In the first article I described combining User Experience design with Agile timelines by having the design team be 1 sprint ahead for a specific project. But at another engagement, the development team had a steady weekly sprint rhythm, and plenty of backlog for an already live product that needed new features and continuous improvement. Slotting design and prototyping efforts into the weekly sprints made no sense, as this pre-development work was very separate from the development team, and would not impact weekly releases. Doing user research, doing user testing, looking at comparators and competitors, trying alternatives, making a prototype, deciding on tests, workshopping and all just doesn’t fit weekly schedules, nor need it.
Our Product Manager, already brilliantly straightening out the backlog and pointing process, suggested creating 2 streams: one for design, and one for development. Each stream would have its own Jira board, but design would be kanban, and development would continue for weekly sprints. She wrote the design stories based on management, and product ideas, and prioritized them along business and user priorities, with my input on structuring the work. I would pull the top one or two design stories and put them in flight.
The design stories would be worked on with whatever tools of the User Centered Design cycle as required to finish. When a story had been explored, prototypes, tested, discussed, workshopped, the results would then be turned into by us into stories on the development board, with the designs and justification attached. The product design team, by that time, would have worked so close in the process I would not even have to present the designs for grooming or sprint planning, as the Product Manager would know all the nuances. This way, the design stories could take the time they needed, but I did have a responsibility to stay timely and keep the development pipeline filled.
Designing in the Browsers and Boundaries
One issue that we did not fully work out during the engagement was how to fit in Designing in the Browser. The visual designer I worked with on the green stream of work had also become an accomplished coder, and when we designed together he would create the designs directly in CSS & HTML, bypassing any comps stage. This means that the resulting design was guaranteed to be implementable–we pretty much had just coded it during the design phase, save for JS wiring–but some of the resources for the gray stream had been put into action before stakeholders had seen the results. The end result was delivered faster in the end by being able to skip the comps stage, but there was a certain unease that committing resources to coding had happened too early and could have ended up wasted. Unfortunately, we never got to the point where we could prove or disprove that designing in code was as cheap as whipping up a quick Sketch comp for people to approve or steer.
Next: Handing over Minimal / More / Complete
One of the issues that arose mixing Agile and UX in two streams like this was the amount of fine-tuning that had to be done after exploring and settling on a design, when handing it over to the development team and their ever-changing circumstances within a dynamic environment. Another issue was how, because the Agile process explores requirements as it builds systems, having a coherent experience as a goal could create major design debt in a moment when a fundamental assumption of the design suddenly got challenged by the result of a sprint or exploration with the client. I will address how these got managed in the next post.
Ask The UXer 