A good final product grows from a good working process

I make sausage

Numerous articles and outlines exist of what a UX process should look like within an agile environment. They’re all excellent! While I know I’m not presenting anything new under the sun, I want to talk through what an effective design process has looked like for me. What are the artifacts at each stage? Who are the players? Where do we begin?

At the outset, I have a problem or user pain point captured in previous user research, an issue that has arisen through customer support, or a spot in a sales funnel where customers repeatedly drop off. The issue is such that our business stakeholders have prioritized it for improvement. The light is green to fix the problem.

But the “problem” might not really be the problem. Sometimes a user pain point boils down to a usability issue easily amended by bringing design principles to bear. More often I see “referred pain”. The source of the complaints is not actually the source of workflow breakdown. For example, users complain about filtering controls. The real issue is that the page they are looking at has been so badly set up that they are being forced to filter to make sense of the content. Someone listening just to the complaints would build a new filter control instead of making the content itself easier to read and more relevant to users’ work.

I get a sense of what direction to probe by looking at previous user research. Large scale contextual inquiries yield extensive qualitative data to be mined for specific work sequences and challenges the user faces. Previous user tests on other workflow improvements often contain work insights that can be revisited. I have a persona library built from the insights of previous research to bring forward. Sometimes I’m lucky enough to be able to contact the complainers directly and learn more.

The page is not blank. I have enough background information at hand to work with a business analyst and form an idea of the solution. I walk away from these sessions with a few things:

• A clear idea of the user’s starting intention and desired end state
• A flow chart outlining the steps and choices a user can make to get to the goal
• A loose set of requirements regarding what must be present on the screen for the user to meet their goal

I want to breathe life into the workflow model to verify that this is an idea that works. I build a prototype based upon the outlined steps that give a sense of how the choice sets will feel. I build simple, interactive prototypes in Axure. I take a few seconds to make it interactive to verify my own thinking. Having an interactive prototype also provides a sense of feel for those with whom I will share the design. I currently use Axure because it was in place at my job before I arrived. The tool used doesn’t really matter as long as everyone involved can get a feel for the workflow.

First, I walk the business analyst through the flow. How does it feel? Now that we see our flow model as real pages, does this change the original flow? Is there a gotcha that we couldn’t see before? Does this meet the requirements? The early prototype is edited.

Next, present the prototype to development. I have always had the best results by involving developers as early as possible. Before I go too far I want to know, is this possible? How? What problems do they foresee from their angle? These are people with a very valuable talent for poking holes in design ideas. Again the prototype is iterated upon.

I emerge from this stage with:

• An interactive prototype that is testable
• The objectives that need to be verified in user testing
• A sense of what stages this design will have to be divided into for agile teams to execute it

Everybody loves this part because it’s SHOWTIME! After all of this work, what are the users going to say?

From the list of objectives, the test plan is built and the questions are outlined. I list the assumptions of success for every subject tested. Our first test is an internal run-through to make sure the questions are thorough.

Everyone is welcome to watch user testing. I create a separate interactive testing prototype with some realistic scenarios for users to walk through. I get on a Webex meeting with users, give them control of the mouse, and start the test. Currently, my testers are recruited from our user base. I’m looking for a group of 10–20 people with a mix of work styles and roles. I invite anyone to listen in on the test who has the time to do so — even the developers.

I go back over the tests to pull the results together and present them to stakeholders. All tests are recorded and I like to go back and transcribe the recording. I internalize the feedback this way and get to really hear the words. Sometimes, at the moment, it can feel like the user has said one thing that, when I go back and slow them down, there was a different point being made. I evaluate whether the assumptions were successful, semi-successful, or failures. From the transcriptions, I distill the feedback into main points backed up by direct quotes and followed up by design recommendations. This is then shared widely with product stakeholders.

Testing artifacts include:

• Test plan outlining objectives, tasks to perform in a test, and questions for the user
• Test-specific prototype that supports specific flows that will be evaluated
• Transcriptions of user responses to questions
• Presentation of user feedback with main points, user quotations, success or failure of assumptions, and design recommendations

Integrate design recommendations into the prototype and run the test again.

Get the revised prototype in front of users another way if there’s no time to re-run a test. I work with colleagues in other disciplines to present the changes to customers and get feedback. This is where being a shameless promoter of UX and cheerfully working one’s way into everyone’s work can pay off dividends.

If something fails twice in testing it’s time to go back and question the overall goal. I have seen some designs fail in repeated tests despite tons of changes made to clarify. Are we addressing the right need? Is this simply too abstract for a user to understand and the idea should be scrapped? Whatever the reason, don’t force something to work that evidence simply won’t support.

After I have vetted a design with users:

• Pull interaction from the testing prototype into one that can be consumed by developers
• Include the flow model in the prototype
• Storyboard out interactions so that developers can see all the states in a static view
• Provide references to relevant design guidance from the product style guide

Pulling together the final ready-for-development prototype after testing is completed should take no more than a day. There are a lot of precise directions to be included for those actually constructing the solution that cannot be set down until testing is done.

From here I wipe my hands of the project, email Axure prototype link to the dev leads, and move on to the next thing. Happy ending.

Kidding!

There is no ending. The final vision for the design will likely be more than a team can execute in a 6-sprint product increment. It may require more than one team. I have delivered a vision of the end goal and now, together with the project manager who will guide developers through creating this, I talk through the achievable stages. This may mean I do a version of the solution that walks back some of the more complicated functionality. I also add more annotations for developers. Together we make sure the user stories and requirements match up with the prototype and that accurate references are made.

The delivery should be multi-modal. Expecting developers to correctly interpret pictures or even a clickable prototype with no annotations is setting the team up for errors. Writing extensive user stories with no visual reference forces the developers to be designers and they don’t want to do that.

My goals for delivery include:

• Have the UI perfectly spelled out so that there is no guesswork. The prototype and product style guide are my stand-in and the voice should be clear.
• Have all the UX resources in one place so that it’s a one-stop-shop
• A final design that is able to be created through iteration by an agile team.

These steps and artifacts have yielded effective design results and kept the UX delivery process consistent for me. The particulars of this method have looked slightly different when different team structures or toolsets were in play. But these are the methods that allowed me to effectively distill the recommendations of UX gurus into a realistic day to day UX practice.