There is a lot of debate around whether a truly Agile methodology can incorporate the specialized skillset and frankly “waterfall-esque” nature of UX research and design. Having worked in software design and development for a decade now, I’ve seen it work, but it requires a healthy respect for the two camps’ approach and an understanding of when to dedicate more time and when to pivot to the “fail fast” mentality.
What is Agile?
The Agile methodology of software development is an iterative process to add incremental value to a product or service that stresses implementing the bare minimum of features that provide value to the market. It is ostensibly a way to provide accurate estimates of work requested by the Product Owner, and is by nature tactical and short-sighted. Agile allows teams to quickly respond to changes in the market with the goal of always providing the most relevant features first. With the Agile methodology, you don’t plan or estimate work too far ahead, because all of that work might be irrelevant by the time you are ready to work on it and you don’t want to waste people’s time planning when they could be coding. Agile teams are small, and they work fastest when they’re composed of generalists with a broad skillset. Typically, developer time is assigned to tickets in 2-week sprints with supporting staff such as Scrum Masters ensuring there are no blockers to slow down the team’s cadence.
What is UX Design
UX Design is a discipline that uses HCD (Human-centered Design or sometimes called User-centered Design) to design the bare minimum of features that provide value to the users. On the surface, it looks a lot like the Agile methodology! The cycle starts with observation of the intended user. Typically, UX Designers will create blueprints or journeys to visualize this experience for everybody on the team. In the ideation phase, the team is coming up with solutions to the known problems, then conducting rapid prototyping and gathering user feedback to vet their assumptions and settle on a solution. When data shows that users will derive value from the solution, it is implemented, where additional observation of analytics and user feedback kicks off the whole cycle again.
Challenges to a Purely Agile Process
Although a recent study showed that 71% of companies now implement an agile process, there are a few pitfalls I’ve encountered with established Agile teams that weren’t used to working with UX Designers. In some situations, the company had a UX team, but the designers reported to the product management team that was still exclusively using market data to determine which features provided the highest value.
Fail Fast = Fail Hard
In my experience, unless a Product Owner is also a UX Designer, there is a lack of good process around soliciting user needs both before and after the product is launched, and incorporating good design before it is developed. Most Product Owners aren’t trained in HCD methodologies or Universal Design principles. If a Product Owner has a purely market-driven approach with little to no user feedback or developer input, they aren’t taking into account all the requirements and they haven’t taken the time to vet their assumptions. This can have extreme impacts on users’ satisfaction and brand loyalty, since their only method of providing feedback at this point is in how they use and talk about the product. Sometimes the “fail fast” can also be “fail hard.”
Missing Requirements
When requirements and solutions are spotty, dev teams typically end up having lots of questions during grooming sessions that create churn across the whole organization. When developers bring up a slew of additional requirements late in the process, some really critical ones can be pushed on to the next sprint. Product Management realizes later that their MVP isn’t the most valuable product, just the most viable (and sometimes not even that).
Lack of Collaboration
The collaboration during design that arises organically in startup environments is done upstream of the developers in organizations without an understanding of HCD. The Product Owner controls all the needs elicitation channels and they create the solutions with stakeholders that are then handed to development teams to size. This creates a siloed and sometimes paternalistic culture where developers are viewed as cogs and have little to no say in the solution.
Lack of Context
Agile pushes development teams–and often even the Product Owner–to think in short cycles of work that can give them a myopic understanding of the solution. When there isn’t an understanding of the scope of the problem and solution, work can become siloed as features are built and QA’ed without the holistic view of their relevance.
Arbitrary Deadlines Can Lead to Rushed Work
Scoping how long design work will take is notoriously difficult because ultimately there are too many variables in the design process. The truth is that until user research is conducted, designers just do not understand user needs well enough to design with confidence. Let’s just say things don’t always go as planned when timelines are crunched arbitrarily, and designers are much more likely to pull all-nighters to meet unrealistic deadlines than they let on.
Challenges to the UX Design Process
Although more and more organizations are starting to understand the ROI (return on investment) of UX Design, there are hiccups that need to be avoided so that the HCD process can prove its value.
Organizations Need to Make Space for the Process
The HCD process is time-consuming. It is an iterative approach that intentionally sees the big picture, ignoring development cycles to maintain a holistic understanding of the problem. If an organization hasn’t fully-embraced that process (check out my presentation to Product Management on the Human-centered Design process here), then designers will often produce incomplete and uninformed work that will burn up time later in the process to fix.
A Lack of UX Maturity
A UX Designer may bring a range of skills to the table from research, service design, design strategy, UI (user interface) and front-end development. As organizations mature in their UX implementation, they find they need designers at both a leadership/discovery level working with product management and architects and at an implementation level working closely with a single dev team. They may also need specialists like UX Researchers or Service Designers, depending on the product or service they deliver. Often, organizations hire people thinking they can serve all these roles, and they end up becoming overwhelmed by the volume of work they’re responsible for.
Not Enough (or the wrong) User Feedback
If teams never do usability research, they rely solely on market data to tell them which features would provide users the most value. But, the market data only reflects users they’ve already captured. What about the users they’ve shut out due to poor accessibility support, biased language, or other design decisions?
Too Little Documentation
UX Designers and Product Management flounders when they’re asked to guess whether a feature is a good idea. Turns out, there is no such thing as “common sense design.” Teams need to conduct design sprints and focus groups to determine the user needs, and they need robust quantitative data on how users are moving through the products and services in order to create effective solutions to the problems they’re experiencing. If teams don’t have UX documentation like user journeys, JTBD (jobs to be done) frameworks, service blueprints, personas, analytics and user statements to get everyone on the same page about the user problem the group is solving, insights from any UX or market research that was done never make it down to the teams who are building the features.
Too Much Documentation
Because so many designers have a passion for good aesthetics, they are concerned with how polished their work is. However, high-fidelity is the antithesis to the agile methodology. Designers can sometimes too much time finding the right balance between readable and aesthetically-pleasing documentation instead of quickly providing the valuable insights they’re trying to convey.
Lack of Collaboration
UX Designers may create designs that provide a high value to users, but unless they have experience or training in developing products (or a design system to pull from, check out my article on why you need a design system here) they inadvertently can create problems for their developers when they try out cool or innovative design patterns. If there isn’t a compelling reason for a design decision, it can create the impression that designers are difficult to work with and impact team morale.
Design is First to Get Cut
The market needs and the user needs are only in alignment when the buyers are the users (typically B2C). In many applications the two groups can have different requirements that sometimes compete for limited resources. UX Designers are often asked to skimp on research and/or design refinement for the sake of time-to-market. Sometimes, features are cut altogether because limited developer resources are going to implement features that have a more obvious ROI.
Losing the Big Picture
A UX Designer’s job is to maintain team alignment and advocacy for the holistic experience. When Agile teams focus on just the logistics of how to get the work done, they can lose sight of the big picture. Breaking work down into sprints can also accidentally break it up into ways that hurt the usability of the product, create redundant work, or make it so that features can’t be tested for usability or accessibility.
What I’ve Found Works
Team Dynamics
- Embrace the Human-centered Design process for generating an understanding of users’ needs and commit time to going through that process even when the solution is “obvious.” All levels of leadership need to embrace it, recognizing that qualitative data is as important as quantitative, and furthermore that user and market requirements should carry the same weight in decision-making. N/N Group published a recent tool to gauge the UX maturity of your organization. Take the quiz to gauge how well your organization has embraced UX Design and HCD.
- Understand each others’ language and roles. Don’t just read job descriptions. Team members should learn the jargon, artifacts, and processes of the other roles so they value their contributions.
- Initiative documentation shouldn’t be considered “done” until the user experience artifacts (user stories, user journey) are included for explanation of scope and impact of the initiative.
- UX Designers should take the time to present the thinking behind the solution as well as demo it to the whole team. This provides context to individual features and tickets when developers start working on them.
- UX Designers should attend Agile ceremonies like stand-ups and grooming sessions and contribute to the discussion as full team members. They should be prepared to ask and answer questions.
- UX Designers should do a design review before code is committed and demo the released functionality to the organization. This allows them to reiterate the holistic understanding of the problem and confirm that the objectives were met from a usability perspective.
- Product Owners need to maintain updated links to design artifacts in all initiatives, features, and tickets. While hopefully the team is collaborating and communicating changes back and forth, but there has to be a single source of truth for what to reference when a developer picks up a ticket.
- Conduct team retros and discuss what is working in your particular organization so that you can refine your process to fit your team composition.
Research
- Qualitative research should start from a universal design perspective. A product or service that takes into account a broad range of users and creates experiences they can all access without struggle is a more successful product (and doesn’t leave itself open to a lawsuit).
- When conducting design sprints, choose different representatives from a very diverse SME (subject matter experts) pool for each round of prototyping and be ready to scrap what’s been done and start over if the SME pool shows it’s not working (N/N Group says it takes about five users to define the rule, but if they’re all one type of thinker or from one background the feedback is unintentionally biased).
- Product Owners and a representative from the development teams should be involved in design sprints or co-collaboration sessions. Their input and contributions to the design process are invaluable for generating shared ownership of the solution, aligning on the problem it solves, and facilitating that knowledge to the rest of the team.
- Cultivating and maintaining relationships with users who will give feedback takes time and resources to develop and manage. Incentivize users to participate. Make sure there is the bandwidth to recruit, schedule, and manage research channels.
- At a certain point, however, it takes experience as a UX Designer to know when you’ve got “enough” data to make an informed guess and move forward with the solution… and it will always be just an informed guess. It’s okay to “fail fast.”
Prototyping and UI Design
- Prototype and brainstorm in low-fidelity as long as possible.
- A picture says a thousand words. Use tools like Invision, Adobe XD, or Figma to generate walkthroughs for the intended solution. Product Owners need to add the links to these context-building design artifacts to epics, features, and tickets so the team has context after they’ve been presented.
- Implement a Sprint 0 for embedded UX design and prototyping, and be prepared for it to go awry if they discover some false assumptions about the market and users. Change is constant, right?
- Implement a design system, ideally one that was created with accessibility device support in mind. No, really.
The Case Against Hunting for Unicorns
Despite the changes that have to be made to accommodate the new processes, it is still better to have dedicated usability experts in your software development than not. In one study done by Lou Schwartz at the Luxembourg Institute of Science & Technology, researchers found that having dedicated UX resources on a team–rather than asking the developers or Product Owners to handle these tasks–had many benefits to the team and the product. In the study, they asked two teams to create an app tackling the same problem. One team had no usability support (UX Designer/Researcher) and was staffed by generalists who did all usability studies and design themselves, and one team had a dedicated UX resource. Involving the usability expert on the team had many surprising benefits to team morale, including:
- helping to maintain a constant pace in the team
- allowing other team members to be objective about the quality of work they produced
- helping the team feel like they were moving more quickly
- providing a higher level of confidence in the solution
One hypothesis was that having generalists in the team would allow more eyes to catch usability errors. What they found instead was that all usability issues were identified by users, not by the team members. The team with a dedicated UX resource produced more, and different, usability testing methods which showed to be more effective. At the conclusion of the project, the product produced by the team with a usability expert had a higher overall satisfaction score with less issues reported. Issues that were reported were considered less severe by users.
Conclusion
As Scott Cook says, “Success is not delivering a feature, success is learning how to solve a customer’s problem.” What good is it to have a streamlined process for building software if it’s a service or product nobody needs or wants? Knowing your customer, incorporating their feedback in the process, and providing solutions for their true needs are all ultimately more important than rigid timelines and budgets. More and more companies are realizing there is no substitute for having trained usability experts embedded at all points of the software development process gathering, validating, designing and testing solutions to tackle user and business needs. As long as teams communicate, collaborate and remain flexible to change, they will reap the rewards from incorporating the Human-centered Design process in their Agile workflow.
