Successfully reported this slideshow.

Nailing It Down: Detailed Design to Preserve the UX Vision

8

Share

Loading in …3
×
1 of 66
1 of 66

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Nailing It Down: Detailed Design to Preserve the UX Vision

  1. Nailing It Down Detailed Design to Preserve the UX Vision Information Architecture Summit ’11 Joe Sokohl @mojoguzzi @RegJoeConsults CONFIDENTIALITY The concepts and methodologies contained herein are proprietary to Regular Joe Consulting LLC. Duplication, reproduction or disclosure of information is this document without the express written permission of Regular Joe Consulting is prohibited. Enjoy the work. We hope you find it useful.
  2. Agenda  What is “detailed design,” anyway?  What’s the problem  What are some solutions 2
  3. Schedule Intros What is detailed design? Who does it? Where does it break down? Why? Break What are some solutions? How do we work within our projects? Break How does Agile fit in? Open discussion, Q&A 3
  4. A bit about me http://www.uxaustralia.com.au/conference-2010/design-thinking-is-this-our-ticket-to-the-big-table 4
  5. What about you? What’s your story? 5
  6. Who this workshop applies to  Agencies  Independent UXers  Highly regulated areas: healthcare, government, military  Anyone working with distributed teams (including cross-border, multiple time zone teams) 6
  7. Who this workshop might not apply to  Heterogenous teams  UXers who also do the front-end development of their apps  Co-located, nimble teams who don’t have a need to retrace steps Then again.... 7
  8. 8
  9. So what’s the big deal, anyway? Determining what the problem is 9
  10. Typical documentation approaches  Research artifacts such as competitive reviews, heuristic analysis, mental models/affinity diagrams, and personas  User/task matrixes  Hi-level wireframes  Concept models  Card sorts  And on and on and on... 10
  11. Exercise 1: Create your own details  Look at the wireframe.  You need to let the development team know how to realize this wireframe as a functioning Web-based experience.  In 10 minutes, identify what you think would be needed. If you run short of time, circle items on the page that you would communicate.  Think how you would do this. 11
  12. What is Detailed Design? Looking at different processes 12
  13. VIEWW Summary VISION INCEPTION ELABORATION WORK WEB Discover the project goals, Design the information Refine the User Experience Develop the application, Deploy the finished define requirements, and structure and system Design & System Design so integrating front end and application into production, frame the initial scope of architecture of the an application can be built. back end systems. transfer ownership to an application. application. support and maintenance teams. Activities Activities Activities Activities Activities • Gather Input on Business, • Create High-Level User • Usability Testing • Create Deployment Plan • Initial Data Load User and System Experience Design • User POC • Update Detailed Design • Deployment Requirements • Create User Proof-of-Concept Document • Create Detailed User • Create Administrative Guide • Define Business • Conduct Usability Testing Experience Design • Develop Components Requirements • Develop User Education (Component Source) • Create High-Level System • Assess and Select Manual • Define User Requirements Architecture Technologies • Conduct Code Review • Transition to Maintenance • Develop Creative Brief • Create Technical Proof-of- • Deployment Plan Team • Define System Requirements Concept • Detailed Architecture FUNCTIONAL • Develop Initial Deployment TESTING RESULTS • Create Technical POC USER ACCEPTANCE Specification REQUIREMENTS TESTING RESULTS • Coding Standards DOCUMENT • Plan and Implement HIGH-LEVEL Development Environment DESIGN DOCUMENT DETAILED DESIGN DOCUMENT 13
  14. FiveDs Summary Discover Design Define Develop Deliver Define project goals, Further define a Refine design details, Build and integrate Complete the business reqs, set of requirements create final design and front-end and commercialization of and initial scope. and create systems obtain signoff. back-end systems. the product and UX models Activities Activities Activities Activities Activities • Define goals • Brainstorming • Merge visual and • Image and page • Acceptance testing functional design creation • Key success factors • Scenario building • System and • Final content • Content integration knowledge transfer • VOC workshops • Wireframes • Test scenarios • Coding • Product deployment • EOC interviews • Visual direction • Object analysis, • Unit testing • Marketing campaign • B/U/S requirements • HL Info Architecture modeling, design • System staging in • Site analysis • HL Sys Architecture • Database analysis QA environment • Audience analysis • Define technology and design • Incremental QA and • Initial use cases • Design testing on multiple • Business processes documentation platforms 14
  15. FiveDs Summary Discover Design Define Develop Deliver Define project goals, Further define a Refine design details, Build and integrate Complete the business reqs, set of requirements create final design and front-end and commercialization of and initial scope. and create systems obtain signoff. back-end systems. the product and UX models Activities Activities Activities Activities Activities • Define goals • Brainstorming • Merge visual and • Image and page • Acceptance testing functional design creation • Key success factors • Scenario building • System and • Final content • Content integration knowledge transfer • VOC workshops • Wireframes • Test scenarios • Coding • Product deployment • EOC interviews • Visual direction • Object analysis, • Unit testing • Marketing campaign • B/U/S requirements • HL Info Architecture modeling, design • System staging in • Site analysis • HL Sys Architecture • Database analysis QA environment • Audience analysis • Define technology and design • Incremental QA and • Initial use cases • Design testing on multiple • Business processes documentation platforms 15
  16. User Experiences Go Beyond the User Interface Expectations frame users’ experiences through brand perception and prior experience Users achieve goals by performing tasks They accomplish tasks by interacting with content, Powerful Interactions features, and functions in the agent portal and other applications, software and tools User interfaces bring the User Rich Internet Application Solutions Single, reliable view of the Single View of the user experience alive, Interfaces Customer user’s entire relationship providing simplified, with the enterprise supports enjoyable online interactions Distributed Content business processes critical to and instant feedback in and Functionality the delivery of a seamless Web Sites Software / Tools Applications experience flexible, intuitive and forgiving workspaces Business Information Identity Processes Delivery Transactional Analytics Management Loosely joined customer- facing and internal business Content Reporting and Notification Syndication processes support quick and Management Monitoring continuous experience improvement Marketing Campaign Authentication and Workflow Others Management Authorization Reliable content Experience and data form the Enablers foundations of a strong user experience product / service meta data analytic data user content & data ••• Beautiful experiences are more than pixel deep 16
  17. Detailed design codifies empathy. 17
  18. Sketches provide documentation The genius in our styling department is that they not only have a great feel for design, but also for the fact that the design needs to function properly on a motorcycle. That melding of functionality and styling is what makes our motorcycles very, very special. 18
  19. Detailed sketches 19
  20. Embeded specifications 20
  21. The finished product 21
  22. Prototypes help, too 22
  23. Detailed Design Activities  Detailed sketches  Detailed scenarios with branching  User-centered use cases  Visual design specifications  Database design, specifically, fields & interactions  Exact interaction design, to include motion  High-fidelity (and possibly evolutionary) prototypes  L10N/I14N/A11Y  What else? 23
  24. What’s the difference between reqs & specs?  Requirements  Requirements cannot be “gathered”  Requirements are not features  Requirements are not specifications  Specifications  “Effective documentation combines text and images to describe the anatomy and physiology of a product.” 24
  25. Who Does What  Typical roles on a project  IA Information architect  IxD Interaction designer  VisD Visual designer  BA Business analyst  PO Product owner  PM Project manager  SA Systems architect  DA Data architect  DBA Database analyst  Dev Developer  QA Quality assurance analyst 25
  26. Exercise 2: RACI  Decide what role does which task  RACI  Responsible: Does the task  Accountable: Signs off the work Responsible does  Consulted: Provides input, opinions, advice  Informed: Consumes output & information from the team  Only 1 Accountable per task  Work in teams, then we’ll gather to discuss 26
  27. What’s Your Definition? • My definition? A detailed design is • The body of information that conveys sufficient detail to communicate that which can be coded. • Just enough detail to enable the non-UX team (dev, biz, mkt, release) to understand the UX designer’s intent. 27
  28. Where do they break down? 28
  29. Two Sides of the Problem ?? !! 29
  30. Maybe a bit tooooo much.... Planning Track Dev Project IPM Officer Manager Manager QA Manager Once, at start of project Org Process Guidance Project Process Instance Tailoring Guidelines Project Plan Vision Statement Master Schedule Personas Risk Management Strategy Plan Project BaselineCM Project Commitments Master Schedule Test Metrics Test Approach Release Manager Define-Update Test Approach Track Complete Test Approach once per project CM Guidelines CM Plan Baseline CM Guidelines Configuration BaselineCM CM Access Control Policy Management CM Baseline Report Every iteration Scenario List Scenario List Create a Scenarios BaselineCM Scenario Architect Business Analyst UATs Every iteration Iteration Start QoS Req List scenarios Create a Quality of BaselineCM QoS Requirements Lifestyle Snapshot Service Requirement 30
  31. Some Examples of Data Disjunct 31
  32. Where do they break? Why Spec need Team proximity or regulatory need (or both) 32
  33. Requirements masquerading as specifications Traditional approach 1.1.1. The system shall allow the teacher to click a control which displays the first answer in the lesson. NOTE: Subsequent answers can be accessed by User story approach As a clinician and/or front desk assistant, I need to record the writer, provider(s), assistant(s), as well as the date and time of entry for every clinical note, so that I can maintain accurate clinical records. 33
  34. Requirement: Turn indicators 1.3.2.5a: The system shall As a motorcyclist, I want to include the ability for the indicate to followers a changed operator to indicate the direction I’m turning so that I won’t be hit. direction of travel 34
  35. A bridge to nowhere? 35
  36. “ is not it at all, That That is not what I meant, at all. . . . . . ” http://static.guim.co.uk/sys-images/Guardian/Pix/pictures/2009/3/30/1238371335802/TS-Eliot-003.jpg 36
  37. Sometimes specs fall into the wrong hands 37
  38. Special order 191 Major Taylor will proceed to Leesburg, Va., and arrange for transportation of the sick and those unable to walk to Winchester, securing the transportation of the country for this purpose. The route between this and Culpeper Court-House east of the mountains being unsafe will no longer be traveled. Those on the way to this army already across the river will move up promptly; all others will proceed to Winchester collectively and under command of officers, at which point, being the general depot of this army, its movements will be known and instructions given by commanding officer regulating further movements. III. The army will resume its march tomorrow, taking the Hagerstown road. General Jackson's command will form the advance, and, after passing Middletown, with such portion as he may select, take the route toward Sharpsburg, cross the Potomac at the most convenient point, and by Friday morning take possession of the Baltimore and Ohio Railroad, capture such of them as may be at Martinsburg, and intercept such as may attempt to escape from Harper's Ferry. IV. General Longstreet's command will pursue the main road as far as Boonsborough, where it will halt, with reserve, supply, and baggage trains of the army. V.General McLaws, with his own division and that of General R. H. Anderson, will follow General Longstreet. On reaching Middletown will take the route to Harper's Ferry, and by Friday morning possess himself of the Maryland Heights and endeavor to capture the enemy at Harper's Ferry and vicinity. 38
  39. http://www.civilwar.org/battlefields/antietam/maps/antietammap3.html 39
  40. BA’s Doing UX In the 10+ companies I consulted for in the past 6 years, only one had UX professionals contributing to the project. http://www.modernanalyst.com/Resources/Articles/tabid/115/articleType/ArticleView/articleId/1735/ Are-you-ready-to-wear-your-UX-hat-when-duty-calls.aspx 40
  41. ` 41
  42. 42
  43. Solutions More detail at the right time 43
  44. Big, grandiose statement Anything that specifies user behavior or activities that affect users belongs to the user experience team 44
  45. Big, grandiose statement Anything that specifies user behavior or activities that affect users belongs to the purview of the user experience team 45
  46. What Are Some Solutions  Frameworks  Style guides and pattern libraries  Accurate diagrams and traceable notes  A proverbial seat at the table. 46
  47. Frameworks and design principles  NextGen Design Principles & Frameworks: a Case Study  Windows Presentation Framework  HTML5  CSS 47
  48. Style guides and pattern libraries  Apple HI Guidelines  YUI!  Search Patterns from Peter Morville  NeXTStep Style Guide 48
  49. Let’s Talk Traceability Along the Natchez Trace 49
  50. Old School is So Old School 50
  51. Display All Taxes & Fees - Currency References Functionality of this page is based on the current reservation review, reserve, and confirmation pages. It covers reservations made in currency amounts. The GCCI free Use Case: 3.3 night reservation confirmation wireframe appears on the next page. Requirements Matrix: 4.A.1, 4.A.2, 4.A.3, 4.A.4 All modified items should be consistent with existing functionality and visual standards. Site Map: site_map_display_all_fees Base Wireframe: 4.1,4.2,4.3,4.4,4.5 1 Separated Rooms and Fees The room stay is separated by first the total for all rooms reserved, without any taxes or fees. Then the estimated taxes and fees 1 appears, followed by the total stay amount. If taxes and fees are included in the rate, use the term “included”. 2 Breakdown of Taxes and Fees 2 The system breaks out and identifies all taxes, separate from any optional service charges. The CPM system provides the tax and fee information. If taxes and fees are included in the rate, use the 3 term “included in reservation amount”. 3 Optional Service Charges If the property assesses any additional yet optional charges, they appear here. If there are no optional charges, do not display anything. 4 4 Additional Confirmations The Reservation Amount module appears the same on the following pages: • Reservation Confirmation Email • Change Reservation • View Reservation • Cancel Reservation It contains the same information as the Reservation summary, just in a different layout. Best Western International Web Release I (AR0637) E,W, W Keane Architecture Services 51
  52. Display All Taxes & Fees - Currency References Functionality of this page is based on the current reservation review, reserve, and confirmation pages. It covers reservations made in currency amounts. The GCCI free Use Case: 3.3 night reservation confirmation wireframe appears on the next page. Requirements Matrix: 4.A.1, 4.A.2, 4.A.3, 4.A.4 All modified items should be consistent with existing functionality and visual standards. Site Map: site_map_display_all_fees Base Wireframe: 4.1,4.2,4.3,4.4,4.5 1 Separated Rooms and Fees The room stay is separated by first the total for all rooms reserved, without any taxes or fees. Then the estimated taxes and fees 1 appears, followed by the total stay amount. If taxes and fees are included in the rate, use the term “included”. 2 Breakdown of Taxes and Fees 2 The system breaks out and identifies all taxes, separate from any optional service charges. The CPM system provides the tax and fee information. If taxes and fees are included in the rate, use the 3 term “included in reservation amount”. 3 Optional Service Charges If the property assesses any additional yet optional charges, they appear here. If there are no optional charges, do not display anything. 4 4 Additional Confirmations The Reservation Amount module appears the same on the following pages: • Reservation Confirmation Email • Change Reservation • View Reservation • Cancel Reservation It contains the same information as the Reservation summary, just in a different layout. Best Western International Web Release I (AR0637) E,W, W Keane Architecture Services 52
  53. Integrating Detailed Specs with Wireframes or Prototypes 53
  54. Integrating Detailed Specs with Wireframes or Prototypes 54
  55. But...but...what about Agile? 55
  56. Even Agile Projects Need Detail 56
  57. Case Study: Agile and an FDA-Compliant Company “One can never get away from needing to provide 'objective evidence' of design inputs, verification & validation and design outputs, this being the bare framework of what is required by the FDA and most, if not all the international medical device quality requirements.” 57
  58. “The Problem with ‘Quick and Dirty’...” “...‘dirty’ is remembered long after ‘quick’ is forgotten.” 58
  59. Desiree Sy’s Approach 59
  60. Find a way to detail your design  You can’t develop a user-centered product from user stories  You can use personas to ask, “What would Juan do?”  Take photos of sketches. Place them in the backlog.  Embed scenarios into the backlog for empathy traceability 60
  61. Exercise 3: The Challenge Game  Divide into two teams  Challenge team creates potential probs/challenges  Solution team creates features & strengths of the product  Challenge team selects a card from the deck and plays it face up  Solution team tries to find a card that can provide a solution to it.  If the Solution team can’t play a reasonable solution card, the Challenge team gets a point. Otherwise, the point goes to the Solution team.  Work together on each challenge to find that solution. 61
  62. Culture of Your Community 62
  63. Summary What did we learn today? 63
  64. “ In preparing for battle, I have always found that plans are useless... ...but planning is indispensable. ” —Dwight Eisenhower 64
  65. So... Detailed design is...  The body of information that conveys sufficient detail to communicate that which can be coded.  Just enough detail to enable the developer to understand the UX designer’s intent. 65
  66. Many thanks! Joe Sokohl Joe@RegularJoeConsulting.com 1.804.873.6964 @mojoguzzi @RegJoeConsults

Editor's Notes

  • \n
  • \n
  • \n
  • 00:00-00:15Intros\n 00:15-01:00What is detailed design? Who does it?\n 01:00-01:30Where does it break down? Why?\n 01:30-01:45Break\n 01:45-02:35What are some solutions? How do we work within our projects?\n 02:35-02:45Break\n 02:45-03:15How does Agile fit in?\n 03:15-03:30Open discussion, Q&A\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Typical UX documentation approaches we use:\nResearch artifacts such as competitive reviews, heuristic analysis, mental models/affinity diagrams, and personas\nUser requirements matrixes\nAnnotated wireframes\nConcept models\n\n
  • Typical UX documentation approaches we use:\nResearch artifacts such as competitive reviews, heuristic analysis, mental models/affinity diagrams, and personas\nUser requirements matrixes\nAnnotated wireframes\nConcept models\n\n
  • Typical UX documentation approaches we use:\nResearch artifacts such as competitive reviews, heuristic analysis, mental models/affinity diagrams, and personas\nUser requirements matrixes\nAnnotated wireframes\nConcept models\n\n
  • Typical UX documentation approaches we use:\nResearch artifacts such as competitive reviews, heuristic analysis, mental models/affinity diagrams, and personas\nUser requirements matrixes\nAnnotated wireframes\nConcept models\n\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Unfortunately, documentation fails usually at the point that documentation goes to developers. Rarely can developers code from wireframes, even detailed annotations...because they’re not specific enough.\n\n
  • Unfortunately, documentation fails usually at the point that documentation goes to developers. Rarely can developers code from wireframes, even detailed annotations...because they’re not specific enough.\n\n
  • Unfortunately, documentation fails usually at the point that documentation goes to developers. Rarely can developers code from wireframes, even detailed annotations...because they’re not specific enough.\n\n
  • Unfortunately, documentation fails usually at the point that documentation goes to developers. Rarely can developers code from wireframes, even detailed annotations...because they’re not specific enough.\n\n
  • Unfortunately, documentation fails usually at the point that documentation goes to developers. Rarely can developers code from wireframes, even detailed annotations...because they’re not specific enough.\n\n
  • Unfortunately, documentation fails usually at the point that documentation goes to developers. Rarely can developers code from wireframes, even detailed annotations...because they’re not specific enough.\n\n
  • Unfortunately, documentation fails usually at the point that documentation goes to developers. Rarely can developers code from wireframes, even detailed annotations...because they’re not specific enough.\n\n
  • Unfortunately, documentation fails usually at the point that documentation goes to developers. Rarely can developers code from wireframes, even detailed annotations...because they’re not specific enough.\n\n
  • What’s wrong with this “specification”?\nIt’s written by a BA. \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Cindy\n
  • Cindy\n
  • This is the best of both worlds.\nYou rapidly and iteratively create interactions, but you specify the behavior as you go.\nThis approach keeps spec close to the IxD. What’s important is that you define the behaviors as you define the layout, the visual design, and the IA.\n
  • Thsi is the best of both worlds.\nYou rapidly and iteratively create interactions, but you specify the behavior as you go.\nThis approach keeps spec close to the IxD. What’s important is that you define the behaviors as you define the layout, the visual design, and the IA.\n
  • \n
  • \n
  • \n
  • \n
  • The Porsche 914 was a mashup of Porsche and VW teams. Arguably one of the worst cars ever to make it to market.\n
  • one approach: have the UX team designing a sprint/cycle ahead of the implementation team. Yet this approach needs to have a strong sense of design documentation, doesn’t it? Not only is the team working on the current sprint, it’s also designing for the next one.\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • ×