AP UX Week '07: Pattern-Based Design Communication Techniques
[Live blogged from Adaptive Path UX Week 2007. Pattern-Based Design Communication Techniques]
Why document design? It helps facilitate collaboration and move the design process forward.
- Visualize solutions
- Something tangible
- Encourages people to commit
At Cooper work is done in small agile teams. The core team in an interaction designer and a design communicator. There is also a visual design lead and engagement lead.
We are talking about interaction design today. ID is responsible for solution ideation through sketching rectangles on a white board. They are to keep the momentum going and produce final pictures.
The DC is responsible for the design making sense, for testing the ideas that come out. They are looking for patterns (design patterns) that make sense for this problem. They create the book, presentation, or notes that tell the story of the design.
This is socratic relationship between the two. ID sketches, DC asks questions. The other members are also there along the way but are included at key moments (daily).
Documentation, delivery, and design are all about story-telling. The process is anchored by personas, propelled by ideal usage scenarios, and tempered by the reality of engineering constraints and other requirements.
So when does design happen?
- During and after research
- to discuss preliminary findings
- To communicate behvior patterns, personas, etc.
- When we define solutions
- To out line napkin-sketch solutions
- To specify refined interactions
- Throughout the process
- To document key decisions
Patterns outline solutions to common problems. The patters concept comes from architecture.
A pattern approach subdivides one large problem into many smaller problems. instead of addressing documentation as a monolith you are addressing the problems you are solving with the documentation.
[See the slides for a good list of challenges in documenting design]
A case study
Client: Barclay's Global Investors
Project: A web tool used by financial advisors to explore new ways of analyzing portfolios and understanding performance
Can't focus on analysis part of the project. Can talk about getting information into the site.
- provide efficient pathways to entry
- help advisors avoid mistakes
- handle errors smoothly and helpfully
Start with a persona: Steven the broker from a full-service brokerage who needs a story to sell to his clients. He already has a dozen and a half tools he is already using.
His goals:
- Win new customers
- Appeal to as many people as possible
- Stay on top of current trends
- Not to waste time
Barclay's wants Steven to think about iShares as a family of products, not as stocks.
Start with a sketch solution. Brand agnostic colors and focus on the parts that matter. There is a visualization of the portfolio.
So uploading security data...
Assets are already in spreadsheets. The people who have financial advisors are wealthy. These people have more than, let's say, five million dollars in assets.
So you take that spreadsheet and upload it. The area below indicates that something is happening. The advisor is prompted for a notes field. Once the results appear the app will need to handle errors.
So do document this you need a patterned approach.
| How does the design help the persona get the work done? | Scenario |
| How does the behavior work? | Screen layout diagram |
| Why is the solution good? | Explanation of rationale |
| Are elements representative of core behaviors that will repeat? | Global behaviors |
| How do we make this easy to find? | TOC & cross-reference |
| What are the dimensions of interface elements? | Styleguide |
Scenarios show behavior in the context of the problem they solve. They communicate the narrative of the design, they keep you rooted in humanity.
A scenario shows a series of pages as a persona goes through a task.
Screen layout diagrams describe important elements and behaviors. It roots the screen in context with the workflow. We are talking wireframes at this point.
Global behaviors and principles for solving common problems. Similar problems = similar behaviors.
Use a table of contents to structure the documentation in a way that communicates the purpose of each piece in relation to the whole.
Q: What about rich internet applications?
A: Powerpoint animations are useful. Documentation can present a ton of overhead, even to make an animated gif. You want to avoid spending too much to make documentation. Flash demos can be useful for this (especially with demoing physical objects that make sound, etc.). Bringing it to life is very important.
Q: How do you use design patterns across projects?
A: This is hard to do because if you emphasize story-telling you reinvent quite a bit every time. They do, however, maintain an archive of previous solutions to build on.
Q: What's in the style guide?
A: This is very high fidelity. This is where the rendered interface is documented along with typographic and color system information.
Q: Who uses this material? and how?
A: It depends. The reality is that there are many customers for the documentation. There is the executive who brought them in, the product manager who is wrangling everyone together, and other internal people. The executive summary presentation will be tailored to that group. Note like check-ins will take place with the product team along the way to keep things on track.
-1 TrackBacks
Listed below are links to blogs that reference this entry: AP UX Week '07: Pattern-Based Design Communication Techniques.
TrackBack URL for this entry: http://www.samfelder.com/mt/mt-tb.cgi/312
Who is this guy?
Leave a comment