During a discussion about our UX process at Zuhlke (we’re always inspecting and adapting), we spoke about the tools, techniques and technologies we’d recently used in our projects. It became apparent that as UX engineers we used a range of approaches dependent on what we were trying to achieve.
We didn’t get hung up about the fact that some of us didn’t use paper prototypes for their last project or that others had not created a service or experience map for theirs. What came out of the chat was that we all applied the tools appropriate to the projects at the time to get the best outcome for our users. We did things that ensured our understanding of the problem spaces, the user of the product and business cases was thorough and solid.
In the fast changing world of UX sometimes there’s an eagerness to try out the latest and greatest prototyping tool, try a new wireframing toolkit or develop ultra-detailed artefacts when they aren’t warranted. It’s important that UX engineers have an understanding of the tools available to them. It’s as important they understand what they wish to communicate before they select the tool to communicate with.
The tools and techniques we use will generate an artefact of some kind. Interviews will generate transcripts, which in turn could generate a spreadsheet or a wall of post-its containing the responses. Process investigation can generate a flow chart, a journey map or an storyboard. After a design process a prototype could be created, should it be a paper or clickable prototype? The answer to all of these is defined by 2 things, who is the audience and what do you want to communicate to them?
When communicating with a development team the outcome we are seeking is shared understanding of a piece of functionality. One process could be to have a huddle at a desk or sketch on a white board. Take photos of the sketches and make notes, these will be attached to user stories in the backlog. This is the best way to communicate with the team, if higher fidelity is required it can be delivered, but usually a sketch or lo-fi prototype is plenty good enough. The aim is to get to testable, working software in front of users not to create higher fidelity prototypes.
If the audience is a user group and the outcome is confirmation of a feature or workflow in an application, an interactive prototype is usually a good idea. The selected tool depends on the situation (Axure, Pixate or a CMS driven wireframe), but one needs to ensure they are testing the right thing (i.e. users aren’t focused on design when process or workflow is what you’re interested in). Preparing a statement to define the task required of the users and what they should expect of the prototype ensures users have an understanding of what is expected of them. Interactive prototypes are valuable if they can provide something close to what might finally be delivered and that the outcomes of the test session relate to feature or process in question. Again, the aim is to get to working software, timeboxing prototype generation is a good idea.
There have been times when we’ve presented early thinking to product management teams using paper prototypes and telling the story of a user’s journey. In these cases the outcome we’re looking for is a shared understanding of the problem space, input or direction from the audience and communication that nothing is, as yet, set in stone.
Earlier in a project it may be better to use sketchier and less ‘designed’ artefacts as you may wish to communicate that you are still in a research or creative phase. As the project progresses your assets may need more polish to communicate a move to a more finished product.
Considering the desired outcomes of your process helps when deciding how much effort to expend on developing an artefact. When trying to describe a complex process, affecting many parts of the product delivery one should spend the time to get it right. These types of assets can truly shape a project. Creating a detailed infographic to describe the outcome of an interview round may not be the best use of your time, and a simpler communication method should be sought.
As was said earlier, consider who your audience is and what do you want them to get out of the work you’ve been doing. Do you want to give direction, evidence or options? Figuring these things out first will streamline your workflow and improve communication throughout your product team.