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


Introduction


D. Keith Robinson


D. Keith Robinson
• Principle & Creative Director for Blue Flavor


D. Keith Robinson
• Based in Seattle, Washington


D. Keith Robinson
• Over 12 years designing for web, etc.


D. Keith Robinson
• Has worked internally for large companies (Boeing, Children’s
Hospital Seattle)


D. Keith Robinson
Hospital Seattle)

• Has worked as a consultant for companies large and small.


D. Keith Robinson
Hospital Seattle)

• Has worked as a consultant for companies large and small.
• Recent clients include Tipped.co.uk, HP, Motive Interactive


Critical. Web App. Design.


• Critical.


• Critical.
Documenting your design decisions is important.


• Critical.

• Web Application.


• Critical.

The design process you use for a Web app will differ greatly
from, say, a web site.


• Critical.


• Design.


• Critical.


• Design.
I’ll be talking about process and deliverables speciﬁc to design.


Web Application Design.


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.


• Small changes can be very important.
• Observation of use is key.


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.


A quick, semantically
unthreatening look at the
process.


Initial Design Process



Discovery



Design and
Discovery Development
Decisions



Design and
Discovery Development Q/A
Decisions


Iterative Design Process

Design and
Re-Discovery Development Q/A
Decisions


Three kinds of deliverables.


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


Ideally you’d have a designer/researcher/developer
who could observe and iterate in real time, all the
time.


Real before ideal.
A quick note about my approach.


?
Deliverables! Yeah!
Wait, what? And why?


We need ways to accurately communicate design
decisions. This is where deliverables come in.


Deliverables document
design decisions.


We often use our deliverables to build consensus.


That’s a
bad idea!


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


The quality of your deliverables should reﬂect your
conﬁdence in your design decisions.


Deliverables can help
build trust.


When in doubt, ask.


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


“Tell me and I forget, Show me, and I
may remember. Involve me, and I will
understand.” Confucius


Documenting Research and
Goals


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


?
Why would I use a
project brief?


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.


Avoid “solutioneering.”


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.


• Be sure to clearly set roles and expectations.
• Make sure your team has reviewed the brief before you move on.


Bottom-line:
A project brief should set
expectations, focus on problems
and get everyone on the same
page.


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.


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-
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.
Web Savvy - 6 out of 10
regardless of how great the job Carrie represents a fairly typical user
would be--if the process to land that that would come into the system
job is to cumbersome. looking to explore, get advice and
hopefully better scope out their pro-
ject.
Goals:
down on time spent doing biz dev - Get some general information about
and bringing in clients who are a bet- budget, scope, timeframe for her
ter “fit” for he and his team. project.
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.
suming alternative.
- Find the right vendor for her project
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.


?
Why would I use
personas?


Jake Mike
Personas Jake is a
market-
ing 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
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
Web Sa
regardless of how great the job Carrie r
would be--if the process to land that that wo
job is to cumbersome. looking
hopefu
ject.
Goals:
down on time spent doing biz dev - Get so
and bringing in clients who are a bet- budge
ter “fit” for he and his team. projec
also educated and web savvy enough Goals: - Get st
to look for a smarter, less time con- projec
suming alternative.
- Find t
Goals: in as e
projects.


Advice for personas


Advice for personas
• It’s the research that matters here, not the deliverable.


Advice for personas
• Base them on research and real data.


Advice for personas
• Involve the whole team in their creation, from research on.


Advice for personas
• Focus on goals and activities, not personal details.


Advice for personas
• Combine them with user stories or scenarios.


Advice for personas
• Don’t rely on them for decision-making or consensus-building.


Advice for personas
• Don’t rely on them for decision-making or consensus-building.
• Have any narrative text carefully edited.


Bottom-line:
The act of creating personas has
much more value than the
personas themselves.


Deliverable: Scenarios
(aka user stories)


?
Where is the value in
user stories or
scenarios?


Scenarios
Scenarios are great for
illustrating user goals
and also fairly
accessible and easy to
digest.


Advice for scenarios


• 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.


Bottom-line:
User Scenarios are good for
describing ﬂow and interaction at
a high level.


You might try: Storyboards or
Comics


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 shouldn’t be solving problems yet, just setting the table.
• You should be getting as much real data as you can.


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.


Documenting Design Decisions


Deliverable: Use Cases
(aka user ﬂows, task ﬂows)


?
Why would I create use
cases?


Use Cases
Use cases are great for
describing detailed
interactions and can be
a very useful
deliverable for both
designers and
developers.


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.


• Focus on tasks and activities, not users themselves.
• List tasks and activities and describe user behavior.


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.


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.)


?
Why would I screen
descriptions?


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 de-
ferred 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


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.


• Use “real” text and examples.
• Be verbose, don’t skimp on the details.


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


Tricky Deliverable #2: Wireframes


BEWARE!


Better!


?
Why would I use
wireframes?


Wireframes
Wireframes are tricky,
but can be amazingly
useful if done correctly.
They can be great way
of visually showing
interaction and layout
together.


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.


• Don’t get caught in a nasty feedback/revision loop.


• Don’t get caught in a nasty feedback/revision loop.
• Tie them back to previous deliverables to reinforce decisions and thinking.


?
What about paper
prototyping?


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.


Combine layout and
interaction.


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


?
What is a design
description document?

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.


You might try HTML or
Flash Prototypes.


Composites


Documenting Validation,
Iteration & Maintenance


Deliverable: Usability Reports
(aka expert reviews, heuristic reviews)


?
Why would I use
usability reports?


Usability
Reports
Usability reports (or
expert reviews, etc.) are
a good way to
document ongoing
design decisions based
on research.


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.


• Don’t be afraid to revisit and re-evaluate original goals.
• Include your designers and developers in the testing process.


Bottom-line:
Usability testing (and the
subsequent reports) are essential
in ensuring quality and usability
over time.


Deliverable: Style Guides


?
Why would I use style
guides?


Style Guide
A style guide is a useful
tool used to keep your
application consistant
through ongoing
iteration.


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.


• Include previous deliverables as reference materials.
• Don’t let it get stale. Review your style guide frequently.


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.


Validation, iteration and maintenance overview



• Web applications have living designs and will change often.



• Validating your design decisions and iterating appropriately is key.



• Validating your design decisions and iterating appropriately is key.
• It’s important to have a living record of your design decisions.


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.


Lessons learned


Lessons learned
• Deliverables document design decisions.


Lessons learned
• Deliverables aren’t usually good for building consensus.


Lessons learned
• Don’t treat your deliverables as your ﬁnal product.


Lessons learned
• Quality is important. A good deliverable will help build trust.


Lessons learned
• Involve people in the process and the creation of your deliverables.


Lessons learned
• Lose deliverables that don’t document or inform.


Lessons learned
• Lose deliverables that don’t document or inform.
• Deliverables can’t completely replace the knowledge of real people.


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.


• Build on previous deliverables.
• Avoid getting caught up in semantic debates.


One last bit of advice: be
open-minded and
creative!


Thanks!


?

Making The Translation: Critical Web App Design Deliverables

Recommended

Recommended

More Related Content

Similar to Making The Translation: Critical Web App Design Deliverables

Similar to Making The Translation: Critical Web App Design Deliverables (20)

Making The Translation: Critical Web App Design Deliverables