Are you considering introducing a UX designer into your scrum process and team of developers? If so, great!
UX designers are very useful and their work model fits right in with the agile approach. Iterations, flexibility, rapid development, optimisation – those are all in a day’s work for UX professionals. But for the whole idea to work out, you need to keep several things in mind.
Here you’ll find a list of 10 rules that we came up with at Usability LAB and RST Software. They’re based on our own experiences with these types of projects.
1. The UX designer must be a real member of your scrum team.
If you want the UX specialist and your programmers to cooperate efficiently, they all need to be on the same team: they must work similar hours, meet up, plan sprints together, participate in refinement, client reviews and retrospectives.
It’s best to make sure your UX specialist is fully available – and if full time employment is not an option, you should determine their exact availability. Furthermore, you should lay down the rules of your cooperation at the very beginning, focusing in particular on what value the UX specialist will be delivering to the rest of the team and how they should go about it.
2. Your team must understand the UX designer’s role.
Unease, distrust, maybe puzzlement at best – these are the gut reactions your developers may have when you first introduce a UX designer into their bunch. You might hear them say something like “We were doing just fine without him and always delivered projects on time, so why do we need another crew member? And what is he supposed to do, exactly? Scold us? Push us around? Monitor our work?”
It’s no wonder, then, that a UX designer joining a team with no prior experience of working in this setting can feel dispensable, unwelcome. In their woe, they might just sing “I’m an alien, I’m a legal alien…” That’s why you, as the scrum team manager, have to introduce the newest member to the rest of the team not just as a person, but also as a specialist that has a specific job to do.
Remember: not every developer may be aware of the nature of that job, so you should briefly describe to everyone what it is exactly that their new UX co-worker will be focusing on. And if you don’t get it all yourself, just let the new guy or gal speak for themselves. :)
3. The UX designer must understand scrum.
This goes both ways. You want the programmers to know why the UX specialist has just joined them, but you also want the specialist to understand how your development team works. If they have never worked in a scrum setting before, you must explain the methodology to them – tell them who the PO and Scrum Master are, what a sprint is and what it’s comprised of (e.g. retro, review, refinement and planning), and finally, what the Minimum Viable Product (MVP) is.
If you don’t do that, you will end up with a designer trying to deliver the same thing they’re used to: a fully functional, extremely polished UX mock-up that has been tested with users, given the client’s blessing and readied for implementation. But you don’t want that — you need your new employee to change their way of thinking and start using the agile approach.
4. The UX designer should have extensive knowledge about the product, requirements, and business needs
OK, maybe their knowledge doesn’t have to be THAT extensive, but they definitely should know just as much as the PO. Without that knowledge, they won’t be able to create the right workflows or design useful mock-ups for developers. Remember: your client might come to you with a brief or a list of requirements, but you can’t use that as the only source of truth. If your project has room for a UX designer, you must also plan the preliminary work that comes before actual development.
Before your UX specialist launches Axure or UX Pin, and before they even grab a pen and paper to draw their first mock-ups, they need to go through the Discovery and Define stages. During the Discovery stage, they try to understand an existing product or the concept of a product currently in development, research the competition, and – if possible – meet with users to learn about their current experiences with the product or their expectations about it. During the Define stage, they define the requirements that the product must meet – preferably with client’s participation, e.g. during a workshop meeting or a series of meetings. They create personas, use scenarios, and the desired customer journey. In other words: they work with the client to co-create the basis of MVP and a backlog.
5. UX design must be ahead of development
When you’re planning the first sprints, remember that your UX designer must create the foundation for the developers’ work. The sooner they get it done, the sooner your programmers can do their job. That’s why it’s important to split up the UX designer’s work (and the developers’ work) into separate stories that are not overly complex. The period of waiting for the first mock-ups can be used to prepare the development environment.
Consultations with devs
If possible, you should also have your developers participate in some of these preparations, e.g. in workshops with the client. This will let them better understand the product, user needs and business requirements. If you can’t arrange that, make sure to present the results of this UX development stage to the team. And I don’t mean that you should just send them the documents or a link – don’t kid yourself, you know they won’t read all that. Instead, set up a team meeting during which the UX specialist will tell the rest of the team what they’ve come up with so far and how it’s going to affect further work.
Sprint ahead?
You often see people mention the “Sprint Ahead” approach online. You can find just as many enthusiasts as critics of this method. The truth most likely lies somewhere in the middle, as it often does. Looking at my experiences so far, I can attest that the following approach has worked out the best: at the beginning of a sprint, we used the most current mock-up. This mock-up had the functions necessary to meet the sprint’s goal. We also initially determined which components of the backlog to use in the next stage. During the sprint, our UX designer consulted their work with others and worked on next views. Halfway through the sprint, we had a refinement stage, during which we refined the stories for the upcoming sprint and presented a UX mock-up that supported those stories. If it turned out that anything needed to be fixed or changed, or we needed a new view, we still had time until the end of that sprint to do this and deliver a complete mock-up (per stage, of course) to the planning meeting.
Want more? You can read the second part here: What to keep in mind when introducing a UX designer into your scrum team – part 2
