UIE Web Application Summit, March 2008




Making The Translation:
Critical Web App Design Deliverables
D. Keith Robinson,...
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
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 Se...
UIE Web Application Summit, March 2008




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




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




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




D. Keith Robinson
• Principle & Creative Director for Blue Flavor
• Based in Se...
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 im...
UIE Web Application Summit, March 2008




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




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




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




Critical. Web App. Design.
• Critical.
 Documenting your design decisions is im...
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.
• ...
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.
• ...
UIE Web Application Summit, March 2008




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




Bottom-line:
Web applications are never done.
They evolve over time and
require...
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
 ...
UIE Web Application Summit, March 2008



     Initial Design Process



             Design and
Discovery   Development  ...
UIE Web Application Summit, March 2008



    Iterative Design Process



                Design and
Re-Discovery   Develo...
UIE Web Application Summit, March 2008




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




 Documenting
                             Deliverables
    what?

             ...
UIE Web Application Summit, March 2008




Ideally you’d have a designer/researcher/developer
 who could observe and itera...
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 delivera...
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 ofte...
UIE Web Application Summit, March 2008



The quality of your deliverables should reflect your
      confidence in your desi...
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
solv...
UIE Web Application Summit, March 2008




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




Documenting Research and
         Goals
UIE Web Application Summit, March 2008




Deliverable: Project Brief

                                                   ...
UIE Web Application Summit, March 2008




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




Project Brief                                                                  ...
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 probl...
UIE Web Application Summit, March 2008




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




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




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




Tricky Deliverable #1: Personas
                                               ...
UIE Web Application Summit, March 2008




Tricky Deliverable #1: Personas
                                               ...
UIE Web Application Summit, March 2008




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


                          Jake                                     Mike
Personas ...
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....
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....
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....
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




Bottom-line:
The act of creating personas has
much more value than the
personas...
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
acces...
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...
UIE Web Application Summit, March 2008




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




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




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




Bottom-line:
User Scenarios are good for
describing flow and interaction at
a hi...
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 set...
UIE Web Application Summit, March 2008




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




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




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




Bottom-line:
A successful first phase will have
your team informed about
busines...
UIE Web Application Summit, March 2008




Documenting Design Decisions
UIE Web Application Summit, March 2008




Deliverable: Use Cases
  (aka user flows, task flows)
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...
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 ...
UIE Web Application Summit, March 2008




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




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




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




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




Bottom-line:
Use cases are a great way of
describing detailed interaction.
They...
UIE Web Application Summit, March 2008




 Deliverable: Screen
Description Diagrams
                                     ...
UIE Web Application Summit, March 2008




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


                         1                                          2            ...
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 y...
UIE Web Application Summit, March 2008




Advice for Screen Descriptions
• Prioritize elements, this will be helpful if y...
UIE Web Application Summit, March 2008




Advice for Screen Descriptions
• Prioritize elements, this will be helpful if y...
UIE Web Application Summit, March 2008




Advice for Screen Descriptions
• Prioritize elements, this will be helpful if y...
UIE Web Application Summit, March 2008




Advice for Screen Descriptions
• Prioritize elements, this will be helpful if y...
UIE Web Application Summit, March 2008




Bottom-line:
Screen descriptions are a very
useful, yet low-fidelity, low risk
w...
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
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...
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 expectati...
UIE Web Application Summit, March 2008




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




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




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




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




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




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




Bottom-line:
When done at the right fidelity
and annotated thoroughly to
describ...
UIE Web Application Summit, March 2008




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




      You might try: A Design
      Description Document
                      ...
UIE Web Application Summit, March 2008




       ?
   What is a design
description document?
UIE Web Application Summit, March 2008
                                                                                   ...
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...
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’...
UIE Web Application Summit, March 2008




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




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




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




Bottom-line:
Usability testing (and the
subsequent reports) are essential
in en...
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 consis...
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 comp...
UIE Web Application Summit, March 2008




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




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




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




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




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




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




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




Bottom-line:
A good style guide can provide
guidance for maintenance and a
hist...
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 ...
UIE Web Application Summit, March 2008




Validation, iteration and maintenance overview

• Web applications have living ...
UIE Web Application Summit, March 2008




Validation, iteration and maintenance overview

• Web applications have living ...
UIE Web Application Summit, March 2008




Bottom-line:
Launching your application is just
the beginning. Be sure to have ...
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...
UIE Web Application Summit, March 2008




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




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




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




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




Lessons learned
• Deliverables document design decisions.
• Deliverables aren’t...
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.
• Ha...
UIE Web Application Summit, March 2008




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




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




Lessons learned, cont.
• Make them as real as possible. Use real language.
• Ha...
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,...
Upcoming SlideShare
Loading in...5
×

Making The Translation: Critical Web App Design Deliverables

3,615

Published on

1 Comment
8 Likes
Statistics
Notes
No Downloads
Views
Total Views
3,615
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
20
Comments
1
Likes
8
Embeds 0
No embeds

No notes for slide

Making The Translation: Critical Web App Design Deliverables

  1. 1. UIE Web Application Summit, March 2008 Making The Translation: Critical Web App Design Deliverables D. Keith Robinson, March 26, 2008
  2. 2. UIE Web Application Summit, March 2008 Introduction
  3. 3. UIE Web Application Summit, March 2008 D. Keith Robinson
  4. 4. UIE Web Application Summit, March 2008 D. Keith Robinson
  5. 5. UIE Web Application Summit, March 2008 D. Keith Robinson • Principle & Creative Director for Blue Flavor
  6. 6. UIE Web Application Summit, March 2008 D. Keith Robinson • Principle & Creative Director for Blue Flavor • Based in Seattle, Washington
  7. 7. 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.
  8. 8. 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)
  9. 9. 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.
  10. 10. 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
  11. 11. UIE Web Application Summit, March 2008 Critical. Web App. Design.
  12. 12. UIE Web Application Summit, March 2008 Critical. Web App. Design. • Critical.
  13. 13. UIE Web Application Summit, March 2008 Critical. Web App. Design. • Critical. Documenting your design decisions is important.
  14. 14. UIE Web Application Summit, March 2008 Critical. Web App. Design. • Critical. Documenting your design decisions is important. • Web Application.
  15. 15. 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.
  16. 16. 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.
  17. 17. 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 specific to design.
  18. 18. UIE Web Application Summit, March 2008 Web Application Design.
  19. 19. UIE Web Application Summit, March 2008 What makes Web Apps Different?
  20. 20. UIE Web Application Summit, March 2008 What makes Web Apps Different? • An ongoing, organic, and iterative process.
  21. 21. UIE Web Application Summit, March 2008 What makes Web Apps Different? • An ongoing, organic, and iterative process. • Design is never complete.
  22. 22. 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.
  23. 23. 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.
  24. 24. 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.
  25. 25. 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.
  26. 26. UIE Web Application Summit, March 2008 A quick, semantically unthreatening look at the process.
  27. 27. UIE Web Application Summit, March 2008 Initial Design Process
  28. 28. UIE Web Application Summit, March 2008 Initial Design Process Discovery
  29. 29. UIE Web Application Summit, March 2008 Initial Design Process Design and Discovery Development Decisions
  30. 30. UIE Web Application Summit, March 2008 Initial Design Process Design and Discovery Development Q/A Decisions
  31. 31. UIE Web Application Summit, March 2008 Iterative Design Process Design and Re-Discovery Development Q/A Decisions
  32. 32. UIE Web Application Summit, March 2008 Three kinds of deliverables.
  33. 33. 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
  34. 34. 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.
  35. 35. UIE Web Application Summit, March 2008 Real before ideal. A quick note about my approach.
  36. 36. UIE Web Application Summit, March 2008 ? Deliverables! Yeah! Wait, what? And why?
  37. 37. UIE Web Application Summit, March 2008 We need ways to accurately communicate design decisions. This is where deliverables come in.
  38. 38. UIE Web Application Summit, March 2008 Deliverables document design decisions.
  39. 39. UIE Web Application Summit, March 2008 We often use our deliverables to build consensus.
  40. 40. UIE Web Application Summit, March 2008
  41. 41. UIE Web Application Summit, March 2008 That’s a bad idea!
  42. 42. 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.
  43. 43. UIE Web Application Summit, March 2008 The quality of your deliverables should reflect your confidence in your design decisions.
  44. 44. UIE Web Application Summit, March 2008 Deliverables can help build trust.
  45. 45. UIE Web Application Summit, March 2008 When in doubt, ask.
  46. 46. 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.
  47. 47. UIE Web Application Summit, March 2008 “Tell me and I forget, Show me, and I may remember. Involve me, and I will understand.” Confucius
  48. 48. UIE Web Application Summit, March 2008 Documenting Research and Goals
  49. 49. 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
  50. 50. UIE Web Application Summit, March 2008 ? Why would I use a project brief?
  51. 51. 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.
  52. 52. UIE Web Application Summit, March 2008 Avoid “solutioneering.”
  53. 53. UIE Web Application Summit, March 2008 Advice for a project brief
  54. 54. UIE Web Application Summit, March 2008 Advice for a project brief • Keep it light and easy to digest.
  55. 55. 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.
  56. 56. 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.
  57. 57. 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.
  58. 58. UIE Web Application Summit, March 2008 Bottom-line: A project brief should set expectations, focus on problems and get everyone on the same page.
  59. 59. 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.
  60. 60. 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.
  61. 61. UIE Web Application Summit, March 2008 ? Why would I use personas?
  62. 62. UIE Web Application Summit, March 2008 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 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.
  63. 63. UIE Web Application Summit, March 2008 Advice for personas
  64. 64. UIE Web Application Summit, March 2008 Advice for personas • It’s the research that matters here, not the deliverable.
  65. 65. 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.
  66. 66. 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.
  67. 67. 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.
  68. 68. 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.
  69. 69. 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.
  70. 70. 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.
  71. 71. UIE Web Application Summit, March 2008 Bottom-line: The act of creating personas has much more value than the personas themselves.
  72. 72. UIE Web Application Summit, March 2008 Deliverable: Scenarios (aka user stories)
  73. 73. UIE Web Application Summit, March 2008 ? Where is the value in user stories or scenarios?
  74. 74. UIE Web Application Summit, March 2008 Scenarios Scenarios are great for illustrating user goals and also fairly accessible and easy to digest.
  75. 75. UIE Web Application Summit, March 2008 Advice for scenarios
  76. 76. UIE Web Application Summit, March 2008 Advice for scenarios • Base them on research and real data.
  77. 77. 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.
  78. 78. 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.
  79. 79. 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 specific as you can.
  80. 80. 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 specific as you can. • Combine them with personas for a rich, high level view of user goals.
  81. 81. UIE Web Application Summit, March 2008 Bottom-line: User Scenarios are good for describing flow and interaction at a high level.
  82. 82. UIE Web Application Summit, March 2008 You might try: Storyboards or Comics
  83. 83. UIE Web Application Summit, March 2008 Research and goals overview
  84. 84. UIE Web Application Summit, March 2008 Research and goals overview • The focus here should be on research and goal setting.
  85. 85. 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.
  86. 86. 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.
  87. 87. 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.
  88. 88. UIE Web Application Summit, March 2008 Bottom-line: A successful first phase will have your team informed about business and user goals for your app and ready to begin problem solving.
  89. 89. UIE Web Application Summit, March 2008 Documenting Design Decisions
  90. 90. UIE Web Application Summit, March 2008 Deliverable: Use Cases (aka user flows, task flows)
  91. 91. UIE Web Application Summit, March 2008 ? Why would I create use cases?
  92. 92. 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.
  93. 93. UIE Web Application Summit, March 2008 Advice for use cases.
  94. 94. UIE Web Application Summit, March 2008 Advice for use cases. • Take your time, really think and be as detailed as you can.
  95. 95. 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.
  96. 96. 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.
  97. 97. 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.
  98. 98. 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.
  99. 99. UIE Web Application Summit, March 2008 Bottom-line: Use cases are a great way of describing detailed interaction. They’re also the first place where your decisions will be documented. Give them the time and thought they deserve.
  100. 100. 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.)
  101. 101. UIE Web Application Summit, March 2008 ? Why would I screen descriptions?
  102. 102. 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 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
  103. 103. UIE Web Application Summit, March 2008 Advice for Screen Descriptions
  104. 104. UIE Web Application Summit, March 2008 Advice for Screen Descriptions • Prioritize elements, this will be helpful if you have to cut later.
  105. 105. 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 specifics.
  106. 106. 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 specifics. • Describe how elements reflect user goals.
  107. 107. 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 specifics. • Describe how elements reflect user goals. • Use “real” text and examples.
  108. 108. 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 specifics. • Describe how elements reflect user goals. • Use “real” text and examples. • Be verbose, don’t skimp on the details.
  109. 109. UIE Web Application Summit, March 2008 Bottom-line: Screen descriptions are a very useful, yet low-fidelity, low risk way of describing detailed layout and interaction.
  110. 110. UIE Web Application Summit, March 2008 Tricky Deliverable #2: Wireframes
  111. 111. UIE Web Application Summit, March 2008 Tricky Deliverable #2: Wireframes BEWARE!
  112. 112. UIE Web Application Summit, March 2008 Tricky Deliverable #2: Wireframes
  113. 113. UIE Web Application Summit, March 2008 Tricky Deliverable #2: Wireframes
  114. 114. UIE Web Application Summit, March 2008 Tricky Deliverable #2: Wireframes Better!
  115. 115. UIE Web Application Summit, March 2008 ? Why would I use wireframes?
  116. 116. 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.
  117. 117. UIE Web Application Summit, March 2008 Advice for wireframes
  118. 118. UIE Web Application Summit, March 2008 Advice for wireframes • Be as real as you can. No greeked text.
  119. 119. UIE Web Application Summit, March 2008 Advice for wireframes • Be as real as you can. No greeked text. • Set expectations. Wireframes are not a finished design or look and feel.
  120. 120. UIE Web Application Summit, March 2008 Advice for wireframes • Be as real as you can. No greeked text. • Set expectations. Wireframes are not a finished design or look and feel. • Annotate thoroughly to describe interaction.
  121. 121. UIE Web Application Summit, March 2008 Advice for wireframes • Be as real as you can. No greeked text. • Set expectations. Wireframes are not a finished design or look and feel. • Annotate thoroughly to describe interaction. • Annotate to answer potential questions that’ll come up later on.
  122. 122. UIE Web Application Summit, March 2008 Advice for wireframes • Be as real as you can. No greeked text. • Set expectations. Wireframes are not a finished design or look and feel. • Annotate thoroughly to describe interaction. • Annotate to answer potential questions that’ll come up later on. • Be as specific as you can.
  123. 123. UIE Web Application Summit, March 2008 Advice for wireframes • Be as real as you can. No greeked text. • Set expectations. Wireframes are not a finished design or look and feel. • Annotate thoroughly to describe interaction. • Annotate to answer potential questions that’ll come up later on. • Be as specific as you can. • Don’t get caught in a nasty feedback/revision loop.
  124. 124. UIE Web Application Summit, March 2008 Advice for wireframes • Be as real as you can. No greeked text. • Set expectations. Wireframes are not a finished design or look and feel. • Annotate thoroughly to describe interaction. • Annotate to answer potential questions that’ll come up later on. • Be as specific as you can. • Don’t get caught in a nasty feedback/revision loop. • Tie them back to previous deliverables to reinforce decisions and thinking.
  125. 125. UIE Web Application Summit, March 2008 ? What about paper prototyping?
  126. 126. UIE Web Application Summit, March 2008 Bottom-line: When done at the right fidelity and annotated thoroughly to describe interaction, wireframes are a great way of documenting design decisions for multiple audiences.
  127. 127. UIE Web Application Summit, March 2008 Combine layout and interaction.
  128. 128. 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 specific 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
  129. 129. UIE Web Application Summit, March 2008 ? What is a design description document?
  130. 130. 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 specific 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.
  131. 131. UIE Web Application Summit, March 2008 You might try HTML or Flash Prototypes.
  132. 132. UIE Web Application Summit, March 2008 Composites
  133. 133. UIE Web Application Summit, March 2008 Documenting Validation, Iteration & Maintenance
  134. 134. UIE Web Application Summit, March 2008 Deliverable: Usability Reports (aka expert reviews, heuristic reviews)
  135. 135. UIE Web Application Summit, March 2008 ? Why would I use usability reports?
  136. 136. 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.
  137. 137. UIE Web Application Summit, March 2008 Advice for usability reports
  138. 138. UIE Web Application Summit, March 2008 Advice for usability reports • Be thorough. Document as much as you can.
  139. 139. 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.)
  140. 140. 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 specific recommendations.
  141. 141. 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 specific recommendations. • Don’t be afraid to revisit and re-evaluate original goals.
  142. 142. 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 specific recommendations. • Don’t be afraid to revisit and re-evaluate original goals. • Include your designers and developers in the testing process.
  143. 143. UIE Web Application Summit, March 2008 Bottom-line: Usability testing (and the subsequent reports) are essential in ensuring quality and usability over time.
  144. 144. UIE Web Application Summit, March 2008 Deliverable: Style Guides
  145. 145. UIE Web Application Summit, March 2008 ? Why would I use style guides?
  146. 146. UIE Web Application Summit, March 2008 Style Guide A style guide is a useful tool used to keep your application consistant through ongoing iteration.
  147. 147. UIE Web Application Summit, March 2008 Advice for style guides
  148. 148. UIE Web Application Summit, March 2008 Advice for style guides • Be thorough, but don’t overcomplicate an already complicated task.
  149. 149. 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.
  150. 150. 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.
  151. 151. 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.
  152. 152. 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.
  153. 153. 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.
  154. 154. 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.
  155. 155. 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.
  156. 156. 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.
  157. 157. UIE Web Application Summit, March 2008 Validation, iteration and maintenance overview
  158. 158. UIE Web Application Summit, March 2008 Validation, iteration and maintenance overview • Web applications have living designs and will change often.
  159. 159. 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.
  160. 160. 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.
  161. 161. 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.
  162. 162. UIE Web Application Summit, March 2008 Lessons learned
  163. 163. UIE Web Application Summit, March 2008 Lessons learned • Deliverables document design decisions.
  164. 164. UIE Web Application Summit, March 2008 Lessons learned • Deliverables document design decisions. • Deliverables aren’t usually good for building consensus.
  165. 165. 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 final product.
  166. 166. 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 final product. • Quality is important. A good deliverable will help build trust.
  167. 167. 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 final product. • Quality is important. A good deliverable will help build trust. • Involve people in the process and the creation of your deliverables.
  168. 168. 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 final 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.
  169. 169. 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 final 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.
  170. 170. UIE Web Application Summit, March 2008 Lessons learned, cont.
  171. 171. UIE Web Application Summit, March 2008 Lessons learned, cont. • Make them as real as possible. Use real language.
  172. 172. 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.
  173. 173. 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.
  174. 174. 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.
  175. 175. 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.
  176. 176. UIE Web Application Summit, March 2008 One last bit of advice: be open-minded and creative!
  177. 177. UIE Web Application Summit, March 2008 Thanks!
  178. 178. UIE Web Application Summit, March 2008 ?
  179. 179. UIE Web Application Summit, March 2008 Making The Translation: Critical Web App Design Deliverables D. Keith Robinson, March 26, 2008
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×