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


Total Views
On Slideshare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 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