Designer vs Developer (Barcamp Memphis 2009)
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Designer vs Developer (Barcamp Memphis 2009)

  • 1,497 views
Uploaded on

An informal discussion about the things that designers and developers do to piss each other off. We’ll talk about ways to make peace and learn to collaborate on a new level.

An informal discussion about the things that designers and developers do to piss each other off. We’ll talk about ways to make peace and learn to collaborate on a new level.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,497
On Slideshare
1,474
From Embeds
23
Number of Embeds
6

Actions

Shares
Downloads
15
Comments
0
Likes
0

Embeds 23

http://barcampmemphis.com 6
http://www.slideshare.net 5
http://blog.steventrotter.com 4
http://techcampmemphis.com 4
http://www.steventrotter.com 3
http://www.barcampmemphis.org 1

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
  • 2. The The Designer Developer Steven Trotter Craig McCoy @steventrotter @merlincam Creative Director, YWP Developer, YWP Owner, Trotter Designs Founder, Refresh Jonesboro Refresh Jonesboro Founder, Jonesboro Coworking steventrotter.com captaincodemonkey.com
  • 3. “You broke my whole fraking design!” kkthxbye, The Designer
  • 4. 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.
  • 5. “Oh hells no! That’s going to take too long to build.” pwncakes & roflcopters, The Developer
  • 6. 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?
  • 7. “Why do you fuglify my stuff ?!” kkthxbye, The Designer
  • 8. 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.
  • 9. “WTF!? What should this big button even do?” pwncakes & roflcopters, The Developer
  • 10. 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.
  • 11. “Let’s throw a little AJAX in there… make it real slick.” kkthxbye, The Designer
  • 12. 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.
  • 13. ”Um, yeah. We’re not including that… it’s completely useless.” pwncakes & roflcopters, The Developer
  • 14. 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.
  • 15. “Let’s throw an add to calendar link in there. That’s easy enough right?” kkthxbye, The Designer
  • 16. 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.
  • 17. ”I’ll look into it.” (when Firefly returns to Fox) pwncakes & roflcopters, The Developer
  • 18. 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.
  • 19. KK THX BYE download me @ refreshjonesboro.org THANK YOU!