Date post: | 19-Oct-2014 |
Category: |
Technology |
View: | 1,448 times |
Download: | 2 times |
Designer Developer
Craig McCoy@merlincam
Developer, YWP
Refresh Jonesboro
captaincodemonkey.com
The
DeveloperSteven Trotter@steventrotter
Creative Director, YWPOwner, Trotter Designs
Founder, Refresh JonesboroFounder, Jonesboro Coworking
steventrotter.com
The
Designer
“You broke my whole fraking design!”
kkthxbye,The Designer
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.
“Oh hells no! That’s going to take too
long to build.”pwncakes & roflcopters,The Developer
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?
“Why do you fuglify my stuff ?!”
kkthxbye,The Designer
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.
“WTF!?What should this big
button even do?”
pwncakes & roflcopters,The Developer
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.
“Let’s throw a little AJAX in there…
make it real slick.”
kkthxbye,The Designer
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.
”Um, yeah. We’re not including that…
it’s completelyuseless.”
pwncakes & roflcopters,The Developer
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.
“Let’s throw anadd to calendar link
in there. That’s easy enough right?”
kkthxbye,The Designer
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.
”I’ll look into it.”(when Firefly returns to Fox)
pwncakes & roflcopters,The Developer
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.
KK THX BYE
THANK YOU!
download me @ refreshjonesboro.org