Prototypes/Wireframes

Visualizing as early as possible helps ground conversations. Sketching gets the juices flowing and helps drive convergence. Continued by an organic progression of linking screens together and documenting thoughts.

How far the linked screens/prototype are 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 FidelityIt’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

Specs are a necessary evil as they are painful to write and painful to read. Documents that are too long tend not to be read, while a lack of detail can lead to a distortion of the original vision.

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

Too much detail can be problematic in some cases. Specifying only the details that affect the end user allows development to make smart decisions on the implementation. 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 the document, the less your stakeholders will revisit updates. Systems like wiki’s provide quick access and organic growth.




UpdatingWhile we love to call a spec final, it's never really done. As development starts, 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 during the SDLC. Promoting the use of electronic copies will save a fair amount of paper and also lessen the chance for stale documentation.

User Flows

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 the user will see on 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. 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

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 digital realm, into the real world. Giving a name to the various personas helps the team focus on who the feature is being designed for and avoid wild goose chases.

Scenarios document the persona's goal that 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 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.