Agile & UX: A Love Story

Plenty of instructional content on how to incorporate UX into an agile working model already exists online. I’m not concerned with how to do agile UX. Doing agile UX will look differently at any given company no matter how rigorously the team has been trained in proper agile methodology.

Confusion about the role of the UX designer, what their deliverables should be, and when developers will have needed design materials to work from constantly threaten the efficiency of an agile team. No developer wants to begin estimating work from a design prototype that could possibly change. Thus we easily slip into a model where development happens on a schedule of agile sprints but design, in an effort to have everything delivered in a perfect state, starts to work waterfall. This situation will disintegrate into missed deadlines and frustration quickly. It seems obvious to have the agile designer conceptualizing, prototyping, and testing ideas on a cadence that is several sprints ahead of development work. But that doesn’t happen just because we want it to or it’s a good idea.

The first step is I take is to give up.

I give up on agile UX looking like neat little 2-week sprints of 10 story points. I let go of knowing exactly what epics I will tackle over the next 6-sprint product increment. I relax into the fact that, were he to look over my shoulder, Jeff Sutherland might not recognize my process as agile. The imminent or long term product plan will not land on my plate in a focused vision. I am the lens that pulls in those goals, combines them with an understanding of our users and heuristics, and then incrementally focuses, tests, and refocuses that vision so that it can be consumed by development and built efficiently. “Agile UX” doesn’t look quite right to the purist searching for a measured cadence of agile ceremonies. It’s a non-traditional relationship that still houses an incremental improvement toward a goal.

I’ve learned one thing from a lifetime of relationships: no one can tell me what to do to “do it right”. I want to focus here on the motivating ideals and experiences driving who I choose to be as a UX designer on an agile team. In my experience, once I am clear on “being” then the “how to do it” part inevitably takes care of itself within the constraints and opportunities of the current work environment.

Being a shameless UX promoter helps everyone.

They’ve hired a designer and know UX should be part of the development-to-release process. But the team may not know what that means specifically. At my current company, I was brought on as the UX lead for a product team that previously had no design direction. It felt good to have people so excited to have me around. But I soon realized this was because they wanted me to fix them..somehow. I had to sell what I can offer a team by looking at current conditions and sharing how I make them better.

Product owners didn’t know if new feature would be well received. Let me take that uncertainty away by doing user testing.

Developers are reading through user stories and not sure how to build a page to meet the requirements. Let me take the decision of how to place things on that page off of your plate by giving you a working prototype.

Offshore teams are at a point where a design decision must be made — but it’s 2 am in Chicago and I’m not online to answer their questions. Let me write a style guide so that design decisions that must be made in-the-moment are no longer a shot in the dark.

Stakeholders are planning the product roadmap. I constantly sell my visions of how to improve a product and ground these in specific trends captured during user testing.

Always be listening and initiating opportunities for dialog.

I set up regular meetings with developers to give them a forum for asking questions and as a means of informing them about basic design thinking. I get a feel for what they really need to understand what to do and can change my prototype accordingly. Twice a year I pause the dialog and take a “pluses and minuses” inventory of how our relationship is going so that weaknesses can be addressed early.

Working with distributed offshore teams coming from widely different cultures, it’s important for me to get a sense of how and when the developers will ask questions. Initially, I saw that being new to having a designer by their side, developers asked questions too late in their process. Their questions centered around issues at the end of their workflow and I could see that they needed design input much earlier on. I started presenting early drafts of prototypes and giving small (very small) design lectures. My goal was to shake things up and get questions flowing as well as continually reintroduce what I do and insert myself into their workflow.

I realized our developers thought of users as some dark mysterious force. I invited them to listen in on remote user tests. They thought I was joking at first. Then they were excited and amazed to hear the direct feedback and our users’ descriptions of their real work. For several, it was their first time seeing the end product of their efforts in its real-life context, and they were energized with this new insight.

My goal in opening this channel was not for me to learn to be a developer or to have them learn to design. We built a shared vocabulary and each became very familiar with that border where our own expertise ended and the other’s began. This learning has made our process much more efficient.

Be friendly with everybody. Yes, everybody.

Workplaces are replete with challenging and bristly personalities. It’s no fun to attempt collaborating with such people, yet collaborate we must. I’ve worked with very smart people who had good insights to share yet could never manage to deliver the message in a way that didn’t leave the recipient feeling insulted and on the defensive.

I have some steps I reach for in such situations to be centered. After a pause (of whatever duration I need to be calm), and putting aside a perhaps poor communication delivery on their part, I go back to what actual words were said and try to listen to where that person was right. I stay willing to change and improve and to treat that person with the dignity that they do not show others.

Some work situations are genuinely abusive and should not be tolerated, but most of the time it’s just an average human with low self-esteem. When I keep this in mind and extend kindness I’m amazed by how much situations improve and effective communication can proceed.

Be very patient

My first UX commandment is “Thou art not the user”. My user is not just the person who will consume my creation to meet their personal or work goals. My product managers are my users. They’ve babied a set of requirements and are trusting that I can breathe life into them. My developers are my users. They consume my designs with a lack of foreknowledge as to what changes are in store. Company stakeholders and upper management are my users. They don’t have the affinity wall of user data next to them and need me to bring that voice into the conversation. The same patient probing for underlying concerns and careful explanation of intention that I grant a customer must be extended to my teammates.

Teammates will ask questions that I’ve answered many times already. They will try to break a design rule “just this one time” because a time crunch prevents us from reaching for a bigger solution. They will lose the link to the style guide every 3 weeks. They will not read the style guide.

Last time I checked none of us gets to a level much higher than “human being”. I remind myself to simply give them reliable and current information uncoated by goopy expectations of “you should know this”.

Be reliable so that we may all be successful

I may be working on a feature that will grow and change over the course of many sprints. But developers want a stable design to estimate their work from and they surely do not want a prototype that changes once they have begun work. I’ve instituted steps to make sure they have a way to find the current prototypes for the latest product increment. Once I know a prototype is being used for feature work by development I stop working on it and make additional changes in a different version. I provide a matrix with direct links to all versions (and explanations) to eliminate guesswork. It’s simply my responsibility to be a reliable source of current information and to present this in as easy to consume way as possible.

Be efficient and scrutinize where time is spent

If I’m copying and pasting I’m wasting time. I’ve gone the route of having dedicated UX stories for tracking work sprint to sprint and it ultimately felt trapped on a hamster wheel of busywork. I no longer bother setting up stories specific to the user experience team. Product owners have already written backlog items as they develop the requirements for everything on the product roadmap. These we tag as needing UI/UX and I can look at requirements already written for developers by a product manager. I don’t need stories, but I do need clarity. I go to where that clarity is — in whatever backlog a product owner is building for eventual development. Whatever the process ends up being what I’m watching out for is any need for repetition of tasks.

Constantly maintaining open communication, remaining patient, and not getting into the habit of destructive inefficiencies are daily practices so I can best iterate upon and deliver designs in a timely way. There is no coasting or set-it and forget-it process. I hit reset and check my expectations of my team and my work every day. This is a partnership …not unlike a marriage… hopefully a loving one.

A note from Plain English

Did you know that we have four publications? Show some love by giving them a follow: JavaScript in Plain English, AI in Plain English, UX in Plain English, Python in Plain English — thank you and keep learning!

Also, we’re always interested in helping to promote good content. If you have an article that you would like to submit to any of our publications, send an email to submissions@plainenglish.io with your Medium username and what you are interested in writing about and we will get back to you!