I’ve been managing product focused web development teams for more than 5 years now, and I never felt I had design and development perfectly aligned.
All the products I’ve worked on, up to now, were heavily design/UX driven.
One way or the other, improving user experience was always the ultimate goal.
We used scrum all along.
We started by scoring each story (using scrum poker) with designers and developers. Awarding scrum effort estimation points as a way for the story to reflect design and development complexity.
1. Prior to each sprint the engineering team discussed the stories with the product team, making sure they were clear enough;
2. The product team prioritised the stories and passed them to the engineering team;
3. We scored each story among developers and designers;
4. We design and developed the proposed until the end of the sprint;
5. Stories were delivered into quality assurance.
This process had some challenging problems.
We had to design and develop before we had the chance to put work in front of users’ and get real users feedback.
This lead to a lot of inefficiencies. We were iterating over user feedback too late in the process and having to redo a lot of work when changes were needed.
After figuring out the problems we restructured the process and it looked like this:
1. The product team prioritised big stories (epics, as some people call it);
2. A discussion is then started using the story description as guideline. Every member of the product and engineering teams (developers and designers) was invited to discuss them;
3. After the discussion stabilised, designers were asked to make high fidelity mockups;
4. Mockups were then tested with users and iterated upon feedback received;
5. Based on the approved mockups we wrote the stories and got them approved by the product and engineering teams;
6. Stories were then prioritised by the product team;
7. Finally they entered the sprint where they were implemented.
In our teams, the designers are in charge of all the HTML and CSS.
This process was better but still troublesome.
The designers were dealing with the necessity of working on the development sprints, making all the needed html and css, so that the developers could then code, and they were also needed in the discussions for mockups. Without mockups we couldn’t do the user testing and without HTML and CSS we couldn’t deliver features to quality assurance.
Prioritising between this two different processes was extremely hard to do and often was leading to bottlenecks in our development flow.
Third and present try
We again needed to change something urgently…
So now we have three major blocks since the features enter the engineering team up to when they are ready for quality assurance:
A) Feature discussion
Input: Product team provides the big story outline;
Output: After discussing the story we have a clear understanding of where we want to go with the solution.
B) Design Sprint (design sprint has two kinds of stories: mockups, HTML and CSS coding)
Input (mockups): Feature discussion result;
Output (mockups): High fidelity mockups;
Input (html and css): High fidelity mockups after user testing and validation;
Output (html and css): Coding of the mockups in HTML and CSS;
C) Development Sprint
Input: Stories describing each feature + coded HTML and CSS;
Output: Feature deployed into quality assurance;
I’m still not sure if this is the right solution. For now it seems so but I’m sure we‘ll’ have to make adjustments further along the way.
So what have we accomplished with all this?
Although we ear all the “design driven development” buzz in every corner, what I find is that design keeps being relegated to a second class citizen status.
In a first version we can even start by allowing the design process to “drive” the implementation, but with no fixed place in the implementation process, quickly it’s placed in a reactive seat.
A bug appears, some correction adds a needed interaction to a previously designed screen and boom… “Hey can you just give some style to this new warning message we now need”… The designer will be asked to add style when the development is already done.
Having a defined structure where we put design always first, we are not only shortening the feedback loop but also making sure design is never an afterthought.
Probably this isn’t the best way to do it, but in our experience it’s the one that’s been working the best.
What do you think?