Design Process

Requirements Gathering is the most important step - you can't hit a target unless you define it first. I try to spend as much time and effort as possible to understand the users, their requirements, where they may conflict with the business requirements, and to define what as successful outcome.

Deliverables:

Heuristic Evaluation: an evaluation of any existing product with an eye towards known usability and user experience rules.

User Profiles, which leads to Personas: It is important to know your audience, sometimes black and white important. If you miss your audience, you can create the most amazing app in the world, but the user's will reject it, and rightfully so.

Affinity Diagram: or Card Sort, this is an effective tool to discover what information is needed by the various users, what information exists, what processes might be gleaned, and possibly identify where there are some holes in the current process (or proposed process for new apps). This takes the form of cards, each with notations on them, originally notes as they are taken, which are then sorted by process, or user, or some combination thereof, to produce a picture of what you are creating.

Competitive Survey: Before you make anything, you should take a look at the competitors. This will give you an idea what the best practices are, and, more importantly, where your app can supply missing functionality in order to win the market.

Task Requirements: I'm often surprised that this isn't done by a lot of companies. To me, unless you list the tasks required for each user persona and then triage them in terms of importance, the project is at serious risk of scope creap or - worse - unerdelivering.

Content Inventory: Know what you have to offer, know where the holes are, hire the people to fill the holes.

Strategy before tactics. Always. This is where the 'bones' of a product will be created, tested and finalized before the 'skin' is applied. This is often where the most interesting work is done, especially when the product is a new app satisfying a totally unforseen need.

Deliverables:

User Journey: Which users need to which tasks? This document will spell out who needs to do what and at what point. Importantly, this doc also includes notations on what information the user needs to perform a task or make a decision. I go a bit further. With an eye on the Personas, I like to note which functions and the tools to complete them may be novel to the user, and decide if they need to be simplified or explained. This will hopefully hit the learning curve target spelled out in the User Profiles.

Concept Map: This short doc is often not needed, but it is a good idea to spell out original directions for the eventual interface. For example, if there is a need for reference material, is it up or down or off to the right? If there are tools for work, do they go on the left? Again, the user profile will inform this document.

New Concepts: Often, at this point of the process, breakthroughs occur, and user tasks can be radically simplified. These new ideas must be communicated to the rest of the team, especially the developers. There is no 'standard breakthrough document' but a wireframe and presentation is a good place to start. I've prepared a presentation to show how this fits into the usual process.

This is where preparation pays off. If you are designing with all of the above complete, you will have very few redesigns, but it is important to test - arrogance kills projects.

Deliverables:

Block Prototype: Finally, DESIGN! A prototype is normally done in two stages, block versions and 'live' versions. In the block version, we are just fleshing out the task flow, and giving those tools size/attention based on their importance to users. This can be verified via user testing.

Living Prototype: this is the first interface design, complete with hooks into any backend database. This is where the interface can be tested thoroughly and adjusted. By the end of this, the interface should be complete and the UX team should be confident that the app meets or exceeds the user needs. If needed, an heuristic evaluation can be completed on this step. Example from Video Bug

Usability Test: Design is blind hope, testing opens your eyes. Usability tests should be as complete as possible given the budget. Each round of usability tests should be documented and recommendations implemented in a new design. Each round of tests will (hopefully) find smaller and smaller issues.

Functional Requirements: The developers will have many questions, the Functional Requirements document should answer as many as can be anticipated. The functional spec will include such small details as how many characters are allowed in a file input, how many pixels (or percent of space) between buttons.

The developers are in charge, but UX is not idle. While the app is being developed, the UX should prep for deployment and start planning the next version.

Deliverables:

User Manual: Yes, many UX designers won't touch this, but who knows the app and its weak points better than the one who wrote up the usability test results. One of the many things in the usability test results should be the recommendation of which widgets need to be explained in the User Manual. The user manual can take the form of either notes for a technical writer, an acutal manual, or a Help function in the app.

Review and Plan: No project is perfect, and often, given limits of time and money mean that some good ideas get left behind. As the project is moving toward the end, it is the time to revive those ideas for version++. This is a simple document to get those discussions on paper so they don't get lost.