Design Iteration: From Evidence to Design. Slides originally by: Dick Henneman

Design Iteration: From Evidence to Design Slides originally by: Dick Henneman

Foundations: MS-HCI @ Georgia Tech Context of use Context of development Analyze/ Evaluate Design/B uild

Evidence-Based Design in HCI Context of use Context of development Needs/ Capabilities: User Business Market Technology Analyze/ Evaluate Evidence/ Requirements Artifact/ Constraints Design/B uild Product/ App/ Service

This class and the next Context of use Context of development Needs/ Capabilities: User Business Market Technology Analyze/ Evaluate Evidence/ Requirements Artifact/ Constraints Design/B uild Product/ App/ Service Improving UX by integrating evidence into iteratively refined design elements

Five planes of UX* Images (clickable, illustrations), text, aesthetics, visual presentation SURFACE Concrete Placement of buttons, controls, photos, blocks of text How users get to a page, where else they can go, information categories SKELETON STRUCTURE Features and functions What the business wants to get out of the product; what users need SCOPE STRATEGY Abstract *Much of the material in this lecture comes from Garrett, Jesse James. The elements of user experience, 2 nd edition (2011). New Riders.

Functionality or Information? Application functionality E-commerce, social media, financial services Development approach rooted in software/hardware development Task focus Information Newspapers, blogs, twitter Development approach rooted in publishing, information science, media Information focus: enabling people to find, absorb, and make sense of information we provide Most sites are hybrids

Five planes of UX Product as functionality SURFACE SKELETON Product as information STRUCTURE SCOPE STRATEGY

Elements Product as functionality Product as information of UX SURFACE SENSORY SKELETON INTERFACE INFORMATION NAVIGATION STRUCTURE INTERACTION INFORMATION ARCHITECTURE SCOPE FUNCTIONAL SPECIFICATIONS CONTENT REQUIREMENTS STRATEGY USER NEEDS PRODUCT OBJECTIVES

Artifacts Interactive comps Functional prototype Design document SURFACE Product as functionality Product as information SENSORY Wireframe prototype Wireframe specification SKELETON INTERFACE INFORMATION NAVIGATION Paper prototype Storyboards STRUCTURE INTERACTION INFORMATION ARCHITECTURE Requirements document SCOPE FUNCTIONAL SPECIFICATIONS CONTENT REQUIREMENTS Strategy document STRATEGY USER NEEDS PRODUCT OBJECTIVES

Methods Product as functionality Product as information User testing (lab, field, remote), A/B testing SURFACE SENSORY User testing (lab, field, remote), A/B testing SKELETON INTERFACE INFORMATION NAVIGATION Paper prototype interviews, card sorting, treejack STRUCTURE INTERACTION INFORMATION ARCHITECTURE Contextual inquiry, content analysis, interviews, focus groups, surveys, competitive analysis, analytics SCOPE FUNCTIONAL SPECIFICATIONS CONTENT REQUIREMENTS Market research, competitive analysis, focus groups, analytics, call center logs, interviews, contextual inquiry, surveys STRATEGY USER NEEDS PRODUCT OBJECTIVES

Strategy plane STRATEGY USER NEEDS PRODUCT OBJECTIVES What do we want to get out of this product? Business goals Make the company money or to save the company money Respond to competitive pressures Be careful not to jump to solutions Brand identity Goes beyond logos, color palettes, typography Impression of an organization happens whether intentionally or not Success metrics E.g., time on site? Impressions? Reduce calls to call center? Customer satisfaction (CSAT)? Improve Net Promoter Score (NPS)?

Strategy plane STRATEGY USER NEEDS PRODUCT OBJECTIVES What do our users want to get out of this product? User segmentation Demographics? Attitudes? Technology familiarity? User research Market research, contextual inquiry, task analysis, persona development (6023) Risk: Executive-centered design

Strategy Plane: UX Challenges STRATEGY USER NEEDS PRODUCT OBJECTIVES Speaking the language of the business owners Convincing others of the importance of user research Making sure user needs are represented Being aware of efforts to create a strategy Role of consultants

Scope plane SCOPE FUNCTIONAL SPECIFICATIONS CONTENT REQUIREMENTS Why are we making this product (STRATEGY) >> What are we going to make? (SCOPE) Translation of strategy into specific requirements for content and functionality Know what you are building and what you are not building Requirements come from users and stakeholders What people say they want and really do need What people say they want and really do not need The feature people don t know they need User research methods: Contextual inquiry, content analysis, interviews, focus groups, surveys, competitive analysis

Functional Specifications SCOPE FUNCTIONAL SPECIFICATIONS CONTENT REQUIREMENTS Be positive The system will not allow the user to purchase a kite without kite string The system will suggest the user purchase kite string if the user tries to buy a kite without string. Be specific The most popular videos will be highlighted. Videos with the most views in the last week will appear at the top of the list Avoid subjective language The site will have a hip, flashy style. The site will meet the hipness expectations of Wayne, the mail clerk. The look of the site will conform to the company branding guidelines document

Content Requirements SCOPE FUNCTIONAL SPECIFICATIONS CONTENT REQUIREMENTS Content requirements (text, images, audio, video) Example: Sporting event > article, photos, video Don t confuse content purpose with format (e.g., FAQ) Anticipate size of content Identify who is responsible for producing content Frequency of updating (derived from strategy) Content Management System (CMS) Allows publishing, editing and modifying content, organizing, deleting as well as maintenance from a central interface Manages workflow in a collaborative environment. Writer > content editor > stakeholder > copy editor > lawyer > user

Structure plane STRUCTURE INTERACTION INFORMATION ARCHITECTURE Developing a conceptual structure for the product A shift from the abstract to the concrete Interaction design: performing and completing tasks Information architecture: conveying information to user

Information Architecture STRUCTURE INTERACTION INFORMATION ARCHITECTURE Creating organizational and navigational schemes that allow users to move through site content efficiently and effectively Top-down (derived from Strategy) vs. bottom-up (derived from existing/proposed content) approaches Guidelines for maximum number of steps in a task? No, let the task determine Possible approaches: Hierarchical, matrix, organic, sequential Controlled vocabulary: consistency

IA Example Card Sort + Survey STRUCTURE INTERACTION INFORMATION ARCHITECTURE Naming and grouping TV channels

Interaction Design STRUCTURE INTERACTION INFORMATION ARCHITECTURE Describes user behavior and how system responds to that behavior (task focus) Conceptual model e.g., does system treat a particular feature as a thing the user consumes, a place the user visits, or an object the user acquires? Goal: consistency E.g., Shopping cart vs. catalog order form Cart has become a CONVENTION Design for typical use (deemphasize edge cases) Handling errors

Role of user research STRUCTURE INTERACTION INFORMATION ARCHITECTURE User research at the Structure Plane can be an efficient and inexpensive tool Interaction Design: Paper Prototype Evaluation Information Architecture: Card Sort Example: Move from talk-centered to data-centered phone plans Paper prototype, 7 customers (recruited 9), current account holders, online account access and bill pay 90-minute sessions 60-minute review sessions immediately following with key team members (Business owner, information architect, usability engineer, business analyst, system architect) Adapted design after first 4 participants

Sample Results STRUCTURE INTERACTION INFORMATION ARCHITECTURE All participants understood new plan and could see the benefit of it. Explore how to communicate the idea of the new plan to customers Participants had trouble understanding when non-plan usage was displayed near plan-specific usage. Avoid including non-plan data in a different, visually-separated group (e.g., do not represent shared data usage in a shared talk group) Organizing the Accounts Overview (Dashboard) by usage Type (e.g., voice, data) was preferred over Plan (e.g., shared talk). Restructure the proposed dashboard by Usage Type Redundant usage information within and across pages confused users. Explore ways to reduce redundancy and flatten the site (longer term?)

Method for Interpreting Results Evidence/ Requirements Design /Build Post your prototype (paper or screen shots) on a wall or place on a table Step through notes from the interview/evaluation with 3-5 team members Designate a note taker What to capture? Observations, Design idea, Issues Label notes with F (function), UI, V (Validation) Deal with function issues first, then design After a round of participants, walk through all of the notes Create a list of issues that need to be addressed Review each change and decide if you are making a change or leaving the design alone for further testing Update the prototype

Method for Interpreting Results (2) Evidence/ Requirements Design /Build Questions to ask: Is the design on track? Is testing suggesting a change of approach? What parts of the design are stabilizing? What parts of the design are unclear, keep changing, or haven t been worked out? Are we challenging the design? Can we start moving to the next design plane?

Dick s Principles of Interpretation Evidence/ Requirements Design /Build Pay attention to everything Write everything down Involve multiple stakeholders in interpreting results Many methods of interpreting data are possible, but make sure you have and use one Users are not designers (focus more on what they do than on what they say) Look for sufficient validation before you change something

Skeleton plane SKELETON INTERFACE INFORMATION NAVIGATION Focus on smaller scale of individual components and their relationships Interface design: allows users to do things, e.g., buttons, fields, drop-downs Navigation design: provides users with ability to go places Information design: communicates ideas to the user

Skeleton plane NAVIGATION SKELETON INTERFACE INFORMATION NAVIGATION INTERFACE INFORMATION

Wireframes SKELETON INTERFACE INFORMATION NAVIGATION Barebones depiction of all the components of a page and how they fit together Paper version (used by development team) is usually heavily annotated, e.g., notes on behavior Number of wireframes depends on the complexity of the project, but often do not create a wireframe for each page Used by many people on a development team Business, designers, developers, QA Produce the level of documentation needed for your project

Example wireframe

Other example wireframes

Testing Method To test and compare two alternative structures and overall layout of a proposed Welcome Center. Six customers (2/day) with recent TV service installation process experience Interviews grounded in the experiences of each customer + standard tasks In-depth interpretation by team immediately following each session

Surface phase SURFACE SENSORY Sensory design: content, functionality, and aesthetics come together Touch interface and interaction design, device shape, texture, vibration Hearing Vision Contrast and uniformity Internal and external consistency Color palettes and typography Design comps and style guides Research methods Usability testing, preference testing, A/B testing, remote testing, icon testing