Making The Translation: Critical Web App Design Deliverables

UIE Web Application Summit, March 2008 Making The Translation: Critical Web App Design Deliverables D. Keith Robinson, March 26, 2008

UIE Web Application Summit, March 2008 Introduction

UIE Web Application Summit, March 2008 D. Keith Robinson

UIE Web Application Summit, March 2008 D. Keith Robinson • Principle & Creative Director for Blue Flavor

UIE Web Application Summit, March 2008 D. Keith Robinson • Principle & Creative Director for Blue Flavor • Based in Seattle, Washington

UIE Web Application Summit, March 2008 D. Keith Robinson • Principle & Creative Director for Blue Flavor • Based in Seattle, Washington • Over 12 years designing for web, etc.

UIE Web Application Summit, March 2008 D. Keith Robinson • Principle & Creative Director for Blue Flavor • Based in Seattle, Washington • Over 12 years designing for web, etc. • Has worked internally for large companies (Boeing, Children’s Hospital Seattle)

UIE Web Application Summit, March 2008 D. Keith Robinson • Principle & Creative Director for Blue Flavor • Based in Seattle, Washington • Over 12 years designing for web, etc. • Has worked internally for large companies (Boeing, Children’s Hospital Seattle) • Has worked as a consultant for companies large and small.

UIE Web Application Summit, March 2008 D. Keith Robinson • Principle & Creative Director for Blue Flavor • Based in Seattle, Washington • Over 12 years designing for web, etc. • Has worked internally for large companies (Boeing, Children’s Hospital Seattle) • Has worked as a consultant for companies large and small. • Recent clients include Tipped.co.uk, HP, Motive Interactive

UIE Web Application Summit, March 2008 Critical. Web App. Design.

UIE Web Application Summit, March 2008 Critical. Web App. Design. • Critical.

UIE Web Application Summit, March 2008 Critical. Web App. Design. • Critical. Documenting your design decisions is important.

UIE Web Application Summit, March 2008 Critical. Web App. Design. • Critical. Documenting your design decisions is important. • Web Application.

UIE Web Application Summit, March 2008 Critical. Web App. Design. • Critical. Documenting your design decisions is important. • Web Application. The design process you use for a Web app will differ greatly from, say, a web site.

UIE Web Application Summit, March 2008 Critical. Web App. Design. • Critical. Documenting your design decisions is important. • Web Application. The design process you use for a Web app will differ greatly from, say, a web site. • Design.

UIE Web Application Summit, March 2008 Critical. Web App. Design. • Critical. Documenting your design decisions is important. • Web Application. The design process you use for a Web app will differ greatly from, say, a web site. • Design. I’ll be talking about process and deliverables speciﬁc to design.

UIE Web Application Summit, March 2008 Web Application Design.

UIE Web Application Summit, March 2008 What makes Web Apps Different?

UIE Web Application Summit, March 2008 What makes Web Apps Different? • An ongoing, organic, and iterative process.

UIE Web Application Summit, March 2008 What makes Web Apps Different? • An ongoing, organic, and iterative process. • Design is never complete.

UIE Web Application Summit, March 2008 What makes Web Apps Different? • An ongoing, organic, and iterative process. • Design is never complete. • Higher focus on interaction and tasks.

UIE Web Application Summit, March 2008 What makes Web Apps Different? • An ongoing, organic, and iterative process. • Design is never complete. • Higher focus on interaction and tasks. • Small changes can be very important.

UIE Web Application Summit, March 2008 What makes Web Apps Different? • An ongoing, organic, and iterative process. • Design is never complete. • Higher focus on interaction and tasks. • Small changes can be very important. • Observation of use is key.

UIE Web Application Summit, March 2008 Bottom-line: Web applications are never done. They evolve over time and require lots of iteration and deep observation to achieve the best possible design.

UIE Web Application Summit, March 2008 A quick, semantically unthreatening look at the process.

UIE Web Application Summit, March 2008 Initial Design Process

UIE Web Application Summit, March 2008 Initial Design Process Discovery

UIE Web Application Summit, March 2008 Initial Design Process Design and Discovery Development Decisions

UIE Web Application Summit, March 2008 Initial Design Process Design and Discovery Development Q/A Decisions

UIE Web Application Summit, March 2008 Iterative Design Process Design and Re-Discovery Development Q/A Decisions

UIE Web Application Summit, March 2008 Three kinds of deliverables.

UIE Web Application Summit, March 2008 Documenting Deliverables what? Project Briefs, Personas, Research and Goals Scenarios Activity Matrix, Task Flows, Use Cases, Screen Design and Development Descriptions, Wireframes, Decisions Prototypes, Mockups, Templates Validation, Iteration & Expert Reviews, Usability Maintenance Reports, Style Guides

UIE Web Application Summit, March 2008 Ideally you’d have a designer/researcher/developer who could observe and iterate in real time, all the time.

UIE Web Application Summit, March 2008 Real before ideal. A quick note about my approach.

UIE Web Application Summit, March 2008 ? Deliverables! Yeah! Wait, what? And why?

UIE Web Application Summit, March 2008 We need ways to accurately communicate design decisions. This is where deliverables come in.

UIE Web Application Summit, March 2008 Deliverables document design decisions.

UIE Web Application Summit, March 2008 We often use our deliverables to build consensus.

UIE Web Application Summit, March 2008

UIE Web Application Summit, March 2008 That’s a bad idea!

UIE Web Application Summit, March 2008 A document will never replace the know-how of a real person, yet they’re often asked to do so.

UIE Web Application Summit, March 2008 The quality of your deliverables should reﬂect your conﬁdence in your design decisions.

UIE Web Application Summit, March 2008 Deliverables can help build trust.

UIE Web Application Summit, March 2008 When in doubt, ask.

UIE Web Application Summit, March 2008 Bottom-line: The design process is not about your deliverables, it’s about solving problems. Deliverables are about communicating those solutions.

UIE Web Application Summit, March 2008 “Tell me and I forget, Show me, and I may remember. Involve me, and I will understand.” Confucius

UIE Web Application Summit, March 2008 Documenting Research and Goals

UIE Web Application Summit, March 2008 Deliverable: Project Brief Mingus Admin 920 N 34th Street, Suite 300 Seattle, Washington 98103 t. +1 206 545-0210 DESIGN PROJECT BRIEF f. +1 206 545-0212 January 15, 2008 info@blueflavor.com www.blueflavor.com Overview and Goals The purpose of this brief is to outline in a reasonable about of detail the project and plan for the Mingus Admin design project. There has already been a considerable about of scaffolding and framework development for Mingus and our goal is now to bring everything together in a “releasable” form. The first phase of that is a design for the admin interface. (Please see the attached creative brief and goals document for background and creative information on the overarching Mingus project.) Roles Project Manager: Keith Technical Direction: Garrett Lead Interaction Designer: Keith Lead Visual Designer: Tom Primary Stakeholder: Jeff

UIE Web Application Summit, March 2008 ? Why would I use a project brief?

UIE Web Application Summit, March 2008 Project Brief Mingus Admin 920 N 34th Street, Suite 300 DESIGN PROJECT BRIEF A very useful high level Seattle, Washington 98103 t. +1 206 545-0210 f. +1 206 545-0212 January 15, 2008 overview of your project info@blueflavor.com www.blueflavor.com Overview and Goals The purpose of this brief is to outline in a reasonable about of detail and a great introduction the project and plan for the Mingus Admin design project. There has already been a considerable about of scaffolding and framework development for Mingus and our goal is now to bring everything for your other design together in a “releasable” form. The first phase of that is a design for the admin interface. (Please see the attached creative brief and goals document for background documentation. and creative information on the overarching Mingus project.) Roles Project Manager: Keith Technical Direction: Garrett Lead Interaction Designer: Keith Lead Visual Designer: Tom Primary Stakeholder: Jeff Schedule Jan 22nd - Garrett will have the code base consolidated and we will begin our design phase. Keith will be leading this phase of the project. Jan 23rd - Keith, Tom and Jeff will have a meeting to work out the final personas and user goals. These will be based on the customer interviews conducted by Nick and Keith as well as consolidated feedback and will be finalized in this meeting. Jan 29th - Keith will meet with the team to present the final scenarios and task flows. Feb 15th - Keith will hand off the final interaction brief (screen descriptions, wireframes, etc.) to Tom to begin working on the initial 1 admin prototype.

UIE Web Application Summit, March 2008 Avoid “solutioneering.”

UIE Web Application Summit, March 2008 Advice for a project brief

UIE Web Application Summit, March 2008 Advice for a project brief • Keep it light and easy to digest.

UIE Web Application Summit, March 2008 Advice for a project brief • Keep it light and easy to digest. • Focus on problems, not features or solutions.

UIE Web Application Summit, March 2008 Advice for a project brief • Keep it light and easy to digest. • Focus on problems, not features or solutions. • Be sure to clearly set roles and expectations.

UIE Web Application Summit, March 2008 Advice for a project brief • Keep it light and easy to digest. • Focus on problems, not features or solutions. • Be sure to clearly set roles and expectations. • Make sure your team has reviewed the brief before you move on.

UIE Web Application Summit, March 2008 Bottom-line: A project brief should set expectations, focus on problems and get everyone on the same page.

UIE Web Application Summit, March 2008 Tricky Deliverable #1: Personas Skellington Interaction Brief Page 1 Jake Mike Carrie Personas Jake is a Mike is a Carrie These represent some of the people market- project runs a who will be using Skellington. They ing man- manager small will also become the “actors” in our ager for a and ac- clothing tasks flows and use cases. medium count boutique sized rep. for a in Den- univer- 12 person ver. sity. He’s interac- She’s in been at his job for 3 years now and tion design firm. He’s responsibilities dire need of a new Web site, yet has has been tasked with a complete include managing projects, dealing no clue where to begin. overhaul of the university’s student- with existing clients, leading market- She doesn't know how much it facing web sites. ing efforts, sales and much more. should cost, or even the kind of serv- He’s got a general idea of his budget He often doesn’t have time to explore ices she may need. She’s looking for and a pretty good idea of what serv- new work and the traditional RFP advice and hopefully some pointers ices he needs as well as what re- process is simply too much work. His to people who can help her out. sources he has in house. company is doing fairly well, so often Web Savvy - 6 out of 10 a “difficult” sale will be tossed aside-- His project has been pretty well regardless of how great the job Carrie represents a fairly typical user scoped, however, he still has ques- would be--if the process to land that that would come into the system tions and is looking for a full service job is to cumbersome. looking to explore, get advice and vendor who can help direct the proc- hopefully better scope out their pro- ess as well as do the work. Web Savvy - 8 out of 10 ject. Web Savvy - 7 out of 10 Mike represents the primary vendor Goals: persona. His goals would be cutting Jake is our primary “Looking for Serv- down on time spent doing biz dev - Get some general information about ices” user. He’s typical of the folks and bringing in clients who are a bet- budget, scope, timeframe for her that turn to the RFP process when ter “fit” for he and his team. project. looking for services. However, he is also educated and web savvy enough Goals: - Get started on finding help for her to look for a smarter, less time con- project! It’s all so confusing. - Cut down on time spent on biz dev. suming alternative. - Find the right vendor for her project - Connect with the right clients and Goals: in as easy a way as possible. projects. - Find the right vendor for his project - Educate potential clients about his in as easy a way as possible. services. - Get his process questions answered. - Never look at an RFP again.

UIE Web Application Summit, March 2008 Tricky Deliverable #1: Personas I’m Fuzzy! Skellington Interaction Brief Page 1 Jake Mike Carrie Personas Jake is a Mike is a Carrie These represent some of the people market- project runs a who will be using Skellington. They ing man- manager small will also become the “actors” in our ager for a and ac- clothing tasks flows and use cases. medium count boutique sized rep. for a in Den- univer- 12 person ver. sity. He’s interac- She’s in been at his job for 3 years now and tion design firm. He’s responsibilities dire need of a new Web site, yet has has been tasked with a complete include managing projects, dealing no clue where to begin. overhaul of the university’s student- with existing clients, leading market- She doesn't know how much it facing web sites. ing efforts, sales and much more. should cost, or even the kind of serv- He’s got a general idea of his budget He often doesn’t have time to explore ices she may need. She’s looking for and a pretty good idea of what serv- new work and the traditional RFP advice and hopefully some pointers ices he needs as well as what re- process is simply too much work. His to people who can help her out. sources he has in house. company is doing fairly well, so often Web Savvy - 6 out of 10 a “difficult” sale will be tossed aside-- His project has been pretty well regardless of how great the job Carrie represents a fairly typical user scoped, however, he still has ques- would be--if the process to land that that would come into the system tions and is looking for a full service job is to cumbersome. looking to explore, get advice and vendor who can help direct the proc- hopefully better scope out their pro- ess as well as do the work. Web Savvy - 8 out of 10 ject. Web Savvy - 7 out of 10 Mike represents the primary vendor Goals: persona. His goals would be cutting Jake is our primary “Looking for Serv- down on time spent doing biz dev - Get some general information about ices” user. He’s typical of the folks and bringing in clients who are a bet- budget, scope, timeframe for her that turn to the RFP process when ter “fit” for he and his team. project. looking for services. However, he is also educated and web savvy enough Goals: - Get started on finding help for her to look for a smarter, less time con- project! It’s all so confusing. - Cut down on time spent on biz dev. suming alternative. - Find the right vendor for her project - Connect with the right clients and Goals: in as easy a way as possible. projects. - Find the right vendor for his project - Educate potential clients about his in as easy a way as possible. services. - Get his process questions answered. - Never look at an RFP again.

UIE Web Application Summit, March 2008 ? Why would I use personas?

UIE Web Application Summit, March 2008 Jake Mike Personas Jake is a marketing man- Mike is a project manager Carrie runs a small ager for a and ac- clothin Personas are a good medium sized count rep. for a boutiqu in Den- way to illustrate your univer- 12 person ver. sity. He’s interac- She’s in been at his job for 3 years now and tion design firm. He’s responsibilities dire ne users, however they can has been tasked with a complete overhaul of the university’s student- include managing projects, dealing with existing clients, leading market- no clue often be more trouble facing web sites. ing efforts, sales and much more. She do should He’s got a general idea of his budget He often doesn’t have time to explore ices she than they’re worth. and a pretty good idea of what serv- new work and the traditional RFP ices he needs as well as what re- advice process is simply too much work. His to peop sources he has in house. company is doing fairly well, so often Web Sa a “difficult” sale will be tossed aside-- His project has been pretty well regardless of how great the job Carrie r scoped, however, he still has ques- would be--if the process to land that that wo tions and is looking for a full service job is to cumbersome. looking vendor who can help direct the proc- hopefu ess as well as do the work. Web Savvy - 8 out of 10 ject. Web Savvy - 7 out of 10 Mike represents the primary vendor Goals: persona. His goals would be cutting Jake is our primary “Looking for Serv- down on time spent doing biz dev - Get so ices” user. He’s typical of the folks and bringing in clients who are a bet- budge that turn to the RFP process when ter “fit” for he and his team. projec looking for services. However, he is also educated and web savvy enough Goals: - Get st to look for a smarter, less time con- projec - Cut down on time spent on biz dev. suming alternative. - Find t - Connect with the right clients and Goals: in as e projects.

UIE Web Application Summit, March 2008 Advice for personas

UIE Web Application Summit, March 2008 Advice for personas • It’s the research that matters here, not the deliverable.

UIE Web Application Summit, March 2008 Advice for personas • It’s the research that matters here, not the deliverable. • Base them on research and real data.

UIE Web Application Summit, March 2008 Advice for personas • It’s the research that matters here, not the deliverable. • Base them on research and real data. • Involve the whole team in their creation, from research on.

UIE Web Application Summit, March 2008 Advice for personas • It’s the research that matters here, not the deliverable. • Base them on research and real data. • Involve the whole team in their creation, from research on. • Focus on goals and activities, not personal details.

UIE Web Application Summit, March 2008 Advice for personas • It’s the research that matters here, not the deliverable. • Base them on research and real data. • Involve the whole team in their creation, from research on. • Focus on goals and activities, not personal details. • Combine them with user stories or scenarios.

UIE Web Application Summit, March 2008 Advice for personas • It’s the research that matters here, not the deliverable. • Base them on research and real data. • Involve the whole team in their creation, from research on. • Focus on goals and activities, not personal details. • Combine them with user stories or scenarios. • Don’t rely on them for decision-making or consensus-building.

UIE Web Application Summit, March 2008 Advice for personas • It’s the research that matters here, not the deliverable. • Base them on research and real data. • Involve the whole team in their creation, from research on. • Focus on goals and activities, not personal details. • Combine them with user stories or scenarios. • Don’t rely on them for decision-making or consensus-building. • Have any narrative text carefully edited.

UIE Web Application Summit, March 2008 Bottom-line: The act of creating personas has much more value than the personas themselves.

UIE Web Application Summit, March 2008 Deliverable: Scenarios (aka user stories)

UIE Web Application Summit, March 2008 ? Where is the value in user stories or scenarios?

UIE Web Application Summit, March 2008 Scenarios Scenarios are great for illustrating user goals and also fairly accessible and easy to digest.

UIE Web Application Summit, March 2008 Advice for scenarios

UIE Web Application Summit, March 2008 Advice for scenarios • Base them on research and real data.

UIE Web Application Summit, March 2008 Advice for scenarios • Base them on research and real data. • Involve the whole team in their creation, from research on.

UIE Web Application Summit, March 2008 Advice for scenarios • Base them on research and real data. • Involve the whole team in their creation, from research on. • Focus on tasks, activities and behavior.

UIE Web Application Summit, March 2008 Advice for scenarios • Base them on research and real data. • Involve the whole team in their creation, from research on. • Focus on tasks, activities and behavior. • Be as speciﬁc as you can.

UIE Web Application Summit, March 2008 Advice for scenarios • Base them on research and real data. • Involve the whole team in their creation, from research on. • Focus on tasks, activities and behavior. • Be as speciﬁc as you can. • Combine them with personas for a rich, high level view of user goals.

UIE Web Application Summit, March 2008 Bottom-line: User Scenarios are good for describing ﬂow and interaction at a high level.

UIE Web Application Summit, March 2008 You might try: Storyboards or Comics

UIE Web Application Summit, March 2008 Research and goals overview

UIE Web Application Summit, March 2008 Research and goals overview • The focus here should be on research and goal setting.

UIE Web Application Summit, March 2008 Research and goals overview • The focus here should be on research and goal setting. • The whole team should be involved as much as possible.

UIE Web Application Summit, March 2008 Research and goals overview • The focus here should be on research and goal setting. • The whole team should be involved as much as possible. • You shouldn’t be solving problems yet, just setting the table.

UIE Web Application Summit, March 2008 Research and goals overview • The focus here should be on research and goal setting. • The whole team should be involved as much as possible. • You shouldn’t be solving problems yet, just setting the table. • You should be getting as much real data as you can.

UIE Web Application Summit, March 2008 Bottom-line: A successful ﬁrst phase will have your team informed about business and user goals for your app and ready to begin problem solving.

UIE Web Application Summit, March 2008 Documenting Design Decisions

UIE Web Application Summit, March 2008 Deliverable: Use Cases (aka user ﬂows, task ﬂows)

UIE Web Application Summit, March 2008 ? Why would I create use cases?

UIE Web Application Summit, March 2008 Use Cases Use cases are great for describing detailed interactions and can be a very useful deliverable for both designers and developers.

UIE Web Application Summit, March 2008 Advice for use cases.

UIE Web Application Summit, March 2008 Advice for use cases. • Take your time, really think and be as detailed as you can.

UIE Web Application Summit, March 2008 Advice for use cases. • Take your time, really think and be as detailed as you can. • Be sure and address all user goals.

UIE Web Application Summit, March 2008 Advice for use cases. • Take your time, really think and be as detailed as you can. • Be sure and address all user goals. • Don’t forget to include errors and multiple ways of doing things.

UIE Web Application Summit, March 2008 Advice for use cases. • Take your time, really think and be as detailed as you can. • Be sure and address all user goals. • Don’t forget to include errors and multiple ways of doing things. • Focus on tasks and activities, not users themselves.

UIE Web Application Summit, March 2008 Advice for use cases. • Take your time, really think and be as detailed as you can. • Be sure and address all user goals. • Don’t forget to include errors and multiple ways of doing things. • Focus on tasks and activities, not users themselves. • List tasks and activities and describe user behavior.

UIE Web Application Summit, March 2008 Bottom-line: Use cases are a great way of describing detailed interaction. They’re also the ﬁrst place where your decisions will be documented. Give them the time and thought they deserve.

UIE Web Application Summit, March 2008 Deliverable: Screen Description Diagrams screen description diagram 1 2 3 Inbox Screen Item Creation Field “Action Bar” Recent Changes Log The purpose of the inbox screen is to capture incoming items and “process” There will need to be a quick way for This will provide a drop down action There will be a running log (no more them into the system. Here you will a user to create a new item (which list that will enable the user to “ac- than 5 items) showing recent see new items, new requests, proc- defaults to a note.) This will be a sim- tion” or bulk edit checked items. Ac- changes to the system. essed items (before they’re “swept” ple text entry field with associated tions include “Done” “Defer” “Dele- , , into the system) and deferred items javascript “listener” to help the user gate” (not sure how this would work) waiting to “tickle” their way in. know exactly what they’re creating. “Delete” and “Committed/Someday Maybe.” This describes the elements and basic interaction of the Inbox screen. It’s Inbox intended to give a general overview A primary element of the Inbox “Clean Up” Button of what the user will see on the page. screen, is (surprise) the Inbox. The There will be a button, part of the Inbox is a container. Inside the inbox action bar probably, that will “sweep” This describes the “in use” state. unprocessed items and requests will all processed items into the system. Things would appear a bit differently be listed (and bolded) as will proc- were there nothing in the inbox, for essed items (regular weight) and de- example. “Go to Today” ferred items (grayed out.) In order to save time and space I’ve There should be prominent place- left out global items such as global ment of a button that takes a user to Inbox Items the today screen. This will be made navigation, the logo, etc. Inside the inbox will be items. These even more prominent by text in- will be listed with a title and an icon structing the user to go to the today that shows the type of item. There screen when the inbox is empty. will also be a check box next to each item, so that a user can select it (and apply batch actions to it.) and there’ll be an “Edit” link/icon that will allow for inline editing of the item (similar to how Basecamp does milestone editing.)

UIE Web Application Summit, March 2008 ? Why would I screen descriptions?

UIE Web Application Summit, March 2008 1 2 3 Screen Item Creation Field There will need to be a quick way for a user to create a new item (which “Action Bar” This will provide a drop down action list that will enable the user to “ac- Recent Change There will be a running than 5 items) showing Descriptions defaults to a note.) This will be a sim- tion” or bulk edit checked items. Ac- changes to the system ple text entry field with associated tions include “Done” “Defer” “Dele- , , javascript “listener” to help the user gate” (not sure how this would work) know exactly what they’re creating. “Delete” and “Committed/Someday Maybe.” Inbox Screen Description A primary element of the Inbox screen, is (surprise) the Inbox. The “Clean Up” Button There will be a button, part of the Diagrams are a great Inbox is a container. Inside the inbox action bar probably, that will “sweep” unprocessed items and requests will all processed items into the system. be listed (and bolded) as will proc- deliverable for essed items (regular weight) and deferred items (grayed out.) “Go to Today” There should be prominent place- describing layout and Inbox Items ment of a button that takes a user to the today screen. This will be made Inside the inbox will be items. These even more prominent by text in- visual elements and will be listed with a title and an icon that shows the type of item. There structing the user to go to the today screen when the inbox is empty. tying them to will also be a check box next to each item, so that a user can select it (and apply batch actions to it.) and there’ll interaction and goals. be an “Edit” link/icon that will allow for inline editing of the item (similar to how Basecamp does milestone editing.) Highest Priority

UIE Web Application Summit, March 2008 Advice for Screen Descriptions

UIE Web Application Summit, March 2008 Advice for Screen Descriptions • Prioritize elements, this will be helpful if you have to cut later.

UIE Web Application Summit, March 2008 Advice for Screen Descriptions • Prioritize elements, this will be helpful if you have to cut later. • Don’t worry about visual speciﬁcs.

UIE Web Application Summit, March 2008 Advice for Screen Descriptions • Prioritize elements, this will be helpful if you have to cut later. • Don’t worry about visual speciﬁcs. • Describe how elements reﬂect user goals.

UIE Web Application Summit, March 2008 Advice for Screen Descriptions • Prioritize elements, this will be helpful if you have to cut later. • Don’t worry about visual speciﬁcs. • Describe how elements reﬂect user goals. • Use “real” text and examples.

UIE Web Application Summit, March 2008 Advice for Screen Descriptions • Prioritize elements, this will be helpful if you have to cut later. • Don’t worry about visual speciﬁcs. • Describe how elements reﬂect user goals. • Use “real” text and examples. • Be verbose, don’t skimp on the details.

UIE Web Application Summit, March 2008 Bottom-line: Screen descriptions are a very useful, yet low-ﬁdelity, low risk way of describing detailed layout and interaction.

UIE Web Application Summit, March 2008 Tricky Deliverable #2: Wireframes

UIE Web Application Summit, March 2008 Tricky Deliverable #2: Wireframes BEWARE!

UIE Web Application Summit, March 2008 Tricky Deliverable #2: Wireframes

UIE Web Application Summit, March 2008 Tricky Deliverable #2: Wireframes Better!

UIE Web Application Summit, March 2008 ? Why would I use wireframes?

UIE Web Application Summit, March 2008 Wireframes Wireframes are tricky, but can be amazingly useful if done correctly. They can be great way of visually showing interaction and layout together.

UIE Web Application Summit, March 2008 Advice for wireframes

UIE Web Application Summit, March 2008 Advice for wireframes • Be as real as you can. No greeked text.

UIE Web Application Summit, March 2008 Advice for wireframes • Be as real as you can. No greeked text. • Set expectations. Wireframes are not a ﬁnished design or look and feel.

UIE Web Application Summit, March 2008 Advice for wireframes • Be as real as you can. No greeked text. • Set expectations. Wireframes are not a ﬁnished design or look and feel. • Annotate thoroughly to describe interaction.

UIE Web Application Summit, March 2008 Advice for wireframes • Be as real as you can. No greeked text. • Set expectations. Wireframes are not a ﬁnished design or look and feel. • Annotate thoroughly to describe interaction. • Annotate to answer potential questions that’ll come up later on.

UIE Web Application Summit, March 2008 Advice for wireframes • Be as real as you can. No greeked text. • Set expectations. Wireframes are not a ﬁnished design or look and feel. • Annotate thoroughly to describe interaction. • Annotate to answer potential questions that’ll come up later on. • Be as speciﬁc as you can.

UIE Web Application Summit, March 2008 Advice for wireframes • Be as real as you can. No greeked text. • Set expectations. Wireframes are not a ﬁnished design or look and feel. • Annotate thoroughly to describe interaction. • Annotate to answer potential questions that’ll come up later on. • Be as speciﬁc as you can. • Don’t get caught in a nasty feedback/revision loop.

UIE Web Application Summit, March 2008 Advice for wireframes • Be as real as you can. No greeked text. • Set expectations. Wireframes are not a ﬁnished design or look and feel. • Annotate thoroughly to describe interaction. • Annotate to answer potential questions that’ll come up later on. • Be as speciﬁc as you can. • Don’t get caught in a nasty feedback/revision loop. • Tie them back to previous deliverables to reinforce decisions and thinking.

UIE Web Application Summit, March 2008 ? What about paper prototyping?

UIE Web Application Summit, March 2008 Bottom-line: When done at the right ﬁdelity and annotated thoroughly to describe interaction, wireframes are a great way of documenting design decisions for multiple audiences.

UIE Web Application Summit, March 2008 Combine layout and interaction.

UIE Web Application Summit, March 2008 You might try: A Design Description Document Services Screen Goals Dashboard Services Proposal Creator Help Showcase Value Proposition 1 Use high level value terms like "Invent, Improve, Refresh" to tell clients what we do in non- Services technical terms. Clickable. Showcase Service Areas A Invent Improve Refresh 2 Give speciﬁc areas of focus like "Websites, Applications, Mobile" to inform clients of our specialities. Clickable. Provide Service Listing B Websites Applications Mobile 3 Allow clients to browse in place a complete listing of our services. Notes Value Proposition List A Browse All Services Provide icon and short description to support primary goal. Strategy C Web Design D CTA Service Area List Interaction Design B Web design is one of Blue Flavor's key service offerings, Contact Us Provide icon and short description to support Web Design G secondary goal. Development fold Service Categories Mobile C Provide list of service categories to browse in Content Web-based Design for place. E Publishing Marketing Accessibility Some text goes here. Some text goes here. Service Title & Description D

UIE Web Application Summit, March 2008 ? What is a design description document?

UIE Web Application Summit, March 2008 Services Screen Design Goals Dashboard Services Proposal Creator Help Showcase Value Proposition 1 Use high level value terms like "Invent, Improve, Refresh" to tell clients what we do in non- Services technical terms. Clickable. Description A Invent Improve Refresh 2 Showcase Service Areas Give speciﬁc areas of focus like "Websites, Applications, Mobile" to inform clients of our specialities. Clickable. Document B Websites Applications Mobile 3 Provide Service Listing Allow clients to browse in place a complete listing of our services. Notes DDDs combine the best A Value Proposition List Browse All Services Provide icon and short description to support of Screen Descriptions Strategy Web Design primary goal. C CTA and Wireframes into one D Service Area List Interaction Design B Web design is one of Blue Flavor's key service offerings, Contact Us Provide icon and short description to support Web Design G secondary goal. cohesive and very Development Mobile fold C Service Categories Provide list of service categories to browse in informative package. Content Web-based Design for place. E Publishing Marketing Accessibility Some text goes here. Some text goes here. Service Title & Description D Performance Give title and short description of selected Related Info service category. Usability Blog Posts Sub-Services F E Clients we've helped in this area Show sub-services or attributes related to Client Name Client Name Client Name service in view. Non-clickable. Client Name Client Name Client Name Related Clients Client Name Client Name F Show a listing of clients we've helped with this service * http://www.thinkvitamin.com/features/design/ footer deliverables-that-work-design-description- Sidebar G documents 975 px Provide a large CTA directed to contact form. Link to related articles based on client or topic.

UIE Web Application Summit, March 2008 You might try HTML or Flash Prototypes.

UIE Web Application Summit, March 2008 Composites

UIE Web Application Summit, March 2008 Documenting Validation, Iteration & Maintenance

UIE Web Application Summit, March 2008 Deliverable: Usability Reports (aka expert reviews, heuristic reviews)

UIE Web Application Summit, March 2008 ? Why would I use usability reports?

UIE Web Application Summit, March 2008 Usability Reports Usability reports (or expert reviews, etc.) are a good way to document ongoing design decisions based on research.

UIE Web Application Summit, March 2008 Advice for usability reports

UIE Web Application Summit, March 2008 Advice for usability reports • Be thorough. Document as much as you can.

UIE Web Application Summit, March 2008 Advice for usability reports • Be thorough. Document as much as you can. • Don’t rely on text alone. Try multimedia reports (images, video.)

UIE Web Application Summit, March 2008 Advice for usability reports • Be thorough. Document as much as you can. • Don’t rely on text alone. Try multimedia reports (images, video.) • Provide speciﬁc recommendations.

UIE Web Application Summit, March 2008 Advice for usability reports • Be thorough. Document as much as you can. • Don’t rely on text alone. Try multimedia reports (images, video.) • Provide speciﬁc recommendations. • Don’t be afraid to revisit and re-evaluate original goals.

UIE Web Application Summit, March 2008 Advice for usability reports • Be thorough. Document as much as you can. • Don’t rely on text alone. Try multimedia reports (images, video.) • Provide speciﬁc recommendations. • Don’t be afraid to revisit and re-evaluate original goals. • Include your designers and developers in the testing process.

UIE Web Application Summit, March 2008 Bottom-line: Usability testing (and the subsequent reports) are essential in ensuring quality and usability over time.

UIE Web Application Summit, March 2008 Deliverable: Style Guides

UIE Web Application Summit, March 2008 ? Why would I use style guides?

UIE Web Application Summit, March 2008 Style Guide A style guide is a useful tool used to keep your application consistant through ongoing iteration.

UIE Web Application Summit, March 2008 Advice for style guides

UIE Web Application Summit, March 2008 Advice for style guides • Be thorough, but don’t overcomplicate an already complicated task.

UIE Web Application Summit, March 2008 Advice for style guides • Be thorough, but don’t overcomplicate an already complicated task. • Make your style guide easy to edit.

UIE Web Application Summit, March 2008 Advice for style guides • Be thorough, but don’t overcomplicate an already complicated task. • Make your style guide easy to edit. • Don’t limit the guide to look and feel, be sure to describe behavior, etc.

UIE Web Application Summit, March 2008 Advice for style guides • Be thorough, but don’t overcomplicate an already complicated task. • Make your style guide easy to edit. • Don’t limit the guide to look and feel, be sure to describe behavior, etc. • Be sure and keep track of versions/revisions.

UIE Web Application Summit, March 2008 Advice for style guides • Be thorough, but don’t overcomplicate an already complicated task. • Make your style guide easy to edit. • Don’t limit the guide to look and feel, be sure to describe behavior, etc. • Be sure and keep track of versions/revisions. • Assign an “owner” to your style guide and run changes through them.

UIE Web Application Summit, March 2008 Advice for style guides • Be thorough, but don’t overcomplicate an already complicated task. • Make your style guide easy to edit. • Don’t limit the guide to look and feel, be sure to describe behavior, etc. • Be sure and keep track of versions/revisions. • Assign an “owner” to your style guide and run changes through them. • Be sure it’s a working document; clear and easy to follow.

UIE Web Application Summit, March 2008 Advice for style guides • Be thorough, but don’t overcomplicate an already complicated task. • Make your style guide easy to edit. • Don’t limit the guide to look and feel, be sure to describe behavior, etc. • Be sure and keep track of versions/revisions. • Assign an “owner” to your style guide and run changes through them. • Be sure it’s a working document; clear and easy to follow. • Include previous deliverables as reference materials.

UIE Web Application Summit, March 2008 Advice for style guides • Be thorough, but don’t overcomplicate an already complicated task. • Make your style guide easy to edit. • Don’t limit the guide to look and feel, be sure to describe behavior, etc. • Be sure and keep track of versions/revisions. • Assign an “owner” to your style guide and run changes through them. • Be sure it’s a working document; clear and easy to follow. • Include previous deliverables as reference materials. • Don’t let it get stale. Review your style guide frequently.

UIE Web Application Summit, March 2008 Bottom-line: A good style guide can provide guidance for maintenance and a history of your design decisions whenever you need it, thus saving you lots of time and re- work.

UIE Web Application Summit, March 2008 Validation, iteration and maintenance overview

UIE Web Application Summit, March 2008 Validation, iteration and maintenance overview • Web applications have living designs and will change often.

UIE Web Application Summit, March 2008 Validation, iteration and maintenance overview • Web applications have living designs and will change often. • Validating your design decisions and iterating appropriately is key.

UIE Web Application Summit, March 2008 Validation, iteration and maintenance overview • Web applications have living designs and will change often. • Validating your design decisions and iterating appropriately is key. • It’s important to have a living record of your design decisions.

UIE Web Application Summit, March 2008 Bottom-line: Launching your application is just the beginning. Be sure to have a process (and associated deliverables) in place for all the hard work that comes after launch.

UIE Web Application Summit, March 2008 Lessons learned

UIE Web Application Summit, March 2008 Lessons learned • Deliverables document design decisions.

UIE Web Application Summit, March 2008 Lessons learned • Deliverables document design decisions. • Deliverables aren’t usually good for building consensus.

UIE Web Application Summit, March 2008 Lessons learned • Deliverables document design decisions. • Deliverables aren’t usually good for building consensus. • Don’t treat your deliverables as your ﬁnal product.

UIE Web Application Summit, March 2008 Lessons learned • Deliverables document design decisions. • Deliverables aren’t usually good for building consensus. • Don’t treat your deliverables as your ﬁnal product. • Quality is important. A good deliverable will help build trust.

UIE Web Application Summit, March 2008 Lessons learned • Deliverables document design decisions. • Deliverables aren’t usually good for building consensus. • Don’t treat your deliverables as your ﬁnal product. • Quality is important. A good deliverable will help build trust. • Involve people in the process and the creation of your deliverables.

UIE Web Application Summit, March 2008 Lessons learned • Deliverables document design decisions. • Deliverables aren’t usually good for building consensus. • Don’t treat your deliverables as your ﬁnal product. • Quality is important. A good deliverable will help build trust. • Involve people in the process and the creation of your deliverables. • Lose deliverables that don’t document or inform.

UIE Web Application Summit, March 2008 Lessons learned • Deliverables document design decisions. • Deliverables aren’t usually good for building consensus. • Don’t treat your deliverables as your ﬁnal product. • Quality is important. A good deliverable will help build trust. • Involve people in the process and the creation of your deliverables. • Lose deliverables that don’t document or inform. • Deliverables can’t completely replace the knowledge of real people.

UIE Web Application Summit, March 2008 Lessons learned, cont.

UIE Web Application Summit, March 2008 Lessons learned, cont. • Make them as real as possible. Use real language.

UIE Web Application Summit, March 2008 Lessons learned, cont. • Make them as real as possible. Use real language. • Have your deliverables edited. Typos can distract or worse.

UIE Web Application Summit, March 2008 Lessons learned, cont. • Make them as real as possible. Use real language. • Have your deliverables edited. Typos can distract or worse. • Always move forward. Constant revision isn’t a good idea.

UIE Web Application Summit, March 2008 Lessons learned, cont. • Make them as real as possible. Use real language. • Have your deliverables edited. Typos can distract or worse. • Always move forward. Constant revision isn’t a good idea. • Build on previous deliverables.

UIE Web Application Summit, March 2008 Lessons learned, cont. • Make them as real as possible. Use real language. • Have your deliverables edited. Typos can distract or worse. • Always move forward. Constant revision isn’t a good idea. • Build on previous deliverables. • Avoid getting caught up in semantic debates.

UIE Web Application Summit, March 2008 One last bit of advice: be open-minded and creative!

UIE Web Application Summit, March 2008 Thanks!

UIE Web Application Summit, March 2008 ?

UIE Web Application Summit, March 2008 Making The Translation: Critical Web App Design Deliverables D. Keith Robinson, March 26, 2008

Making The Translation: Critical Web App Design Deliverables

by dkr on Jun 23, 2009

Accessibility

Upload Details

Usage Rights

Statistics

Making The Translation: Critical Web App Design Deliverables Presentation Transcript