First users: Heuristics for designer/developer collaboration

  • 907 views
Uploaded on

From the University of Illinois Web Conference 2013. …

From the University of Illinois Web Conference 2013.

Ask a web designer who his “first users” are, and he’ll probably name early adopters, stakeholders, or usability testers. Designers rarely consider their actual first users: the web developers they work with to build their designs. Over the last year, I’ve performed an informal user research project where the “users” were software development teams of all shapes and sizes. Drawing on these discussions and my background as a former web developer, I’ve created a set of friendly heuristics (in the tradition of Jakob Nielsen and Louis Rosenfeld) that designers can use to make their design materials far more useful for developers. I’ll show how these heuristics will encourage holistic solutions rather than piecemeal design work, surface critical implementation issues sooner, and establish a stronger basis for designer/developer collaboration.

More in: Technology , Design
  • 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
907
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
2
Comments
0
Likes
0

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. First Users:Designing for Web DevelopersHeuristics for improvingdesigner/developer collaborationUIllinois Web Conference 2013Jonathan Abbett@jonabbett · jonathan@abbett.org · http://abbett.org
  • 2. Questions?Critiques?Suggestions?
  • 3. 24 December 1990
  • 4. The CONCISE FOLK HISTORY of “WEB PEOPLE”WebmasterInformation Architect
  • 5. The CONCISE FOLK HISTORY of “WEB PEOPLE”WebmasterInformation ArchitectWeb DesignerWeb DeveloperUsability AnalystInteraction DesignerUser Experience DesignerContent StrategistJavaScript MVC Developer, etc., etc., etc.vs. “The User”
  • 6. 1990JAKOBNIELSEN10 UsabilityHeuristicsfor UserInterfaceDesign2011RESMINI &ROSATIHeuristicsfor aPervasiveInformationArchitecture2011JUHANSONINDesignAxioms2012ABBYCOVERTInformationArchitectureHeuristics2004LOUROSENFELDIAHeuristics
  • 7. The CONCISE FOLK HISTORY of “WEB PEOPLE”WebmasterInformation ArchitectWeb DesignerWeb DeveloperUsability AnalystInteraction DesignerUser Experience DesignerContent StrategistJavaScript MVC Developer, etc., etc., etc.vs. “The User”
  • 8. “Designers have to be aware that what is‘normal’ to them, in terms of how they readsketches and what they see in them, is notobvious to others, and they must take thatinto account in how they educate others, andwhat representation they use tocommunicate ideas.”
  • 9. “Those without design training … need to besensitive to this difference of skills … beforemaking uninformed judgments... [They]should do their best to gain some literacy indesign representations, and designers shouldgo out of their way to help them in this.”
  • 10. A common language
  • 11. IntentionalityConsistencyThoroughnessInforealismAdaptationMaintenanceMeasurabilityCommunication
  • 12. ONE / INTENTIONALITYAll design choices are made for areason.
  • 13. ONE / INTENTIONALITY / KEY QUESTIONS• What user/business/communal goals are served byeach component of the design?• Are design decisions supported by best practices?• Do you understand why you’ve copied somethingfrom elsewhere?
  • 14. ONE / INTENTIONALITY / IN ACTION• Annotate design materials with references to userresearch (scenarios, personas, etc.)• Refer to known design patterns, best practices, orheuristics• Present new interactions for team critique• Simplify!
  • 15. TWO / CONSISTENCYThe same interactions arerepresented the same waythroughout the design.
  • 16. TWO / CONSISTENCY / KEY QUESTIONS• If recommending an alternative to an establishedinteraction pattern, why is this new type ofinteraction necessary or desirable?
  • 17. TWO / CONSISTENCY / IN ACTION• Define visual treatments (type, color, layoutpatterns) in one place and use consistentlythroughout design materials.• Define frequently used interactions once in detail,and refer back when used in designs.• Justify differences (see #1)• Create templates so you can work quickly withoutbeing sloppy
  • 18. THREE / THOROUGHNESSThe design comprehensivelyrepresents all system states,transitions, and modes ofcommunication.
  • 19. THREE / THOROUGHNESS / KEY QUESTIONS• Does the design include examples of all interactionstates?• Does the design show transitions from one state toanother?• Has the software team agreed that it has enoughdetail to build?
  • 20. THREE / THOROUGHNESS / IN ACTION• Wireframe in sequence• Review materials with devs and annotate directly• Prototype unfamiliar or complex interactions in amore realistic medium• Don’t forget errors, delays, service interruptions,validation• Supplement visual materials with softwarerequirements if necessary
  • 21. FOUR / INFOREALISMThe design fully reflects the data tobe displayed and captured.
  • 22. FOUR / INFOREALISM / KEY QUESTIONS• Are designs and prototypes populated with realdata?• Do you understand the extremes of your data?
  • 23. FOUR / INFOREALISM / IN ACTION• Get access to your company’s data (now).• Look at extremes of individual fields.• Look at overall orders of magnitude.• Include examples of missing/absent data.• Take time to write real copy. No lorem ipsum.
  • 24. FIVE / ADAPTATIONThe design indicates how the systemwill adapt to different form factors.
  • 25. FIVE / ADAPTATION / KEY QUESTIONS• What devices, browsers and screen orientations willyou support?• Will you implement one responsive interface, orspecialized interfaces?
  • 26. FIVE / ADAPTATION / IN ACTION• Wireframe every relevant form factor (at least at ahigh level, e.g. layouts).• Build responsive prototypes.• Identify which user scenarios require mobile deviceaccess.• Remember accessibility! (Screen readers, etc.)• Mobile first…http://www.lukew.com/presos/preso.asp?26
  • 27. SIX / MAINTENANCEThe design describes how the userwill administer the system.
  • 28. SIX / MAINTENANCE / KEY QUESTIONS• What data elements need to be managed?• How will you monitor system health?• How will the right people compose content? (help,marketing, field labels, validation)• How will you internationalize the content?• What system scenarios require proactivenotification?
  • 29. SIX / MAINTENANCE / IN ACTION• Design all administrative interfaces up front.Don’t leave for the end.• Bring content writers (customer service, marketing,content strategists, etc.) into process early.• Remember that i18n can be employed for low-literacy users.
  • 30. SEVEN / MEASURABILITYThe design specifies what measureswill be collected to indicate thesuccess of the system.
  • 31. SEVEN / MEASURABILITY / KEY QUESTIONS• How will product owners track operational success?• How will you gauge success of redesign over legacydesign?• How does the design communicate those measures?
  • 32. SIX / MEASURABILITY / IN ACTION• Design reports and analytical tools up front.Don’t save it for the end.(In fact, you might want to start here.)• Define your [design] success criteria.• Refer to user goals & corporate goals.(You have them, right?)
  • 33. EIGHT / COMMUNICATIONThe design specifies how the systemwill communicate with usersthroughout the product experience.
  • 34. EIGHT / COMMUNICATION / KEY QUESTIONS• Does the design include real & thoughtful content?• What synchronous & asynchronous events withinthe application will trigger communications?• What mode(s) of communication are appropriatefor each event?
  • 35. EIGHT / COMMUNICATION / IN ACTION• Again, no lorem ipsum: write real informational,instructional/help content.• Design & test your e-mails (e.g. Litmus)• Think across spectrum: growl, popup, e-mail, textmessage, automated phone call, snail mail…• Understand your users’ technology access(e.g. smartphone vs. SMS)
  • 36. Ways to use1. Add a step in your process for review.2. Use as a kickoff document for projects withnew teams.3. Teaching tool, alongside other heuristics4. Dismiss as common sense (at your peril)
  • 37. With thanks to thesedevelopers and designersWilliam Wechtenhiser, Jeremy Hert, Timothy Danford,Chaim Kirby, Flavia Gnecco, Patrick Keller,Patrick SchmidAnd recognizing great inspiration fromJuhan Sonin, Abby Covert, Atul Gawande,Bill Buxton, Alok Nandi
  • 38. Thank you!http://devheuristics.com@jonabbettjonathan@abbett.org
  • 39. References & ResourcesJAKOB NIELSEN: 10 Usability Heuristics forUser Interface Designhttp://www.nngroup.com/articles/ten-usability-heuristics/RESMINI & ROSATI: Heuristics for a PervasiveInformation Architecturehttp://pervasiveia.com/wp/wp-content/uploads/2011/04/chapter3-heuristics.pdfJUHAN SONIN: Design Axiomshttp://www.mit.edu/~juhan/design_axioms.htmlABBY COVERT: Information ArchitectureHeuristicshttp://www.slideshare.net/AbbyCovert/information-architecture-heuristicsLOU ROSENFELD: Information ArchitectureHeuristicshttp://louisrosenfeld.com/home/bloug_archive/000286.htmlBILL BUXTON: Sketching User Experienceshttp://www.billbuxton.com/ATUL GAWANDE: The Checklist Manifestohttp://gawande.com/the-checklist-manifesto
  • 40. Image SourcesWorldWideWeb browser: http://www.w3.org/People/Berners-Lee/WorldWideWeb.htmlNielsen: http://jakob.nielsen.usesthis.com/Rosenfeld: http://www.flickr.com/photos/jodieandlarry/1386993480/Sonin: http://about.me/juhansoninResmini: http://uxbrighton.org.ukBuxton: http://billbuxton.com/