Preface

I am writing this blog because I am frustrated and tired of having the same conversation over and over again about how UX ought to be integrated into Agile development practices. I am writing this because, as someone who has worked in every role from UX research and UI design to software development, product management, and requirements management, and on everything from e-commerce to self-driving cars to mobile apps and logistics for the United States Air Force, I feel I offer a somewhat uncommon perspective. I am writing this quickly to get my thoughts down on paper, based on my own experiences, without the necessary citations and rigorous research and review that would (or ought) to be required for something like an actual article or a book. In the spirit of Agile, I am writing primarily to learn—to get something out there that I am proud of but not too precious of to be defensive, and by forcing myself to articulate, in plain English, the nonverbal thoughts and intuitions and learnings I have accumulated over the years that guide my values and perspective. I write to improve myself, and hopefully you as well.

So let’s go.

What Is Software Development? And What Does It Actually Entail?

For the purpose of this article, I will focus on software where a client has a user base with existing needs and processes and for which the client has decided that custom built software is the appropriate solution.

In this sense, software development is simply the creation of a solution that utilizes, at least in part, software code that can be run reliably to satisfy these needs. Again, for the purposes of getting this article out fast and focusing our discussion, I will focus on user-facing software where the user base is not the client themselves but a separate audience. (E.g., a pothole reporting system being developed by a local municipality—after some freeze and thaw here in St. Louis, potholes are definitely on my mind.)

Of course, this definition of software development is too reductive and entirely misses the point. The challenge in software development is rarely writing code, though dealing with obtuse frameworks, poorly-organized architecture, unusual bugs, and cryptic error messages are always frustrating and often a time sink. The real challenge in software development is understanding where to use code and how to streamline everything that would get in the way of writing value-delivering code. These potential blockers include:

• Basic intra-team and team-client collaboration, communication, and working practices
• Establishing stable goals, requirements, and timelines
• Gaining working knowledge of systems, architectures, subject matter, people, resources, and processes
• Continued support of the project through value delivery and advocacy

To say, however, that the goal is to “streamline everything that would get in the way of writing code” is not to elevate software above other disciplines and tasks (as has historically and unfortunately been too often the case) but rather to indicate that, at the level of software development, well-written code is often a lagging indicator more than a predictor for success. Per Agile, good software is built quickly, unprecious, and delivers value without delay so that we can learn from real-world use how best to build upon our work—and if that work ends up being deprecated, whether due to changing circumstances or new learnings, we’ll have been glad that we didn’t spend more time building something wrong before we could start building something right.

At this point, though, I am burying the lede—how does UX fit into all of this, and how can UX support Agile software development?

How Does UX Fit Into Software Development?

User Experience (UX) has become the nom du jour of a field that has experienced rapid growth and many evolutions with the rise of computers, the web, and mobile. Thankfully, “UX” seems to have settled as a kind of umbrella term that gets the main point across—i.e., an emphasis on the end-user of an application in addition to the experience of that end-user. Usually those end users are people and that experience includes not only the act of using an application but everything before and after, in addition to the circumstances surrounding why someone might use that application to begin with.

As such, user experience folks—most commonly researchers, designers, and customer-focused developers—have a lot of value to provide to software teams that recognize their talents and opportunities for contributions.

First, I want to make clear that “UX” at its purest is really a philosophy and value set rather than any individual role. Everyone on a team is capable of and should feel confident embracing a UX mindset and advocating for good UX in their project. UX is not just for designers and researchers. And everyone, regardless of skillset, has an opportunity to contribute and take ownership over the user experience of the product they are developing.

As such, I made a matrix cross-multiplying the various roles on a typical software project—research, design, software, business, management, and the client—against key questions regarding software development and Agile/Lean practices. (I am not going to digress into a discussion of Agile vs. Lean, but my very reductive summary is that Agile is tactical while Lean is strategic; as such, they often go hand-in-hand and ultimately work towards the same goals and values—i.s., quick feedback loops, being responsive to change, delivering value incrementally, and transparency.)

Roles vs. Tasks

What is required for software development:

• (A) What are we building?
• (B) What is the value needed from what we are building?
• (C) What are our options for building what we need?
• (D) Build it!

What is required for Agile/Lean:

• (E) How do our requirements (i.s., customer needs) map onto distinct user bases?
• (F) What key questions or assumptions do we need or want to answer and/or validate earlier rather than later?
• (G) What dependencies & optimizations exist between requirements and/or between solutions?
• (H) How quickly can we build a working product (MVP) that at least one customer base can start using for real-world use + from which we will either receive momentum and/or learning?
• (I) When requirements change or need to change before an MVP or subsequent iteration is complete, how can we triage and integrate those changes into our roadmap?

There is a lot in this chart, and it is very much a first pass, so I am sure there will be both hurrahs of happiness and screams of disagreement. For the purpose of moving forward, I will just leave this chart here and move on.

As I mentioned above, when we talk about “UX,” we often mean research and design, so I will focus this article on how UX researchers and UX designers can integrate their work within Agile development processes like scrum, sprints, planning, and iterations without resorting to a Waterfall-like I-wish-we-were-just-a-sprint-ahead-mindset.

So, how do we make UX Agile?

How Do We Make UX Agile?

I really do think that answers to the questions listed above (A-I) are what UX practitioners can best contribute to a software project. However, the key is doing so with the rest of the team rather than in parallel or ahead of the rest of the team. That is not to say that no work needs to be upfront, that no dependencies exist, or that other team members need to participate in every step of the UX process, but that the upfront work required of UX is no different from that required of software, management, business, or the client. The problem often arises when the bulk of UX is done ahead of time (leading to a false illusion that “we know what we’re doing”), reactively (i.e., purely as implementation and validation of set assumptions and requirements—e.g., user testing), or separately (i.e., simply acting as consultants on a project).

I often use the analogy of a map when it comes to the utility of a user experience approach, but this analogy really applies for any role. In my many working experiences, I have often been the advocate of getting things down on paper, not just as a form of preservation and tool for communication but as an opportunity to eliminate assumptions and force alignment. A map—like an actual one, with roads and highways and parks and intersections—serves this purpose. It is hard to plan a route without knowing where the roads are or the topography of your journey, and while it is plausible that you could make it start to finish based on a rigid set of instructions, the best roadmaps are able to react to changing conditions on the ground. Traffic jam? Here’s an alternate route. Snow forecast? May have looked like the shortest route on paper, but best to avoid roads that might not be plowed. And that candle outlet store in Indiana? Well, if we decide to wait in the Dairy Queen drive-thru for fried cheese curds, we might not be able to stop by before it closes at 7pm. Knowing and discussing both our route and the landscape around it allows us to make sure we aren’t being unrealistic and that we’re all on board with our plan before everyone starts arguing in the car.

Analogy aside, good UX builds consensus and creates a foundation for responsive design and solutioning should needs or conditions change. For UX (or any discipline) to succeed, you need skin in the game. And to have skin in the game, you need to own the solution and commit to following it through, even if (and especially when) it needs to be adjusted to reach your goal.

OK—I’ve been talking enough in generalities. Let’s get real.

Agile UX Research

Advice #1: Stay Relevant

My key contribution here will be to emphasize rapid turnaround for clarifying uncertainties, resolving disagreements, removing assumptions, and increasing team-wide subject matter expertise using an iterative approach and utilizing the perspective, framing, expertise, and methodologies within a UX researcher’s toolkit. UX researchers should have their thumb on the pulse of both the team and the client and demonstrate that they can deliver results quickly. Formal methods should be used as appropriate to ensure accurate results that inform the actual question being asked, but often an adherence to scripted procedure slows down delivery, and in many product organizations, the most important insights will not require overly formal research and analysis. (Of course, some more regulated industries, e.g., healthcare or safety or social media, will and should require a more rigorous level of research in order to avoid user harm.) UX researchers need to balance speed versus reliability and use their best judgment as to when and how to prioritize each. UX researchers come with a wide variety of skillsets and talents, so it will be up to you as a UX researcher to use your talents to the best of your abilities, to communicate both the talents and the limits of your abilities to the team, and to ensure that contingencies are communicated and planned for ahead of receiving results. A good UX researcher is one that can communicate what they are learning to the team in real time while also communicating the appropriate level of confidence and accuracy in these learnings—the whole “I need to process results before getting back to the team” mindset is by definition incompatible with Agile. The goal here is to keep the team in the loop with what you know so that there are no surprises—i.s., things you knew or suspected weeks ago while the team continued to operate under a contradictory understanding of things.

Advice #2: Present Solutions

My second contribution here is that the ideal UX researcher not only collects results but is able to present these results clearly and in the context of actionable recommendations and solutioning. Doing so requires not only a deep empathy for the team’s needs but also often a good product sense; i.e., what insights will help inform product strategy and development. However, while I am still a believer that the best UX researchers have that product sensibility themselves, it is not required. So long as someone on or available to the team has that product sense, the UX researcher can collaborate with them to ensure that findings are presented constructively and does not come off as naysaying or irrelevant to the current work at hand. To use the map analogy mentioned before, UX research is not just mapping the landscape but also identifying the roadblocks that lie ahead, presenting the merits of various alternative routes to our destination, and validating that our planned destination is in fact where we would like to end up.

Advice #3: Be Equal

My third contribution is to emphasize that UX needs to become an equal member of the team that works collaboratively with software, business, management, and the client in shaping decisions and outcomes. UX alone may not be able to create this environment (we will discuss this in “UX Management” below) but they can spearhead this and take small steps towards establishing a rapport where their advice and efforts are requested by other members of the team on a daily basis. Once again, make sure the work you are doing is timely. Use your work to facilitate the work of others. Own your work, but make sure others take ownership of it too. The key here is to get other members of the team, including the client, invested in your work.

Advice #4: Document It

My final contribution here is an emphasis on communication through documentation. Good research is reliable, and if research is reliable, key themes and findings should be summarizable while still instilling confidence and trustworthiness. There is a huge and counterproductive misunderstanding over the second principle of the Agile Manifesto (“Working software over comprehensive documentation”). Many take this to mean that documentation is inherently wasteful. However, my understanding is that this principle is aimed mostly to counter instances where documentation is compensating for poor practices elsewhere: e.g., a lengthy User Guide because the software is unintuitive to use, or excessive technical documentation because the code is poorly architected, lacking comments, and hard to follow. As applied to UX research, documentation should aim to get everyone from new team members to key stakeholders up-to-speed on everything we’ve learned so far about a project through UX research methodologies—what questions we’ve asked, how we’ve answered them, how those answered have informed our product development—and without having to rewatch hours of videos or pore through unrefined research artifacts. This may in fact come in the form of a User Guide or technical documentation, but in the spirit of Agile (and its roots in contemporary product design), good documentation is “as little documentation as possible” (while still, of course, serving the purpose at hand). Your job is to tell a compelling story: where we are, how we get there, and where we’re going.

Agile UX Design

My contribution here will be to emphasize that whatever design work is done in support of product development should serve two key purposes—to facilitate communication and to establish a strong clear vision.

Advice #1: Design To Communicate

It is up to the skilled UX designer to understand how and when to generate mockups, prototypes, process diagrams, and other visualizations to facilitate communication and collaboration within the team and with the clients and/or users. Like with UX researchers above, timeliness and relevance are of the essence—design deliverables should serve to answer questions and present actionable alternatives. The fidelity of deliverables such as mockups and animations will depend on the question being answered and the visual understanding of the target audience. Certain exercises within the toolkit of UX designers like rapid sketching, mind mapping, SWOT-ing, and Post-It notes may or may not work with your team and may or may not be relevant to the task at hand. A good UX designer should not fight against this but instead adapt to the circumstances. Wireframes may be too low fidelity to build consensus and establish understanding. “Lorem ipsum” text may simply confuse participants, and mock data may end up digressing stakeholders into an argument about the realisticness of the data rather than the merits of the design itself. A talented UX designer is a moderator and should be adept in managing such design conversations that veer off track. They should ensure that all voices are heard and all concerns are raised so that everyone feels the ownership necessary over process and decisions in order to achieve consensus. Nevertheless, such advocacy does not have to fall singularly on the UX designer—once again, every member of the team should feel empowered to take on this responsibility if they feel adept.

Advice #2: Design To Lead

As to my second contribution, the reason a strong clear vision is so paramount to a project’s success is because it establishes hope. No matter how delayed the project is, how challenging a particular feature is to implement, how confounding certain research results are, the vision establishes that the project is possible. There is a goal, an end state, an ideal, and we as a team are working towards that ideal. The vision may lack details or specifics, but it keeps us aligned. It needs to be tangible enough that one can work towards it, and it should be flexible enough that when things change and the design is adjusted, the core vision remains the same. The vision motivates. As UX designers, you are unusually empowered to shape, create, and establish this vision. Still, the vision needs to be shared—the twist, of course, is when members of the team or client fundamentally disagree with the project’s vision. I would say that if this is the challenge you are facing, you as UX practitioners are doing at least your own job well. When such fundamental disagreements arise, management comes into play.

Agile UX Management

Ultimately, the success of any team and its team members is dependent on being given the opportunity to succeed, and too often that opportunity is blocked by management—i.e., the people to whom you or your team report, either directly or indirectly, whose decisions can overrule those of the team or whose consent is necessary to proceed with certain plans. This is by design something of a necessary setup—ultimately, for legal, organizational, and financial reasons, the buck needs to stop somewhere. But when it comes to integrating UX into the Agile development process, management can do so much more than simply not be blockers. Management can become advocates for UX even without any UX background themselves.

Advice #1: Actively Include UX

First and most obviously, management needs to make room for UX. That means not only hiring UX professionals and integrating them into their team but also studying and understanding their contributions. For those most directly involved in UX (like a team lead), that means including them as an equal team member in both team activities like standups and product development activities like stories. Going back to the much-misunderstood second Agile manifesto principle mentioned above, one key way of fostering collaboration is to have research, design, and software actively collaborate on building features together. This doesn’t mean that all three are literally assigned to and working on the same story but that questions are answered throughout the course of development rather than ahead of it via time-consuming and tedious “grooming” or “story refinement” sessions. (That said, story refinement sessions are still important and necessary—they just often get misused to try to spec out all details of story before work begins, creating less flexibility and fewer opportunities for learning and collaboration during development.)

In practice, this looks like a startup. The stereotype here of open office plans and desks made of plywood and sawhorses holds true: the reason this kind of environment is conducive towards “innovation” is because the people you need to talk to are right there—no need to schedule a meeting or wait for someone to respond to your Slack message. Key team members sit next to each other and are able to “swivel chair” towards each other to spontaneously work out something together. For example, maybe the engineer is having trouble populating a typeahead input for street names without the software becoming laggy. Rather than going it alone and trying to optimize the performance of an API endpoint the team may not even control, the developer can swivel-chair to their UX designer, explain the situation, and see what ideas they may have. The designer may come up with an alternative implementation that still solves the problem at hand and delivers the necessary functionality without using the laggy endpoint. Maybe rather than an active typeahead UI, they propose performing input validation in the background after the user has exited the input field. Maybe UX research overhears this conversation and mentions that one of their past studies showed that most users enter a previously-used address. Instead of a typeahead, maybe the ability to prepopulate the address fields would be of more value. Rather than binding themselves & continuing to spend time building something they used to think was necessary, the team—developer, designer, and research—reach back out to key stakeholders to see if this new simpler implementation is acceptable. After discussions, they table the typeahead functionality for now and quickly implement the alternative solution. (And once in testing, it may turn out that users don’t miss the typeahead functionality at all.)

Of course, when such a development occurs, management should be aware, either via daily standups, direct communications, and/or eavesdropping, that the plan has changed. (This is, to an extent, why I hypothesize that management tend to prefer in-person work versus remote.) Management then needs to take into account other factors when determining whether such changes are viable. Perhaps the client, for whatever reason, is enamored with typeahead functionality and has already built out marketing materials advertising the feature. Perhaps the slow API endpoint is something whose performance could be improved if they (rather than the team) send an email to the right individual to get the fix expedited. This is not to say that management should serve as a protective gatekeeper preventing any new development without their approval. Rather, the key is to establish observability over the team so that the team can work as naturally as possible while remaining transparent. As much fun as it is to surprise, surprises are what Agile tries to avoid.

Advice #2: Actively Coordinate UX

In addition, management—or more specifically, whomever is managing the development team—has both the perspective and power to ensure that work is being well-coordinated. The number one reason to ensure that development work is focused is to limit the amount of subject matter knowledge the team needs to maintain in working memory in order to complete their tasks successfully. The second reason is to increase the likelihood of the team discovering optimizations, dependencies, and misunderstandings through the course of their work. It is hard to understand how the puzzle pieces fit together when pieces are randomly picked from the backlog and much easier to find missing or duplicate pieces when relevant pieces are assembled together.

Advice #3: Actively Advocate UX

Finally, it is my position that the team lead—whether Scrum Master, Product Manager, Project Manager, or whatever title is used—needs to be fully invested in both the team’s and the product’s success. Such a statement should be obvious and uncontroversial, but the number of PMs who measure success by the numbers of boxes checked, points completed, or reputations preserved rather than value delivered quite literally kills my spirit and makes me want to start my own company. It is also my position that, in order to support this success, the team lead—i.e., the person ultimately responsible for the team, at whom the “buck stops”—needs to understand the backlog, roadmap, and current work state well enough to limit scope creep and coordinate efforts. This, by definition, requires understanding and caring about the product being built. When development gets painful, progress slows, and tensions rise, it is the team lead that needs to defend, fight for, and inspire the team; and it is not only unfair but highly risky to ask anyone other than the team lead to take responsibility for this.

Wrapping Up

As you may have noticed, this lengthy blog post, while heavy on opinion, commas, and em-dashes, is fairly light on “practical” advice. When it comes to templates, Agile ceremonies, or other tools, I am very much a believer in “whatever works.” I have successfully advocated for UX improvements to software projects using everything from spreadsheets to reports to diagrams to mockups to literally going out to lunch with the right people and listening to stories of their childhood. Nevertheless, when it comes to a more literal discussion of what UX + Agile look like on a day-to-day level, I may have write another blog post on the topic.

Please let me know what other topics I can cover or which parts of this blog post I can write better or expand upon. As always, we are always iterating to learn and deliver value expeditiously and continuously. That’s Agile.