• Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,277
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
14
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Designer Developer Steven Trotter Refresh Jonesboro #17
  • 2. “You broke my whole fraking design!” kkthxbye, The Designer
  • 3. Discuss potential problem areas during wireframe process. Explain how you arrived at the design solutions you’re presenting. Find compromises when things don’t work out perfectly.
  • 4. “Oh hells no! That’s going to take too long to build.” pwncakes & roflcopters, The Developer
  • 5. Explain why you really want things a particular way. Both of you. Evaluate with the whole team to find better, streamlined methods. Decide together. Will this function make the product better? If not, where is the time better spent?
  • 6. “Why do you fuglify my stuff ?!” kkthxbye, The Designer
  • 7. Review the design internally before beginning development. Point out small nuances in your design. Is there a reason for the styling? C/B compliant? Is it accessible? What’s the user experience? Explain your point of view. Listen to their point of view. Rinse & repeat.
  • 8. “Yeeeaaahhh… I’m kinda coming in the back door on this one.” pwncakes & roflcopters, The Developer
  • 9. Brainstorm together before beginning design & development. Get & give input during the entire process. Blur the lines between designer & developer. Review everything internally before presenting to the client.
  • 10. “Let’s throw a little AJAX in there… make it real slick.” kkthxbye, The Designer
  • 11. Don’t be afraid to be a teacher. Knowledge sharing now makes for more streamlined projects later. Learn to trust each other so that you can be honest. - “I don’t know what the hell you’re talking about. " It’s a relationship. You’ll start completing each other’s sentences.
  • 12. ”Um, yeah. We’re not including that… it’s completely useless.” pwncakes & roflcopters, The Developer
  • 13. Remember that you are not the user. Often times, developers lack empathy for the user’s POV. It goes both ways: Too much or too little – both suck. Developing for geeks: include the kitchen sink. Developing for task management: a few streamlined features.
  • 14. “Let’s throw an add to calendar link in there. That’s easy enough right?” kkthxbye, The Designer
  • 15. Scope creep: Did the user request a calendar on the site? Will this link add to the site’s calendar or is it an iCal file to be imported to a desktop calendar? Know the specs. Inside. And out. Yes, the developers can work their magic, but that doesn’t mean the client will pay.
  • 16. ”Can’t do it.” pwncakes & roflcopters, The Developer
  • 17. Keep in mind that the ultimate goal is to create the best product possible. Requirements change, and though it sucks to complicate elegant solutions, sometimes change is necessary. Avoid the “knee-jerk no” & when a truly bad idea lands on your plate, your objections will carry a lot more weight.
  • 18. KK THX BYE download me: refreshjonesboro.org http://www.twitter.com/steventrotter