One way to minimize time spent creating documentation that will rarely be read and will constantly need updating is by creating prototypes. By creating a prototype of the primary workflow you’re currently working on, your team can center around the interaction design in that workflow. Conversation is facilitated around that deliverable and the team can start building as the design is further refined.
The prototype allows work to begin as it is a primary vehicle for creating shared understanding. That shared understanding is the currency of Lean UX and, as such, is traded against the depth of the documentation required.
The prototype allows work to begin as it is a primary vehicle for creating shared understanding.
The more shared understanding a team has, the less it has to document and, most importantly, the faster it can start building products. These products will then get into customer’s hands faster increasing the pace with which the team learns whether or not their design hypotheses were accurate or not. The prototype helps facilitate the conversation upon which shared understanding grows. As edge cases and exceptions to the core flow are raised they are addressed in real time, during this conversation (with developers, stakeholders, product managers, et al) — sometimes that will require additional documentation, and sometimes it won’t.
An Example: How Good UX Practices Can Keep…
How an MBA meets the silos challenge of UX
I love prototypes and we are prototyping more frequently.
I would like to point out one of the dangers of prototyping: it is inclusive of shared understanding only. Omissions from the prototype can create a shared misunderstanding that a feature is not required.
Pingback: Putting the UX in our work | Designing for Experience