Effectively communicating user interface and interaction design

© 2010 K. Bachmann

Effectively Communicating

User Interface & Interaction Designby Karen Bachmann

Research & Analysis Practice Lead

Perficient XD

© 2013 K. Bachmann

Communicating UI Design | 2

UI Design Process

Welcome to the MarketPlace, Member! The

MarketPlace is your online source for office

supplies, computer software and hardware, and

professional services, all at your discount prices.

If you have any questions about the Marketplace,

please contact Customer Care.

Review I nbox

Place an Order

MarketPlace Help

MarketPlaceMarketPlace

Client BrandPartnerBrand

Main Brand & Copyright© 2009 Ours

?

!

© 2013 K. Bachmann


class GoodbyeCruelWorld { public static void main(String[] args) { System.out.println(”Goodbye World!"); } }

class HelloWorld { public static void main(String[] args) { System.out.println("Hello World!"); } }

Bacon ipsum dolor sit amet pancetta swine shank fatback. Short ribs beef leberkas, jerky pork chop t-bone doner turkey shankle. Bresaola pork chop venison, cow ground round corned beef frankfurter. Tongue ground round short loin flank.

Label

Label

Label Label

Analysis

?

Ham tenderloin sirloin leberkas jowl ribeye. Excepteur pork belly andouille, irure short ribs ea minim bacon dolor ham hock qui officia aliquip incididunt ut. Adipisicing ut incididunt, turkey duis drumstick andouille short ribs occaecat in turducken. Ullamco in irure culpa spare ribs pig.

Label

?

Ideally, design and development iterate

Bacon ipsum dolor sit amet pariatur capicola doner, occaecat do dolor cillum sint. Laboris in do quis, officia anim pork loin shank. Strip steak short loin brisket pariatur duis prosciutto commodo.

© 2013 K. Bachmann

Bacon ipsum dolor sit amet pancetta swine shank fatback. Short ribs beef leberkas, jerky pork chop t-bone doner turkey shankle. Bresaola pork chop venison, cow ground round corned beef frankfurter. Tongue ground round short loin flank.

Label

Label

Label Label

Ham tenderloin sirloin leberkas jowl ribeye. Excepteur pork belly andouille, irure short ribs ea minim bacon dolor ham hock qui officia aliquip incididunt ut. Adipisicing ut incididunt, turkey duis drumstick andouille short ribs occaecat in turducken. Ullamco in irure culpa spare ribs pig.

Label

Bacon ipsum dolor sit amet pariatur capicola doner, occaecat do dolor cillum sint. Laboris in do quis, officia anim pork loin shank. Strip steak short loin brisket pariatur duis prosciutto commodo.


System Test & Ship

class HelloWorld { public static void main(String[] args) { System.out.println("Hello World!"); } }

class GoodbyeCruelWorld { public static void main(String[] args) { System.out.println(”Goodbye World!"); } }

Analysis

More frequently, design and development are separate

?

?

© 2013 K. Bachmann


Designs can be changed over time Without input from the designer

Without a thorough understanding of the user goals the design serves

Without recognizing the underlying rationale in design decisions

© 2013 K. Bachmann


Prepare for change: Design communication

Communication supporting the design helps the final product match the original user goals and informs required changes

Hi! Let me tell you about myself…

© 2013 K. Bachmann


http://nathanbowers.com/art/free-downloadable-abstract-wall-

art/

Prototypes: Worth 1,000 words?

Busy and confusing

Dynamic and

exciting

Yes, but are they the words you meant?

© 2013 K. Bachmann


Who is the audience Developers

Project managers

Visual designers

Content authors

Project sponsors & stakeholders

System testers & UAT managers

Usability testers

© 2013 K. Bachmann


What to communicate Full interactions and system behaviors

Initial state of each screen element

How each element behaves when the user interacts with it

How user action changes (or not) each element

Navigation and screen flows

Rationale and user goals each design decision supports

Which requirements that the design supports

© 2013 K. Bachmann


What to communicate (cont’d)

Data that is input and data that is returned

Errors and messaging

Content requirements

As much detail as needed to support implementation

© 2013 K. Bachmann


How best to communicate design

General overview Exhaustively detailed

All stakeholders Project team

Walkthrough presentation with screen-level comments

UI design specification

Screen shots with call-outs on specific elements

1

2

3

Screen flow document

© 2013 K. Bachmann


Select the approach that works for you Interaction between designers and developers during the

development process

Varied needs for different team members

Methodology used to guide the development life cycle

Culture of the organization and the development team (formal, informal, collaborative, etc.)

Maintenance requirements and future development support

© 2013 K. Bachmann


What about format?

Use what works

Wiki

Written documentation

Spreadsheet

Back of a napkin

Presentation

Auto-generated specification

CASE tool

Drawing software

User story notecardIn-person discussions

© 2013 K. Bachmann


Self-contained communication helps UI designer may not remain engaged with a project

Interaction between designer and developers may be limited

Developers do not always consult with designer about changes

Maintenance developers usually have to go it alone, resulting in some interesting design mutations as a system ages

May be required with some development methodologies

All teams need effective guidance “to process the product requirements into a more detailed format” [Wikipedia]

© 2013 K. Bachmann


Specification vs. Style guide A specification describes the specific controls used,

interactions, data, content, and validation that take place with a UI design to create a user experience

A style guide specifies the layout of pages, choice of controls, and positions of those controls relative to the whole in order to deliver a consistent look and feel

Usability guidelines specify overarching usability goals for types of interactions

© 2013 K. Bachmann


UI specification vs. System requirements “In general, the goal of requirement specifications are to

describe what a product is capable of, whereas the UI specification details how these requirements are implemented in practice” [Wikipedia]

Requirements answer what the system should do; UI specification answers how the system will do it

Requirements come first and should be implementation independent

© 2013 K. Bachmann

COMMUNICATION APPROACHES

So what does this look like?


© 2013 K. Bachmann


Walkthrough presentation A live presentation of the design screens or prototype to

other team members, a guided tour

Shows every major screen and most interactions

Explains important design considerations

Notes key inputs that need to be considered

Answers questions

Includes a companion handout of key screens and at least screen-level notes

© 2013 K. Bachmann


Walkthrough presentation (cont’d) Demonstrates design to stakeholders as well as the

development team

Can be the only addition to the prototype if

Designer remains a resource to the development team

Scope of the project is small

More formal documentation is not part of the project culture/methodology (that is, they won’t read it anyway)

© 2013 K. Bachmann


Example: UI mockup with comments

This basic profile screen is where users are taken when they opt to Create a profile from the home page.

The language is casual in keeping with branding and UX approach of overall site.

© 2013 K. Bachmann


Screen shots with call outs Shows each screen with call-outs highlighting key points

that aid understanding the design

Shows every major screen and most minor screens

Explains the key screen elements and features of the design

Highlights issues or alternative cases

Provides a general reference for stakeholders as well as the development team

Can be the only addition to the prototype if

Designer remains a resource to the development team

Product is well-defined (upgrade, established product type, etc.)

© 2013 K. Bachmann


Example: Screen shot with call outs

1. The language is casual in keeping with branding and UX approach of overall site.

2. Users can specify how to use their physical address. Shipping option is checked by default.

3. User name would use the email, if provided, but user can change.

4. Help text for password will update as user types. Messages include minimum characters (shown in example); strong, good, weak indicators for password strength; and invalid password warning.

1

2

34

© 2013 K. Bachmann


Screen flow document Shows each screen in task order

Explains the key screen elements and features of the design (may be paired with call-outs)

Highlights issues or significant alternative cases

May omit message dialogs

Provides a general reference for stakeholders as well as the development team

Will directly support writing user documentation, system test cases, and usability test scenarios

© 2013 K. Bachmann


Screen flow document (cont’d) Is a useful companion to a prototype to ensure functionality

is not missed — user guide for the prototype

Is a good choice when

The designer has moderate to low level of engagement with the project during development

User tasks are complex and/or the system is highly transactional

The prototype is a partial representation or not interactive

© 2013 K. Bachmann


Example: Screen flow document

When you click the Create My Profile button, you reach the Thank You screen with options to add more information.

Click the arrow next to the What I want to know (or don’t) item. The item expands to show all email options.

Screen note: The Thank You message only appears the first time. Subsequent profile editing reuses the options, but has a different introduction.

Screen note: Sales announcements and Product highlights and reviews are selected by default.

© 2013 K. Bachmann


UI design specification Details each screen and each element

Explains the screen elements and features of the design (may be paired with call-outs)

Highlights issues or alternative cases

Describe message dialogs

Provides a detailed reference primarily for the development team

© 2013 K. Bachmann


UI design specification (cont’d) Is a good choice when

The designer will not have a high level of engagement with the project during development

Scope of the project is larger or will be long-lived

More formal documentation is part of the project culture/methodology

The prototype is a partial representation or not interactive

© 2013 K. Bachmann


What details to specify Type of control

Initial state of the field, including defaults

Point of entry or pre-requisite conditions

Supported interactions and behaviors

Interaction business rules, such as whether the field is required

Requirements, use case, and prototype screen references

Accessibility guidelines supported

Rationale for use of a particular widget or pattern (tied to user research or UI standards)

© 2013 K. Bachmann

What details to specify (cont’d) Data displayed or accepted

Data returned

Examples of the kinds of information users may enter

Validation or data normalization rules

Errors and other messaging

End state of the field

Any questions or discussion around a particular design that may not be finalized


© 2013 K. Bachmann

Axure specification Detailed UI specification built into a prototype

Generates either as a specification document or as annotations and page notes in the HTML prototype

Annotations sometimes are enough

Reminders to development team

Sufficiently “visible” design

Heavy documentation not appropriate for environment


© 2013 K. Bachmann

Example: Axure prototype with annotations


Page Notes describe the page overall.

Annotations describe each particular element.

© 2013 K. Bachmann


Key points to remember Design guidance ensures that the user and business goals

behind the UI and interaction design are achieved by every version of the end product

Designs change — Be prepared to support that change while protecting user goals

Deliver information that works and will be used by the whole team

Provide as much detail as needed and no more

© 2013 K. Bachmann


Read More Laura Brandenburg. “How to create a user interface specification.” Bridging the Gap:

http://www.bridging-the-gap.com/how-to-create-a-user-interface-specification/ Dan Brown. Communicating Design. 2nd Ed. New Riders Press: 2010. Peter Gremett. “Using Wikis to Document UI Specifications.” Boxes and Arrows:

http://www.boxesandarrows.com/view/using-wikis-to Brian R. Krause. “Getting Creative With Specs: Usable Software Specifications” Boxes

and Arrows: http://www.boxesandarrows.com/view/getting_creative_with_specs_usable_software_specifications

Karen McGrane. “We're All Content Strategists Now.” IDEA 2010: http://ideaconference.org/2010/speakers/Karen-McGrane

Nokia. “UI Specifications” Design and User Experience Library v2.0: http://library.forum.nokia.com/index.jsp?topic=/Design_and_User_Experience_Library/GUID-AC29156A-7992-45ED-93A2-C4B8ED6614F3.html

Wikipedia. “User interface specification.” http://en.wikipedia.org/wiki/User_interface_specification

Thomas Memmel Zuerich. “Interactive User Interface Specifications” The Usability Architect (personal blog): http://www.usability-architect.com/search/label/UI%20specification%20practice

© 2013 K. Bachmann


About meKaren Bachmann, the Research & Analysis Practice Lead with Perficient, helps clients deliver usable products that support how users need and expect to interaction with information and perform their tasks. Karen is a member of STC, UXPA, and ACM SIGCHI. She is a former manager of the Usability & User Experience community and is an Associate Fellow of STC.

She lives with 6 ferrets and a cat, who view her and the other human in the house as necessary, although hard-to-train, staff.

Karen can be reached [email protected] or [email protected]. Slides are available on Slideshare: http://www.slideshare.net/karenbachmann/communicating-ui-designslideshare

Got treats?

Effectively communicating user interface and interaction design

News & Politics

Transcript of Effectively communicating user interface and interaction design