UX design is team work
How the practice of user-experience design is changing with (agile) teams.
Years ago, when the company I work for grew larger, we had the illusion we needed a design department, a front-end department, a development department and so on. At that time, a large part of my day job existed of User-Experience Design related tasks, like writing functional specs, wire framing and prototyping. It didn’t take long to find out that this department and waterfall approach wouldn’t work anymore for us: we went Agile.
A lot of people in the UX Design field struggle with the transition from waterfall to an Agile/team process. Because we were doing very well, right? We had a complete workflow set-up. We had this great list of deliverables. This old play-an-department thing was absolutely brilliant for the UX Design discipline. Everybody seemed to be happy with us.
Well. We thought.
Because I actually think that our old UX design workflow was one of the main reasons we switched from waterfall to an agile process. A lot of our deliverables, whether they were wireframes, flows or specs, implied that we could grasp the whole product in advance. The deliverables gave security, to our clients, sales persons, developers and others.
But especially in the digital industry, I think this was a false sense of security. Projects went out of scope. If predefined design decisions didn’t make sense – to developers or others – they were hard to alter. Functional specs turned into contracts instead of living working documents.
Team work
About 6 years ago we decided these design/front-end/development departments were not working for us. We moved to agile, or better said: team working.
We experienced clear benefits:
- iteration, more possibilities to adapt to new insights and priorities;
- no department culture, let’s see if you still will say that ‘that developer’ doesn’t get it, when he is sitting besides you;
- better insights in a project, every day we have a daily stand-up to track progress and problems;
- better collaboration, clients can join and become part of the decision making;
- working products, with fixed budgets and short time planning.
But also for a better user-experience, I think there are clear reasons why we should adopt these new principles.
“The biggest irony of the shift to Agile is that it’s exactly what the UX world has been seeking for years. Yet now that it’s here, we’re wholly unprepared for it.”
— Jared M Spool
We were also unprepared, but are much more experienced now. I would like to take you through our learnings and explain how I think we’re managing to keep a strong focus on user-experience after our shift to agile.
What we’ve learned
(and what keeps changing)
Before I move on. User Experience Design can become quite an abstract term which focuses on many domains, from research to interaction design to visual design. But also offline or online. So I would like to show you examples how we have managed to embed UX tasks in our process. A lot of them are interaction design tasks, but also visual design, et cetera. So I’ll just call it UX design. The learnings below, until now, are from us: a digital agency, that works agile.
1) Make UX part of the team
We build our products with teams of 4 to 6 people. One or two developers, a front-end developer, a designer and a team leader. The team works with a backlog that contains of User Stories. Major design decisions are all made during the sprints by the team. Our teams have built large online platforms, responsive websites and native apps. In all these projects, no one had UX designer on his or her business card. But, to get to this result, we did a lot of UX tasks.
The role of UX designers is changing. We no longer OWN the user experience of the website we’re designing. Our projects are getting more complex, have to work on different screen sizes, devices and different technologies. I’m not suggesting there can’t be a dedicated UX designer anymore. I can still perfectly imagine a project where somebody is sketching, making flows etc. full-time in a team. But we mainly see UX as a competence, instead of a discipline.
More skills, less people
Our projects ask for more skills. While productive teams ask for less people. Less specialized people. The team constantly has to make decisions that influence user experience and flow. I believe that these skills are already there. That the multidisciplinary teams can work together to solve UX design problems.
When we started making the transition to agile teams, we also added UX to the set of skills that everyone at the company should master. Of course this depends on which role you will fulfill in the company. Naturally we want our Art and Creative Directors to have a high level of UX skills. But our developers and front-end developers also have a great sense for design and user-experience. Every team should have a certain level of UX Design.
User-Experience isn’t just the field of designers. Everyone should understand what it takes to create great user experiences. And the different perspectives makes this better. Our designers and developers are not just designing or developing. They’re solving problems, that should work as good as possible. Code, is just one of the ways to reach that goal.
2) Become a UX design facilitator
But what about prototyping? Wireframing? To quote Jared M. Spool, once more:
“Agile teams don’t care for deliverables. The Agile Manifesto values ‘working software over detailed documentation’ and ‘responding to change over following a plan.’ In an Agile project, you can’t just drop the deliverables on the table and move on.” — Jared M. Spool
At the start of the century a lot of us didn’t work with development iterations. So, as UX Designers we filled up our toolbox to deliver completely defined designs because they were needed. With teams, UX is not about dropping a bomb (deliverables) and running away, anymore. Techniques like card-sorting are tools. Tools that should make things clear for everyone, not just the ‘UX designer’. If you’re an UX expert, an important role is to help others learn these techniques so that they can use them.
Organise workshops, train team members, sketch together. Make sure, all team members are capable of making decisions that influence user-experience.
3) Embrace that everything will change
Once you’re working – on responsive designs, apps or other interfaces – in an agile team, you know one thing for sure. Everything will change. Constantly.
So instead of getting frustrated, we can better embrace techniques that facilitate experimenting. A way to do is, is to initiate a sketching session. One of my favorite techniques is Sketchboarding. A sketching technique by Adaptive Path, that let’s you come up with good solutions together in a team, in a really short time.
With Sketchboarding, it’s it’s all on paper. Which makes it really easy to discuss solutions and change them with the team if needed.
4) Research and design up front, but just enough
We moved a lot of UX related work from ‘big design up front’ to development sprints. Is there still a role at our company for UX research? Usability? Of course there is! As you can imagine, these teams work in sprints of 2 weeks. In these sprints the focus is on completing user stories. There is less time for extensive research. So what do we prepare?
We do what’s needed.
For example, for a recent project we tested with the target group before we started sprinting. We first wanted to know what their feedback was, and created mock-ups to do so. The whole team, including the client, knows that the eventual product could become radically different than our tested designs. But it gave us more insight in advance of building, and we could base the user stories on the testing results. So with research, if it’s needed in advance, we’ll do it. In between sprints we usability test with target audience, which provides valuable feedback for future development.
Besides research, we prepare visual design direction, because it needs time. Both for us, as for the client. But even in this phase we try to make them suitable for agile. For example with Style Tiles, a more abstract definition of the visual design.
A compromise?
Do I mean with UX design is team work that everything should be a compromise? No, contrary actually. Everyone should focus on what they’re best at. But whether you like it or not, the eventual User Experience, will be a result of the complete team, from researcher, to copy, to development. In that perspective: I think that waterfall is the real compromise.
