Deliverables

Prototypes/Wireframes

2010-06-23T23:12:00.000-07:00

UI paper dolls and overpriced time-consuming mockups. Both wireframes and prototypes have a good deal of misconceptions tied to them.

The greatest benefit can be had by drawing screens as early as possible, but to do so in a a very quick manner. Sketching gets the juices flowing and helps get the conversation out of the clouds. Continued by an organic progression of linking screens together and documenting thoughts.

How far the linked screens/prototype is taken depends on the project, team and audience. Time should not be the deciding factor since there are many tools and many creative shortcuts.

5 Axis's of Fidelity
It’s dangerous to automatically assume a b/w wireframe is sufficient for all projects. Each project needs to be assessed on a sliding scale on 5 axis’s of fidelity: Visual, Interaction, Data, Breath and Depth.

Quick Iterations
Design is not done in a single pass. It takes many iterations. The more you do upfront, the less you have to do in the back-end.

Visualizing
There is clear need to convert business requirement words to screens. But there is also a great advantage to visualizing the interaction and actually clicking through the flow.

Think It Through
The larger the application, the more difficult it is to hold it all in your head. Walking through the prototype helps you find those unknown or procrastinated pages.

Specifications

2010-06-23T22:56:00.000-07:00

Specs are the necessary evil. They are painful to write and painful to read. If you too much nobody will read them, write too little and they are not informative enough.

I have found that verbal communication is the best way of getting a project through to development. This also help get them involved and spot opportunities. The spec then plays the role of documenting the group decisions for later reference and for QA.

How you write what you write is also important. Specifying only the detail that affect the end user allows development to make smarter decisions on the implementations. All too often, development spends time coding a detail that will not have a user impact, just because it was in the spec.

Accessible
Nobody likes to read specs. The more steps there are to get to it the less your stakeholders will revisit/update. Systems like wiki’s provide quick access and organic growth.

Updating
While we love to call a spec final, it never really is. As development works the spec needs to be tuned. Keeping it up-to-date is important. Again, systems like wiki’s provide an easy way to update and deliver new versions.

Save Paper
There is no harm in saving in few trees in the SDLC. Promoting the use of electronic copies will save a fair amount of paper and also lesson the chance for stale documentation.

User Flows

2010-06-23T22:44:00.000-07:00

A high level view of the user’s path to their goal helps keep the design focused. A more visual version of scenarios, flows incorporate alternate paths and some measure of burden that the user will take on. That is, these diagrams show the number of pages/states will see in the way to accomplishing their tasks.

While flow diagrams can help the early conversations, it is important to recognize that they are still diagrams and diagrams tend to only be deciphered by their maker. Like a floor plan, stakeholders who do not understand them tend to “agree” rather than admit that they don’t understand.

For this reason, I tend to limit the use flow diagrams, or any type of diagram for that matter, outside of the design team. The sooner I can start to talking in a visual language that the stakeholders understand, such as clickable screens, the better.

Personas
Flows allow for the high level visualization personas interaction with the system and with each other.

Paths
Define primary, secondary and tertiary paths through that the design will be focusing on.

Interactions
It’s not just the pages and the personas that matter, the type of interactions can also be communicated here. Particularly to show excise in a heuristic analysis.

Personas & Scenarios

2010-06-23T22:10:00.000-07:00

It’s a great step when companies start to care about the user and consider them even during business conversations. However, humans are quite complex. To generalize all potential participants of the product as “user” whitewashes our many intricacies.

Personas help separate participants by general participation patterns, sometime spilling outside of the web site, into the real world. Crazy right? Giving a name to the different personas also helps the team focus who the feature is being designed for and avoid wild goose chases.

Scenarios document what the tasks and ultimately the goal that personas will be able to accomplish with the product. They are usually written as a paragraph with enough contextual detail to give the task meaning, but avoid specifying the actual solution.

Research Based
User research, market research, business requirements all feed into the development of Personas. Relevant skill sets can be mapped along with external life attributes.

Guerilla Style
Unfortunately, proper research is not always possible. In these cases, any available knowledge of users plus quick informal studies can be done within a couple of days. These sketchy personas still help guide conversations and expectations.

Upstream, Downstream
Personas are great tools for communicating with the entire team. It helps drive convergence with business and also gives development context for a proper technical design.