A few considerations on the UX design process and how it fits into the overall scrum framework, from the point of view of Darius Tulbure, Head of Design at Qubiz.
For a long time, I thought that the UX design and scrum process didn't mix well. Each of my designer colleagues worked on two, three or even more software development projects at a time. There was a real pressure to deliver screens for a project, only to move quickly to the next one.
Under these conditions, there was no way for designers to be part of the scrum teams and be able to research, analyse, prototype, iterate, maintain a design system, and test designs in 2-week increments.
However, as our team grew, we realised the best solution was to dedicate more UX time to each project. This improved the delivered quality and the relationship between engineers and designers.
Even so, friction may still appear as fundamental differences exist between the UX design and agile and scrum development processes. One of them is that designers like to work on the entire user journey. Developers need to break their projects into small and independent units of work called user stories.
So, how do we reconcile these two perspectives at Qubiz?
Here are the 3 delivery models my team and I tried:
For some projects, we worked using a model that resembles the classic waterfall approach. We designed everything upfront before the actual Scrum team was scheduled to begin.
It worked well with small projects. Even so, eventually, we needed subsequent design support and iterations. So, we call this way of working the design head-start model.
This is an iterative approach. The UX designers and the rest of the development team are all pretty much part of the Scrum team.
In our experience, it works well for long-term, complex projects where a clear design foundation is in place. For example, domain and project knowledge, a design system, user feedback, scalable information architecture and so on.
In all fairness, I'd call this a quasi-agile approach because we wouldn't attend all the scrum meetings. Also, we would deliver big chunks of design every other day.
This is a combination of the two. In this scenario, we designed a sizeable chunk of the product before the scrum team was bound to start.
In this model, designers would consistently deliver for the sprints ahead to avoid dependencies. For a long time, this was our preferred way of working because it's suitable for big, long-term projects. It also allows us to see the big picture and design for more than a couple of user stories at a time.
In this model, we'd hold dedicated design meetings but would rarely participate in the classic scrum ceremonies.
These are all ok and can fit different project types and situations, but we can do better.
In my experience, after many trials and errors, here is how designers should ideally work in a scrum environment.
The UX process should always start with requirements analysis, user research, and problem understanding.
By involving designers in the first functional discussions, not only will they produce deliverables earlier, but they will also help define the solution. Indeed, there were times when designers alone performed the first requirements acquisition. More on that in another post.
Instead, have one or two sprints ahead to avoid delays caused by dependencies. First, this will help reduce stress within the team. Second, the whole team will have a clear image of what's going to be delivered in future sprints. Not to mention that it helps analysts write better user stories and acceptance criteria.
*Often "done" designs need to be updated, extended, refined, and explained to be properly implemented. So, designers and developers will collaborate on the same user story to a certain degree.
These typically are:
Extra: Design-specific meetings. They can be organised on an as-needed basis. Some examples of such meetings are:
Including a design-related status that Product Backlog Items (PBIs) need to get through, such as "design QA" or "designer-checked". This helps the team take design-related conditions into account before a user story is marked as "Done". This way, there will be fewer implementation inconsistencies, fewer ill-treated edge cases, and will likely reduce future design/technical debt.
Closely related to #4 is the concept of design process QA. This allows designers to review the implementation and find the potential differences between the design and the implementation. It could, however, point to inconsistencies in the design collaterals too!
Some professionals in the field suggest this step be taken before "normal" testing. But I reckon every team and project has its own style of working.
So this is our ideal way of working for scrum teams that include UX designers. Easy, right? Not really, but developing software, in general, isn't easy. However, having a framework such as Scrum definitely helps.
This isn't our first article on UX-related topics. Check out the one that provides easy UX tips for developers. Or the one that argues that projects developed without UX designers end up being more expensive.
