Scrum and UX-design
While scrum has its own flaws, it is a wonderful software development framework. It’s especially useful for teams not yet fully mature or where there is a lot of dependencies/need to plan communication etc.
What scrum is not describing very well is how to manage all the other important aspects of delivering a feature or product. One such is UX-design (Even SAFe is very vague how to actually implement UX-design). UX design is not just simply creating a pixel-perfect design spec for front-end development. It’s tasks such as research, prototyping, testing, copywriting and validating prototypes. Scrum makes it feel that these things happen magically in the background and the designs and texts are ready and perfect when the development team needs them.
Scrum has been designed with mostly software development in mind. The goal of scrum ceremonies (certain meetings that occur each sprint) is to assure that everybody is in-sync and that issues are unveiled timely. For this to happen, the right people must attend these meetings. Let's assume that the UX-designer is not 100% dedicated to the team and/or the whole team is not sitting in the same room (very likely scenario today). This creates a situation where the UX-designer is not always around whenever the developer has a clarifying question.
Let’s look at some of these ceremonies.
Product backlog refinement
During backlog refinement (formerly known also as backlog grooming) the dev team goes through the prioritized list of backlog items and tries to understand what exactly needs to be done and how much effort does it take. I would approximate that about the first 10% of the discussion with each item is about ‘what’ needs to be done (if the PM/PO has done a good job) and all the rest of the time is spent on the technical details. Then the developers guestimate how much effort each item will take and then the item is then ready for planning.
During refinement, UX-designers input is needed when there is a question about the design, missing interaction, not drawn out use-case etc. The design specs are never 100% perfect and shouldn’t be. Other 90% of the refinement, the team discussing technical details to make the task granular and transparent. For a designer to be sitting out the whole refinement is a waste of precious designer resources.
Sprint planning
The team takes a prioritized and refined list of items from a backlog and commits what they can deliver within the sprint. UX-design tasks are not planned or refined and I think you shouldn't even try. UX-design tasks are inherently very different and need their own process.
The problem
This described above can end up in anecdotal situations where:
- Development is done before designs
- UX-testing is done after releasing to customers
- The item is developed based on the wrong designs
- Designs are not feasible
- The item is not refined and consequently not planned into a sprint because there are too many questions
You can’t just fit UX-design into the same cadence as your sprints. UX-design must almost always take into account the product and user experience as a whole. End to end. The work on more complex tasks might need to start months ahead of the backlog refinement because research and prototyping take time. Sometimes, during this, you stumble upon something new and need to change plans, iterate and pivot.
Solutions
If it feels waste to keep UX-designer for the whole refinement, arrange the discussion so that the first half-hour is dedicated to items where UI/UX is relevant and let designer go for more technical discussions later. During the first part of the refinement, the designer can answer questions and learn about issues that need prompt action. This is a compromise but it’s better than not having a designer at all during refinements or boring her with all the technical details.
Draw out the current process
If you have a problem with any flow or process always start withdrawing it out as detailed as possible. Even if the process itself is really bad and worthless it's still worthwhile visualizing it. Find problems and bottlenecks in the current process. Whatever flavour of scrum you are wielding you should have scrum retrospectives and if there are any issues with designs then there should be enough feedback from the team. List the problems and what they might cause. For example:
- The developers see designs first time during sprint refinement. This makes team feel that they have not been involved in the process of how to build. Unused potential. Some designs are unviable or unfeasible, the designed solution would be very slow or super expensive.
- The designer does not take part in refinement or sprint planning. The development and designs are not in-sync. Waste in updating UI later. The designer has little info on what the team is currently working on. The team has little info on what the designer is working on.
Propose a new process
Remember, the new process does not have to be perfect. It just needs to be better and it should address at least some of the problems you listed down. You can and you should improve and iterate. Discuss the new process with your team and monitor if the same issues still arise during retrospectives.
Examples
We came up with a new board to visualize the design process and address the problem where nobody had a clue in what stage designs were. So far it has worked well with both small (a new button) and large (a new mobile application) design tasks.
Usually, a product manager or product owner creates design briefs (ask your UX designer what she expects from the brief) into Drafts. But it can also be a UX-designer herself. The Drafts is sort of like a sprint backlog but not quite. We use it as a place to keep a backlog of problems to be solved. E.g ‘high number of users can’t figure out how to X’. Not all problems are equal in severity and impact and sometimes it takes some time to collect data or validate the problem. When the problem gets a priority to be solved then we discuss this during a ‘Design meeting’.
Design meeting is an additional weekly (sometimes bi-weekly) meeting. It's for the development team, UX-designer, product manager, product owner, and some stakeholders based on what is on agenda. The meeting is optional for the development team members (those who feel they want to give input can), but at least a team architect or some other senior developer must attend. The goal of this meeting is to discuss what (why should be described in the brief) we will build in the time horizons up to a quarter of a year. This is a time and place where the development team has a chance to give early feedback and input about possible solutions.
In later phases, UX-designer can present design mocks, testing results etc. The team knows that until an item is in “ready for development” it is not ready. Additionally, if there is a need for a copywriter to verify texts and need to check if designs work with translations you can add these as sub-phases.
We try to sync design tasks to be in the “Ready for development” for the time they need to be in sprint refinement. This board and weekly meeting give some sense of urgency to the tasks that the development teams need to be ready. This helps with focus.
The items should be on this board in the ‘Monitoring for success’ phase until they are released to the customers and whatever metrics you wanted to improve start improving. It's sort of a good reminder. When a hypothesis fails (metrics not moving in the right direction) you should revert the change, find out what went wrong, learn, and start again.
