To include design in your sprint or get it done ahead of time? One tough question that product managers seem to be split in half. In web development the design is generally upstream and stakeholders wants their say. Also compared to traditional software you have more breeds of devs, front-end & back-end. You need to fit all that in a scrum mindset.
The Design process seems to never quite perfectly fit with scrum teams. There are many reasons for this but the most obvious one is that clients often wanna see the design well before the coding is started to have their say on the final product look.
. That makes for some headache, that is why product managers will often opt to put design one sprint ahead. It’s just easier to manage, but at what cost?
Striking a balance
On one side you get people that say you should never split design from development, all in one sprint.
1. Your user stories take two sprints for being done instead of one, big iterations are slower.
2. Design & development get split a bit, less collaboration on design creation, may miss some important answers.
3. Developers takes less accountability of the design
4. Designers get caught up between two guns, must deliver next sprint user stories but also help developers do mini iterations when the design does not work as expected.
Then on the other side, keeping both separate has also great advantages:
1. Most teams already worked somewhat like that, ease workflow between design & development
2. Easier to manager front-end devs workflow, always work to do
2. Make sure devs understand the user stories well, better estimation
3. Easier to manage designs flow, can get inputs from users & stackholder before going to development stage
I’m frankly not sure one option is always better than the other one. I guess it depends a lot on the team, the company, the culture you are in.
Which bring me to our last project At SSENSE. We recently had to build a CMS for our content team, this project was interesting because our content team creates custom layouts for each article & this is not something you can easily do using a platform like WordPress for example. Unfortunately like too much internal project, time was short. We had to build something fast, iterate fast & deliver it as soon as possible.
Our workflow is generally to keep design one sprint ahead. However with this CMS we were reign free, I built very strong user stories, very driven on the acceptance criteria & we started our sprint without design.
Our workflow
Front-end does basic wireframe integration based on our grid system
↓
Designer applies styling with css/rework base integration
↓
Integrator adds functionalities
↓
Designer applies styling/rework integration
↓
The team iterate together if any user experience issues popup or we find better solutions.
That meant our designer had to use more his CSS/HTML chops than its Photoshop skills, if your designer is completely unable to use CSS that’s another thing. However we were very fortunate to have a designer than can also code very well & with a good CSS framework, all is possible.
Is it really better?
For us this workflow allowed to find UX issues sooner & iterate faster than our usual workflow. I really liked how this worked out with the team & everyone seemed happier with the workflow as wells. Now how can we replicate this workflow on all our projects?
Looking at other teams in the wild that do design ahead they are generally not happy with it, it’s not a lack of trying to integrate it, but it’s hard to find solutions to that problem since design involve generally more than the scrum team & stakeholders have generally some control over design & processes.
More ressources about scrum & design processes:
The Sprint Ahead — Sprint Behind Tango
Designing Ahead: The Good, The Bad, and The Ugly
UX working a Sprint ahead is full of FAIL. Work as a single team instead.