A Solid Way To Combine Agile Development With UX Design Work

There is no question that agile development has revolutionised the way software is made. Over the past 15 years or more, Agile has become the method of choice for most software development, whether it is Windows applications in C++, mobile native development in iOS or Android, or web-based applications. What makes agile development so powerful lies in its name: flexibility and agility, with quick setup and fluid implementation of features in a two-week sprint (Scrum methodology). Even if these features are introduced later, they are put in a backlog and introduced at a time when it makes sense.

Agile development is most often used these days to produce software, not so much for research & development (although it wouldn’t be impossible to do that with it). By design, a methodology like Scrum has a robust structure that is designed to produce results that lead to a final outcome, which can be an MVP, or a proof of concept, the refinement of an existing application, or simply a 1.0 version of a product.

Efficient production

When a company makes a product to be released on a market, by the time it goes into production, it has already been through R&D, it has been ideated, concepts have been developed and refined through testing, and prototypes have been used to determine the final version of the product to be produced.

It’s not much different for software than it is for hardware products. Think of agile development as the factory that produces a product.

By the time an application enters the Scrum workflow, it should already be defined, use cases should exist, user stories should declare the goals for the product’s features, and time estimates should define how long it will take to build or code these features in increments.

Common conflicts

UX designers and developers often struggle to implement UI features in the final product. Engineers come with a feature architecture of a web application and ask UX designers to create screens with UI elements for interaction. UX designers, on the other hand, are left scratching their heads because they’re being asked to create something on the fly for which they have no concept and know virtually nothing about the product’s users.

Treating the design process as part of Scrum is doomed to failure. It can never make up for the lack of time invested in research, vision, concept, prototyping and testing. Designers, like feature architects, need time to gather information, think about structural and flow elements, interaction connectors and expected outcomes, and then define user flows that allow them to create prototypes. They then test their hypotheses against these user flows and prototypes to see if the product actually does what people expect it to do.

In such circumstances, a clash between developers and designers is almost inevitable. If the UX designers demand more time to research and develop solutions, the developers will be stopped in their tracks and prevented from starting the first production sprint.

The cost of incompatibility

What unfolds from here is often a chaotic mess: UX designers rush to meet the impossible deadline. They attempt to create hypothetical use cases and user stories without ever testing them with users. They are forced to believe stakeholders who have their own hypothesis of what they think users should do with the application. No one has time to find out what users actually want.

But the software engineers get what they want, they start implementing features, and soon it becomes clear that a lot of pieces are missing, assumptions have led to holes with features that don’t work well or don’t make sense at all. In the worst cases, a sprint has to be cancelled or restarted from scratch. One of the biggest programming scare words I have come across is “refactoring” - the complete reproduction of the same thing from scratch.

These clashes can lead to a culture of cynicism and hostility. The basis for trust is quickly destroyed. Developers begin to claim that UX designers don’t know what they’re doing, and designers become frustrated, claiming that they weren’t given the time and space to develop a good UX concept.

An idea with potential

There’s a way out of this dilemma, and I successfully implemented it when I was head of UX for the Swiss government’s “DaziT” digitalisation programme.

If agile development is the production part, UX design is the research & development part.

Agile processes like Scrum are all about efficiency, incremental work towards a tangible result, and producing features. Design, on the other hand, is about researching, understanding circumstances and expectations, developing use cases, figuring out user flows, and prototyping ideas until you have a product with interrelated features that, because we have tested it with stakeholders and potential users throughout development, we know it will work.

That said, there may be things we discover after the product is released. But we will have a good implementation of a first release of something that does the job as expected.

Development without delay, design without hassle

How can we combine the UX design process with an agile development workflow like Scrum?

There are several methods on the design side that allow for a better implementation of design with development cycles. Google Ventures came up with Design Sprints, where the idea is a shortened design process focused on the most minimal requirements. A design sprint lasts two weeks and is about prototyping concepts with fast decision making.

There is also the Double Diamond, which was popularised by service design and has since been adopted by many design disciplines. Contrary to popular belief, the Double Diamond process doesn’t have to be as slow as its reputation suggests.

Whichever method you choose, at its core it’s always the same: a process with progressive steps to achieve a useful and usable outcome. As I’ve written before, UX designers need to research, create a vision, develop concepts and prototype ideas to test them, and through this process we will end up with usable user flows that make sense and implement the features required by the product.

A funnel that produces a dense result

Design is a processing engine. You start with what you don’t know and gather as much knowledge as you can. You quickly divide people’s perceptions, expectations and circumstances into groups that relate to the product you’re going to make.

The general idea here is to replace assumptions with confirmed indicators, something to build upon.

Then you take what you’ve learned from stakeholders, related services, technology requirements, future user expectations. Maybe you’ve created a future user journey map, and now you start writing use cases and user stories.

Your user stories will become user flows, a first step in developing ideas and prototyping them, and from here you can easily think, make and check if the flow works, until you have developed a concept for each feature required for the product.

Of course, there are a lot of unanswered questions when you start. You start with an open mind. And as you progress through the process of turning concepts into ideas, your process funnel becomes narrower and denser as your product takes shape and clarity.

How long does it take? The real answer is as long as it takes - but of course we want to deliver tangible results in a timely manner. It all depends on the size of the job and the number of features and functions in the product. More UX designers don’t necessarily mean faster results. It helps to divide larger product projects into several cycles, just like in agile development.

Ready for production

During the DaziT digitisation project, we developed different software with completely different scope and number of features. A small product with maybe two or three features would take about four to six weeks to develop in design. You have to find your own pace and comfort with the time and space you are given to produce solid user flows and prototypes.

Once you have a set of features ready for production, it’s time to enter the production cycle. While you have been working on the prototypes, you have been testing your ideas with users, stakeholders and feature architects. So now you can turn your revised user stories into sprint tasks and easily describe the goal of each feature and the expected outcome for the user.

Now - it’s important to understand that this way of funnelling your design work into a Scrum sprint is not meant to happen once only. You can’t “finish” a final prototype and hand it over to the developers so they can start working on it and never turn back.

The whole idea here is that this process is collaborative, a woven process, and you drop feature concepts as you get them ready. Only what everyone agrees is ready for production goes into the next sprint. This is up to everyone involved, but most importantly the project manager, the scrum master, the architects and the UX director (or Head of UX).

Reviewing steps and revisiting concepts at different stages to see if they’re going in the right direction is a continuous, seemingly never-ending process. You can deliver many use cases and user stories at once, or just a few - the important thing is that the agile development cycle is filled with tasks that can be performed without being held up.

Conclusion

A culture of hostility and cynicism is hard to break. Don’t let it get out of hand, and if it has, try to reset the game and meet each other on the same level of understanding and respect for each other’s fields.

Developers and designers are literally meant to work together, and the better you do this, the more trust can be built. Regular meetings and review sessions will help to arrive at the same conclusions. Consistently reliable results will solidify your collaboration and inevitably lead to better products that satisfy everyone involved.

Comments