Most software teams work with agile methods, with the base logic of sprints, and then adding in their own flavor to it to cover how they do grooming, whether they assign points to tickets etc.
When a design firm like ours is hired, there is often an attempt to plan the design work to be in sync with the development sprint planning. In my opinion, no attempts should be made to fit design planning into the sprint planning, because they are two different things.
Design is about figuring out the problem and shaping a solution.
Development should be about execution and making things work. If you are solving the problem in development, something is wrong.
Now, because of the typical team composition and imbalance of teams (too little designers, we would say), design happens anyway. It’s just not always done by designers.
It’s sometimes done by a front-end developer. It’s done by a quick mockup in Powerpoint. It’s done by a description in Jira ticket. It’s done in a myriad ways. And that’s totally fine.
To restrict decision-making to “designers only” would be a gross overstatement of our capacity as designers. It would also simply not work, because if I take our clients as a measure we can count 1 designer for every 12 developers. So if decision making would be restricted to design, you are creating a huge bottleneck there.
Instead, decision making happens as a group. And each person has their own specialty. The developer knows the complexity of the codebase. They know the kind of queries they’d have to write to do the data wrangling work. The UI designer knows how the current problem fits into the existing design system, and how much extra work something would incur. The customer support person knows what the customers were recently asking about. The product manager knows a little bit of everything and tries to make the right decision based on that.
Quite often decisions are made without involving the user at all. That’s a problem in itself and probably a blogpost in itself. But what I want to say in this one that you shouldn’t treat design work as part of a sprint planning. It is a separate process.
Deliverables from the design work could be used during the development work. Design can play a role in development work by giving feedback and handling a bit of QA. Development can play a role in design by making something that’s truly interactive – a prototype that can be tested.
But if we see design as problem solving, and take a step back from the day to day work, it’s clear that the design process has an entirely different timeline than the development process. To try and align these is a house of cards that will fall down pretty quickly. I’ve seen attempts and it has never worked. So don’t.
19 Oct 2019 at 09:19
Your email address will not be published. Required fields are marked *