UX Design in an agile environment

Design is not an island – observations of a UX designer.

When I first became part of an agile “Scrumban” team myself, it felt as if I was thrown into a washing machine running in spin cycle: I felt completely disoriented.

From that moment on “Agile” fascinated and terribly annoyed me. Annoyed, because the attempt to be agile often led to standstill instead of flow in my experiences, because the external reality often looked so much different than the internal team reality, and the agile rules of the game are by definition “easy to understand, difficult to master” (see Scrum Guide). But I also made many positive experiences, developed myself agile and got to know many inspiring agilists. I would like to share my transformation as a user experience designer in an agile environment with you.

Step 1: You are what you become

In my studies, agile project work looked something like this: Throughout the semester, we rolled over with ideas, experimented, collected all kinds of information, tools, knowledge and when the deadline came dangerously close, we sprinted through the implementation in a few days (and nights). I loved my studies and the freedom we had. But we were also pretty much among ourselves, designers among designers. In our projects we often covered the whole development chain, there was the freedom to learn the things we needed to implement our common vision, and in this way we were able to move mountains.

With my first work experiences, this bubble burst. Here I often had the feeling that I was only one thing left: a supplier. The design delivery always had to be on time (“the day before yesterday”) and innovative. Communication with the development department usually consisted of dictating further requirements for the design. The fact that this was not a working process became very painful when we had worked for six months on a new product for which there was never a real customer. It was time to rethink and redefine my own role.

The designer as supplier of innovative ideas

Memo: Even if everyone has their own background, there are more things that software developers and designers (and product owners, product managers, sales people, support people…) have in common than there are things that separate them – all of them have the goal to create a good product that can be sold and can survive in the market.

Step 2: When you’re swimming in a torrential river…

… it’s not so easy to escape the waterfall. Let’s fast-forward a few years: In a project that was roughly about the possibility of manual data entry, our UX team had put a lot of effort into identifying user needs by means of design thinking, and from this, developed and validated ideas and prototypes. The final user story was described by the product owner: The first step was to implement an MVF (Minimal Viable Feature) to see what the impact of the feature would be and how users would actually use it. In the end a CSV upload was implemented. Once the upload had reached the users, it was not usable due to the required data formatting. So the UX Team designed error messages and validation steps to help the user with the correct formatting. With a lot of extra work from the development side and from the user’s point of view rather a crutch than a satisfying solution. Everyone was frustrated in the end.

If you see a waterfall rushing down the cliff in your mind’s eye during this little story, you have observed the scenario quite well. One could also give this experience the title: “Design Thinking vs. Requirements Engineering vs. agile development”. The user requirements move from silo to silo and change and when the feature finally reaches the customer, it is no longer what he expected. And to make it clear right away: everyone contributes to this result.

Not so easy to escape the waterfall, especially if you have already made yourself comfortable under it

Memo: Scrum is not a process – neither is Design Thinking, Lean UX or Design Sprint. There are many empty spaces in the descriptions, connecting parts are not always given or unspecific, the attitude or mindset cannot be read. This freedom means that we have the possibility to create collaboration, but it also means that we have to do it, because it doesn’t happen by itself. In this sense: Let’s go back to step 1, the next iteration begins.

Step 3: Better together

There are many funny graphics on the Internet about “Integrating UX in Agile”. But most of them make me dizzy just looking at them, considering the many loops and roundabouts. And even the strict separation according to frameworks and methods still holds the danger of silo structures for me: How do we make sure that what we have already learned flows back into the process instead of the cat biting its own tail again and again?

For a long time, as a UXer in various projects, I have tried to make user needs the subject of discussion, especially by arguing. In one meeting, for example, we discussed which additional KPIs we could display on the dashboard. As a self-proclaimed “advocate of the users”, I argued that some of the existing visualisations already did not sufficiently answer the users’ questions and whether we could not make them more meaningful before creating further complexity. This sparked a discussion as to whether everything today really has to be simple “Apple design”. And we moved miles away from the actual topic. The realisation: Discussions of opinion rarely or never lead to solutions. My new strategy now consisted of gradually relinquishing my perceived responsibility for the user, in line with the motto: “User experience starts in the backend and does not end with the user interface.

My role has changed quite a bit since then. Instead of being a supplier or UX preacher, today I like to be a coach, moderator and method kit. I set up workshops that meet the current project needs and involve different disciplines in the design process. From time to time I get the feeling that I will become superfluous in this way. As a designer, however, I am and remain an expert in visualising things and making them tangible.

Better together – in the sandpit there is sometimes bickering, but together you manage much better to form great things from the loose sand

Memo: Simply tinkering with the methods and frameworks and following them ideologically does not make things less complicated and the end result no better. But then how do you actually manage to build bridges between islands and work agilely? Basically, the Agile Manifesto provides a wonderful answer to this from my point of view: Individuals and interactions more than processes and tools. So, get together and find out what connects you.

Step 4: If you are already agile, you cannot be agile

I heard this nice headline at the Agile Regulars’ Table in Karlsruhe a few weeks ago. And indeed, I’m always sceptical when a company says “it’s agile”, because in the end, agile always contains the mechanism of continuous change. Nor do I believe that design thinking or other forms of user-centered design automatically solve all major problems. After all, in the end there are usually ideas, but not yet any implementation.

The methods and frameworks help to create a good basis for opening up solution spaces and creating a breeding ground for innovation, or for initiating and timing implementation. However, simply connecting the methods in a process one after the other or into each other is not enough. Dialogue and reflection are needed to create an agile environment – in which all participants are ultimately involved.

Instead of letting yourself be spun around in the agile washing machine, you can also look at it from the outside to learn from turn to turn

Memo: For me, agile means “being able to react to uncertainty and change”. Since I don’t know what to expect in the future, my personal transformation process doesn’t stop, of course. In this sense: To a new one, back to step 1, the next iteration begins.

Note:

Anna Zinsser has published more articles in the t2informatik Blog, including

What does t2informatik actually do? One click and you'll know.