Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Working with Developers for Fun & Profit

Working with Developers for Fun & Profit

This presentation was given at Midwest UX in Columbus, OH on June 2, 2012.

There has been a lot of discussion recently within the UX community about what is required to be an Interaction Designer. Do you have to be good at visual design? Do you have to know how to code? These are the wrong questions. The question we need to ask is, “What skills and methods will make us better Interaction Designers?” The answers will vary greatly depending on the context of your work: the type of company you work for, the makeup of your team, the types of projects you work on, and so forth.

I strongly believe that a closer working relationship with developers and participation in more of the development process will improve your ability to deliver outstanding products and will increase your job satisfaction as a designer. I will outline a collaboration lifecycle in relation to project schedules and the design process and show designers how they can extend their influence, insuring design integrity and improving the quality of the final product, through greater participation in the entire development process. The presentation will address use of developer tools, documentation, the designer's ability to code, and designer–developer relationships.

Jack Moffett

June 03, 2012
Tweet

More Decks by Jack Moffett

Other Decks in Design

Transcript

  1. Working with Developers For Fun & Profit Jack Moffett |

    @jackmoffett Senior Interaction Designer, Inmedius designaday.tumblr.com
  2. “The way we work at Apple is that the complexity

    of these products really makes it critical to work collaboratively, with different areas of expertise. I think that’s one of the things about my job I enjoy the most. I work with silicon designers, electronic and mechanical engineers, and I think you would struggle to determine who does what when we get together. We’re located together, we share the same goal, have exactly the same preoccupation with making great products.” Sir Jonathan Ive
  3. by the power of grayskull by Speculum Mundi http://www.flickr.com/photos/speculummundi/4569110353/in/photostream/ user

    study & requirements analysis interaction & information design visual design & graphics production UI prototyping & implementation functional testing usability evaluation authoring of user guides & training materials
  4. it hasn’t always been that way Memory Lane by physiognomist

    http://www.flickr.com/photos/davidmican/315728765/
  5. Develop a shared understanding of the requirements Pre-game huddle by

    -just-jen- http://www.flickr.com/photos/whetzel/55214389/
  6. Develop a shared understanding of the requirements Pre-game huddle by

    -just-jen- http://www.flickr.com/photos/whetzel/55214389/
  7. Identify technologies The cup that can only be half-full. by

    vrogy http://www.flickr.com/photos/vrogy/511644410/
  8. Identify technologies The cup that can only be half-full. by

    vrogy http://www.flickr.com/photos/vrogy/511644410/
  9. Estimate Time & Effort “Ideally, the developers and I are

    to work closely together during the design phase... but it typically works out that they gloss over the document or attend a few meetings and get a basic understanding of what we are planning on doing, but never pay attention to the full details. Then they tend to come to me with questions or ‘are you crazy? I can’t do that!’ when it’s time for them to put together a timeline for their development assessment. After a few times of close calls, they are beginning to pay more attention to the pencil sketches and overall workflows we put together for them.” By eflon http://www.flickr.com/photos/eflon/5079163335/
  10. Estimate Time & Effort software bill of materials By eflon

    http://www.flickr.com/photos/eflon/5079163335/
  11. Estimate Time & Effort How can we best prioritize our

    work to support the developers’ schedule? By eflon http://www.flickr.com/photos/eflon/5079163335/
  12. A successful tool is one that was used to do

    something undreamed of by its author. by katerha http://www.flickr.com/photos/katerha/5746905652/ Use their tools
  13. A successful tool is one that was used to do

    something undreamed of by its author. by katerha http://www.flickr.com/photos/katerha/5746905652/ Issue Tracking
  14. A successful tool is one that was used to do

    something undreamed of by its author. by katerha http://www.flickr.com/photos/katerha/5746905652/ Issue Tracking
  15. A successful tool is one that was used to do

    something undreamed of by its author. by katerha http://www.flickr.com/photos/katerha/5746905652/ Issue Tracking Create items for each of your design tasks. Developers can subscribe to the ones that relate to their own tasks. Your estimates can be calculated in the chartboard, or not.
  16. A successful tool is one that was used to do

    something undreamed of by its author. by katerha http://www.flickr.com/photos/katerha/5746905652/ Wiki
  17. A successful tool is one that was used to do

    something undreamed of by its author. by katerha http://www.flickr.com/photos/katerha/5746905652/ Wiki Subscribe to see what the developers are thinking. Document your own thinking so it is available to them.
  18. Design Documentation One size fits all…. By The Candid Street

    http://www.flickr.com/photos/haddadi/5971508861/
  19. Design Documentation One size fits all…. By The Candid Street

    http://www.flickr.com/photos/haddadi/5971508861/
  20. Design Documentation One size fits all…. By The Candid Street

    http://www.flickr.com/photos/haddadi/5971508861/
  21. Design Documentation One size fits all…. By The Candid Street

    http://www.flickr.com/photos/haddadi/5971508861/
  22. Design Documentation One size fits all…. By The Candid Street

    http://www.flickr.com/photos/haddadi/5971508861/ Design the documentation for those that will wear it.
  23. Bill Scott “The developers really appreciated it, because they could

    just look at it, and they didn’t have to wonder if the designer had forgotten something.”
  24. Documentation is part of the design process. One size fits

    all…. By The Candid Street http://www.flickr.com/photos/haddadi/5971508861/
  25. Documentation is part of the design process. One size fits

    all…. By The Candid Street http://www.flickr.com/photos/haddadi/5971508861/ You learn a lot by describing your design.
  26. “I get most frustrated when, after providing a pixel-perfect mockup,

    I see the finished implementation during the testing phase, and it’s drastically different than what I spec’d (fonts, colors, sizes, spacing, alignment, positioning, etc).”
  27. “If you’re in a room filled with designers, bring up

    the topic of whether it’s valuable for a designer to also code. Immediately, the room will divide faster than Moses split the Red Sea. One side will tell you coding is an essential skill, while the other will vehemently argue how it dilutes the designer’s value.” An Event Apart 2010: San Diego - Jared Spool By peterjhart http://www.flickr.com/photos/40054618@N03/5139909661/ Jared Spool
  28. Tasked with coding instead of design “I found that when

    I tried to be both a designer and engineer/coder, I ended up doing a lot more engineering and a lot less design than I wanted to do. I think part of the problem is that engineering skills are, in the end, valued more than design skills.” Jennifer Tidwell, author of Designing Interfaces: Patterns for Effective Interaction Tent By planetlight http://www.flickr.com/photos/planetlight/4767815082/in/photostream/
  29. Tasked with coding instead of design Limit Creativity due to

    knowledge of difficulty Tent By planetlight http://www.flickr.com/photos/planetlight/4767815082/in/photostream/
  30. Tasked with coding instead of design Limit Creativity due to

    knowledge of difficulty Tent By planetlight http://www.flickr.com/photos/planetlight/4767815082/in/photostream/
  31. Tasked with coding instead of design Limit Creativity due to

    knowledge of difficulty Marginalize design skills to add coding skills Tent By planetlight http://www.flickr.com/photos/planetlight/4767815082/in/photostream/
  32. Calling BS on coders Mighty Elixir By Robert S. Donovan

    http://www.flickr.com/photos/booleansplit/2220774911/
  33. Calling BS on coders Respect & credibility Mighty Elixir By

    Robert S. Donovan http://www.flickr.com/photos/booleansplit/2220774911/
  34. Calling BS on coders Respect & credibility Speaking their language

    Mighty Elixir By Robert S. Donovan http://www.flickr.com/photos/booleansplit/2220774911/
  35. Calling BS on coders Respect & credibility Speaking their language

    Knowledge of capabilities & difficulty Mighty Elixir By Robert S. Donovan http://www.flickr.com/photos/booleansplit/2220774911/
  36. Calling BS on coders Respect & credibility Speaking their language

    Knowledge of capabilities & difficulty Participation in evaluation & selection of technology Mighty Elixir By Robert S. Donovan http://www.flickr.com/photos/booleansplit/2220774911/
  37. Calling BS on coders Respect & credibility Speaking their language

    Knowledge of capabilities & difficulty Participation in evaluation & selection of technology Better able to create prototypes Mighty Elixir By Robert S. Donovan http://www.flickr.com/photos/booleansplit/2220774911/
  38. Calling BS on coders Respect & credibility Speaking their language

    Knowledge of capabilities & difficulty Participation in evaluation & selection of technology Better able to create prototypes Mighty Elixir By Robert S. Donovan http://www.flickr.com/photos/booleansplit/2220774911/ Participation in implementation
  39. “Coding and designing are collections of skills. What we’ve learned

    is teams with a better distribution of skills, not segmented by roles, produce better results.” An Event Apart 2010: San Diego - Jared Spool By peterjhart http://www.flickr.com/photos/40054618@N03/5139909661/
  40. “Coding and designing are collections of skills. What we’ve learned

    is teams with a better distribution of skills, not segmented by roles, produce better results.” An Event Apart 2010: San Diego - Jared Spool By peterjhart http://www.flickr.com/photos/40054618@N03/5139909661/
  41. building blocks By ella novak http://www.flickr.com/photos/cookylida/3334177358/ Participation in Implementation Less

    documentation is required when you implement your own design. Get everything perfect the first time.
  42. A successful tool is one that was used to do

    something undreamed of by its author. by katerha http://www.flickr.com/photos/katerha/5746905652/ Use their tools
  43. A successful tool is one that was used to do

    something undreamed of by its author. by katerha http://www.flickr.com/photos/katerha/5746905652/ Working in the Production Code
  44. A successful tool is one that was used to do

    something undreamed of by its author. by katerha http://www.flickr.com/photos/katerha/5746905652/ Working in the Production Code I don’t have to ask permission to make changes or ask someone else to make them for me.
  45. A successful tool is one that was used to do

    something undreamed of by its author. by katerha http://www.flickr.com/photos/katerha/5746905652/ Working in the Production Code I don’t have to ask permission to make changes or ask someone else to make them for me. I know that the final product will be the one that I designed.
  46. A successful tool is one that was used to do

    something undreamed of by its author. by katerha http://www.flickr.com/photos/katerha/5746905652/ Working in the Production Code I don’t have to ask permission to make changes or ask someone else to make them for me. I know that the final product will be the one that I designed. With great power comes great responsibility.
  47. Functional Testing Abandoned buildings of Ichikawa junior/senior high school, Chiba

    Japan. By naosuke ii http://www.flickr.com/photos/ogwrnsk/5020082786/
  48. Designers make great testers Abandoned buildings of Ichikawa junior/senior high

    school, Chiba Japan. By naosuke ii http://www.flickr.com/photos/ogwrnsk/5020082786/
  49. Designers make great testers Detail oriented Abandoned buildings of Ichikawa

    junior/senior high school, Chiba Japan. By naosuke ii http://www.flickr.com/photos/ogwrnsk/5020082786/
  50. Designers make great testers Detail oriented Use the system more

    like a user Abandoned buildings of Ichikawa junior/senior high school, Chiba Japan. By naosuke ii http://www.flickr.com/photos/ogwrnsk/5020082786/
  51. Designers make great testers Detail oriented Use the system more

    like a user Know better than anyone how the thing is supposed to work Abandoned buildings of Ichikawa junior/senior high school, Chiba Japan. By naosuke ii http://www.flickr.com/photos/ogwrnsk/5020082786/
  52. A successful tool is one that was used to do

    something undreamed of by its author. by katerha http://www.flickr.com/photos/katerha/5746905652/ Use their tools
  53. A successful tool is one that was used to do

    something undreamed of by its author. by katerha http://www.flickr.com/photos/katerha/5746905652/ Use their tools Participation is power.
  54. A successful tool is one that was used to do

    something undreamed of by its author. by katerha http://www.flickr.com/photos/katerha/5746905652/ Use their tools Participation is power. Gives you the opportunity to record usability issues to be fixed prior to usability testing.
  55. A successful tool is one that was used to do

    something undreamed of by its author. by katerha http://www.flickr.com/photos/katerha/5746905652/ Use their tools Participation is power. Gives you the opportunity to record usability issues to be fixed prior to usability testing. Don’t abuse it—follow the rules.
  56. it works both ways Have developers participate in field trials.

    They will gain a better appreciation of the users’ concerns.
  57. it works both ways Have developers participate in field trials.

    They will gain a better appreciation of the users’ concerns. Other developers will listen when one of their own is as adamant about usability concerns as you are.
  58. v2.19: March 19th (Pirate Socks) by Phoney Nickle http://www.flickr.com/photos/mslivenletlive/427537759/ DO

    Not Critique engineering prototypes on aesthetics or interaction design.
  59. v2.19: March 19th (Pirate Socks) by Phoney Nickle http://www.flickr.com/photos/mslivenletlive/427537759/ DO

    Not Critique engineering prototypes on aesthetics or interaction design. Force your process on the developers.
  60. v2.19: March 19th (Pirate Socks) by Phoney Nickle http://www.flickr.com/photos/mslivenletlive/427537759/ DO

    Not Critique engineering prototypes on aesthetics or interaction design. Force your process on the developers. Expect developers to make changes at the last minute because you haven’t been involved until the end.
  61. v2.19: March 19th (Pirate Socks) by Phoney Nickle http://www.flickr.com/photos/mslivenletlive/427537759/ DO

    Not Critique engineering prototypes on aesthetics or interaction design. Force your process on the developers. Expect developers to make changes at the last minute because you haven’t been involved until the end. Expect developers to have the same visual sensibilities you have.
  62. v2.19: March 19th (Pirate Socks) by Phoney Nickle http://www.flickr.com/photos/mslivenletlive/427537759/ Yes

    Please Position your involvement as something that makes your developers’ job easier.
  63. v2.19: March 19th (Pirate Socks) by Phoney Nickle http://www.flickr.com/photos/mslivenletlive/427537759/ Yes

    Please Position your involvement as something that makes your developers’ job easier. Be inclusive. It’s not our responsibility to make decisions so much as to offer options.
  64. v2.19: March 19th (Pirate Socks) by Phoney Nickle http://www.flickr.com/photos/mslivenletlive/427537759/ Yes

    Please Position your involvement as something that makes your developers’ job easier. Be inclusive. It’s not our responsibility to make decisions so much as to offer options. Find opportunities to educate.
  65. v2.19: March 19th (Pirate Socks) by Phoney Nickle http://www.flickr.com/photos/mslivenletlive/427537759/ Yes

    Please Position your involvement as something that makes your developers’ job easier. Be inclusive. It’s not our responsibility to make decisions so much as to offer options. Find opportunities to educate. Dare to compromise.
  66. v2.19: March 19th (Pirate Socks) by Phoney Nickle http://www.flickr.com/photos/mslivenletlive/427537759/ Yes

    Please Position your involvement as something that makes your developers’ job easier. Be inclusive. It’s not our responsibility to make decisions so much as to offer options. Find opportunities to educate. Dare to compromise. Be social - Jenna Bilotta says, “Drink a beer with your engineer.”
  67. Four Storms And A Twister by JD Hancock http://www.flickr.com/photos/jdhancock/3842546304/ Tight

    Dev Team Integration Participate in the entire development process
  68. Four Storms And A Twister by JD Hancock http://www.flickr.com/photos/jdhancock/3842546304/ Tight

    Dev Team Integration Participate in the entire development process Tailor documentation to be developer-friendly
  69. Four Storms And A Twister by JD Hancock http://www.flickr.com/photos/jdhancock/3842546304/ Tight

    Dev Team Integration Participate in the entire development process Tailor documentation to be developer-friendly Use the developers’ tools
  70. Four Storms And A Twister by JD Hancock http://www.flickr.com/photos/jdhancock/3842546304/ Tight

    Dev Team Integration Participate in the entire development process Tailor documentation to be developer-friendly Use the developers’ tools Learn implementation skills
  71. Four Storms And A Twister by JD Hancock http://www.flickr.com/photos/jdhancock/3842546304/ Tight

    Dev Team Integration Participate in the entire development process Tailor documentation to be developer-friendly Use the developers’ tools Learn implementation skills Be respectful / Be social
  72. Suggested Reading • How designers and engineers can play nice

    (and still run with scissors) by Jenna Bilotta • Concept to Code - Code Literacy in UX by Ryan Betts • Owen Otto’s response to “How do UI designers work with engineers to ensure their vision is achieved?” on Quora • 3 Reasons Why Learning To Code Makes You A Better Designer by Jared Spool
  73. Credits Typefaces: Blanch, by Atipus Myriad Pro, by Adobe Survey

    visualizations created with Parallel Sets by Robert Kosara.