How to define a UX Process in an agile world

I recently had the chance to establish a UX process for a team I was working within an agile setting. My role is the design lead which covers everything from user experience to user interface design. The purpose was to improve upon existing interfaces as well as create new interfaces that leave users coming back for more.

Many web-based applications today sometimes miss the essence of a native app(which is fine) but users have old habits that dictate their next step in any process. Web designers need to think ahead of our users and make sure each step of the way is natural.

Below are the results of my research. I figured I would share the wealth so you can apply the process to your own projects and products. Please leave any feedback in the comments where you can!

What is a UX process

A UX process helps build products, people, want and need. In the end, the goal is to create a product that is a good fit for people who end up using it — instead of for the developer or CEO who envisioned it. This factor is particularly important for a user who has spent their hard-earned money to purchase your products.

A UX process will save valuable time and resources by getting it right, or mostly right, the first time. As the process repeats team members become faster and more efficient while doing so.

Some key things to remember if you don’t bother reading anything else (tl;dr)

Avoid dogmatic thinking that says there is only one way to correctly do usability research or design
Be realistic and flexible
No one wants to hear that their way of doing things results in a bad product or the company losing money. No one wants to hear you telling them your way is right and their way is wrong. The key is to show, rather than tell; persuade, rather than dictate.
Document wins, then publicize ruthlessly - This is probably the most important thing you can do to sell the value of UX within your company.

Kicking things off

Starting small will help keep your team from biting off more than they chew. You can’t expect to completely overhaul your products in one fell swoop. Modularizing projects(features, bugs, improvements, etc...) as they come can help to refine products over time and also validate the process itself. Picking a smaller, less visible project is most-ideal starting out. From that point forward you can start integrating new techniques while showing the team how to build products with the user in mind.

Documentation and Tracking

Documenting and tracking the progression of the UX activities and outcomes is crucial to validate the process itself. You will need to measure any and all information so that you can later illustrate how the process actually works towards someone new to it. After each revolution of the process simply document your findings and over time you’ll start to understand what works and what doesn’t for both your users and team.

Agile Methodology ( A Brief Overview )

Agile in a nutshell...

User Role — As a user, I can…
User Story — I want to…
Value — So I can…
Conditions of Satisfaction — Verify that…
Notes — Details from discussions
- Priority
- Level of Effort

UX in an Agile World

User experience doesn’t quite fit in the agile world. Design doesn't code. There are no fixes or exact solutions to various problems that arise. Sometimes, UX practitioners just need some time to work through big design issues that don’t fit neatly into an existing user story or an individual sprint. Regardless, agile is here to stay and with that UX needs to be incorporated somehow. Below are some key measures to keep in mind when working through our UX process during Agile development.

1. Communication Is Key
For some team members, the biggest benefit of using Agile is communication. The Scrum method provides the structure for cross-functional team members to contribute ideas, share responsibilities and refine the process together. To reduce knowledge gaps from the evolving nature of project specifications, constant contact and design review meetings should be held to keep in sync with product iterations.

2. Empathy
Put yourself in your user's shoes. Think about what problem they are trying to solve. Take a step back and access these issues first before diving into any work.

3. Keep Teams Consistent
It takes time to build a good cohesive team that makes the right decisions quickly. Each Agile team may work differently and have a unique team dynamic. Disrupting the system wildly interrupts velocity because knowledge and expectations must be reestablished.

“Team consistency is key. Stop reorganizing and shuffling people around. Teams that stay together, learn together, and keep getting better and faster.” — Derek, Lead Researcher & UX Designer*

4. Be Proactive, Not Reactive
If you are used to working “head down” for long stretches of time, then you need to change your work style or risk being outdated. Collaboration is key for successful product development. The involvement of cross-functional team members promotes transparency and allows issues to be identified early. Be involved in all aspects of the design process, including planning. Be prepared to share your ideas, show what you are working on, and contribute to discussions.

5. Have a Dedicated Scrum Master, Especially at the Beginning
Make sure there is a dedicated Scrum Master. If you can’t do that, you must be clear about each member’s roles from the start.

6. UX Must Work at Least One Step Ahead of the Sprint
UX needs to precede development almost always. Developers don’t want ambiguous concepts nor should they be expected to take matters into their own hands with UX. Having too much guesswork produces inconsistent results and failed attempts at solving critical issues. This ties back to communication between all parties on the project.

The Process

1. Plan

Beginning the process involves setting expectations, roles, as well as perceptions of the user up until this point. You likely have been presented with a problem that needs to be solved or removed and do this requires a plan of attack. Accessing and analyzing any data or predetermined knowledge in this part of the process helps dramatically going forward.

Product Planning

Before starting any work, planning is crucial to establish a holistic look at the project ahead. Listing what it is you know and what you don’t know through the methods below will help kick things off on the right track. Some methods to product planning include:

Sitemaps
Existing Feature Roadmaps
Use cases and scenarios
Measured Data (Analytics)

Design Strategy

If any data (analytics, customer complaints, error logs, etc...) is available, all parties will begin reviewing it without coming to any swift conclusions.

At this point with data in hand or not, you could start to implement a design strategy. This strategy can vary per project or feature and the methods to develop the design strategy can as well. Some examples to make use of are below

Journey Maps
User Stories
Personas
Stakeholder Interviews
KPIs (Key Performance Indicators)

2. Concept

Lightweight concepts kick off the second part of the process. Every member of the team needs to be involved with this. In this phase, ideas should pour out and be put together roughly by all parties. Remember that no idea is a bad one. The initial investment in sketching is so minimal that there is no significant cost to completely rethinking the direction. There are many strategies you can practice for conceptualization:

Brainstorming
Moldboards
Storyboards
User Journeys
Taxonomies

3. Prototype

Once a concept(or direction) is agreed upon internally, a rough prototype helps to validate the idea with your customers.

As with the initial sketches(concepts), focusing the prototype on critical components of the experience is essential. Pick the core user flow (or two), and prototype only those screens. The fidelity of the prototype ultimately doesn’t matter, so create it the way you know best. Once created, it will be immediately testable by any and all users.

At times, the customer (internal or external) will demand a level of fidelity that helps them better visualize the experience. In my own experience, my team made use of Balsamiq for wireframes, Marvel for click-through prototyping with higher fidelity designs and Sketch or Affinity Designer for the design creation.

4. Internal Validation

Internal validation(testing) occurs after a working prototype is ready to test. Reach out to internal members of your team or even friends and family and have them test the prototype. Doing this helps validate any concerns you have before moving to external validation. Be sure to validate with users that know the product well and others that don’t necessarily deal with the product on a day-to-day basis.

Record any feedback you witness. Different types of validation can take place. These are best chosen when the time comes as projects and requirements will always vary. Some methods you could use for validation include:

Focus Groups
Usability Testing
A/B Testing
Eye Tracking
Surveys
Accessibility Testing

5. External Validation

The same methods can be applied for external validation as in internal validation. Test your product(s) on varied types of users and collect the data they show physically and tell us verbally. In this stage, you can conduct interviews either remotely or on-site to gather all the necessary data and behavior patterns we can.

During external validation, you can make good use of the time to test and ask the users some valuable questions. Some of the questions I have found to be useful in knowing include:

Project Vision - Can they define goals and pitfalls of experience so far?
Ask them to describe a typical user and the roles they are granted
Value Proposition - What are they getting out of the software?
Competition - Do they prefer our products or others?
Your (The User’s) Customers - Define who or what is being targeted
Process/Workflow - Discover the patterns/habits of the user's process
Context of Use - Asking what tools/features they use today. Validation of look and feel. If anything is missing or if there are any obvious pain points.

6. Learning

Collect feedback. Figure out what worked and what didn’t. Tweak the prototype. Hell, you can gut it if you have to. The investment put in at each phase so far is so minimal that rethinking, reconfiguring or redesigning isn’t crushing in workload or ego-bruising. Gotta love that!

7. Iterate (Repeat steps 1 - 6 if necessary)

If you don’t arrive at a viable solution:
If after all of the prototyping and validation phases you still fail to produce an answer, it may be time to start the process again to see if there is a prime path missed or one you failed to consider.

If you arrive at a viable solution:
Once validated, demo your updated prototype to the team. Explain the flows, the user motivations and why it was designed the way it was. The prototype has now become the documentation.

The viable prototype is now “The Spec.” Very little (if anything) more is needed to resolve the problem.

The strength of process here is that, with the design validated, the designer is now freed to move on to the next core component of the experience, instead of spending many weeks creating a design requirements document and pixel-perfect specs that might be all for nothing.

8.Design

By this phase a prototype should already be chosen as the final direction to take as proven by internal and external validation.

Remember that the final prototype is the documentation. It is the experience. Thick deliverables created simply for future reference regarding the user experience become obsolete almost as soon as they are completed. When a question arises about how something should behave in the UX, going through the workflow in the prototype to see what happens is easy enough. The old kind of documentation is a waste and draws effort away from solving current design problems.

Design itself can be performed/created in a variety of ways. How design resides in our space is to simply communicate the vision. There are no deliverables to slice out and import. Prototypes, pattern libraries, wireframes, technical specifications, and sketches are used simply to communicate the experience to the developer who implements the vision.

9. Validate once more

Throughout the design phase, a series of reviews need to take place to validate the direction matches the prototype. You need to make sure you remain on course from the prototyping phase all the way to production. Using the agile approach, daily scrums(design reviews) are a great way to keep communication intact as well as validate any design-related problems.

While the experience has already been defined. This second round of validation pays greater attention to the UI Design introduced during the design phase. Establishing a consistent look and feel across a global spectrum needs to be stressed going forward.

10. Off to production

In the final production phase, developers begin to use all the data, prototypes, and design concepts as their “requirements” for the project. Developers build the experience based on what designers and product managers crafted several phases prior. Going forward the developers put the project through their own process of building, testing, and deploying to a testing directory. More testing is done on a technical scale and finally, a launch or soft launch commences.

Links and Resources