Pillar 2: Drive design integration
Pillar 2: Drive design integration
Increase design’s reach throughout an organization. Develop processes that force closer collaboration with product and engineering.
Often in companies design is set up outside of the working product org. A product manager will request a designer to design a specific thing, with requirements, and then reviews it, takes the completed design back to the agile squad. End of the designer’s contribution. And often the ask from the PM is solution-oriented and specific, rather than a discussion about the problem and consideration for how to solve that problem. This is a terrible way to involve design and leads to a lesser result all around.
I believe strongly in getting design as close to the squads doing the work as possible. They should be a part of the team if possible, dedicated certainly. In most organizations there aren’t enough designers to be assigned to a single squad (more designers are always needed!). But as much as possible, designers should align to specific squads, ideally those squads focused on a related/similar part of the user journey. This allows the designer to go deeper on a portion of the experience, think more on the same set of problems and thus generate a holistic view of the solution.
When designers work with the same squads, they get to know the people better and build relationships and shared vision. The first thing I coach to my UX team members is to develop a relationship with the PM. Get to know the things they’re thinking about — what are the problems they think about, what are the opportunities they’d like to explore if they had more time. Work with them to flesh these things out. This allows the designer to confidently focus on the things that matter. And to be sure, they should also building relationships with engineers and the rest of the team.
Designers should attend regular team ceremonies — standups, grooming sessions, retros. When they are viewed as part of the team, they are more closely involved and that builds cohesion. Collectively the team starts to think through problems and they leverage the combined perspectives and skills of each individual. Designer thinks through problems with the input of an engineering mind. Engineers better understand the thinking behind a particular design and work to maintain the spirit of that intention. The team ultimately pursues more thought-out solutions.
One small example of this that has always meant a lot to me: a few years ago a team was working on an ambitious project to redesign/replatform the entire site. One of my designers came to me one day, dejected. He informed me that the product pages we had planned to launch that day was going to be delayed. Apparently the engineer had noticed in QA that there were some CSS-related bugs in the display of the pages. Odd line breaks and font changes. Spacing was off. He brought this to the attention of the designer and the two worked throughout the day to solve the bugs. They got a lot of these fixed, but they needed another day or two to fix everything.
What this meant: a developer had a deadline, and pages that worked, but they didn’t look as good as they could look, and so developer and designer worked together. This is about raising the level of execution, the level of what “good” means. This was possible because the two worked closely together normally. That type of relationship is what you want to foster.
I believe there is an effective way to integrate design workstreams into agile frameworks. My teams have practiced what I call “UX Kanban” wherein the design work is tackled in kanban fashion — which is to say, the top priority is worked on, and then the next priority is taken up when the first task is completed. This regardless of whether the agile squad is operating in sprints or kanban themselves.
The design work is tracked in JIRA, or however the squad tracks stories. It’s important to use the same board and methodology here. It offers one simple place to see all work — backlogs, in progress and status, and completed work. If an entire squad has a single source of truth for work, why introduce a different source for just design work?
I find UX Kanban offers three main advantages:
Transparency: Squads and PMs can see the status of everything. What’s being worked on, what the blockers are, and how things are tracking. This is critical to every agile squad.
More UX “autonomy” to tackle work: Designers know what the biggest priorities are and the order they need to be worked on. When this is not in place, I’ve often seen PMs either struggle to come up with the next task or they fill the time up with less-meaningful tasks. This keeps the right work moving.
Reduced time between design and development: A benefit related to transparency. Also when the work is reviewed and discussed in progress as happens with JIRA, there’s greater shared understanding. This reduces hand-off time.
It’s important that design work does not get trapped in a black box. PMs and engineers and whomever should be able to see the work in real time, as requested. Status should always be communicated. Now with that it’s important for non-designers to be comfortable with seeing work that is in progress and not finished. Equally, designers need to be comfortable sharing work that’s still in progress.
It’s also important that the design work is conducted outside of the sprint, which is to say, not bound by a two week cadence (or whatever sprint length the team adopts). Design work doesn’t break down into discreet steps the way engineering work typically does. When you try to write out tasks for each step of a design process, things get messy and unwieldy quickly.
The designers will still have “in sprint” work, and this is crucial. Once engineers pick up the work completed by the designer, the designer should be available, supporting in any way they can. On call to provide context and explanation, to provide ad hoc QA, to make any necessary changes to the components. This work doesn’t get tracked in JIRA, but should absolutely be viewed as necessary work by designers.
One last point: I instruct my designers to write their JIRA tickets. They should be responsible. It helps them think more akin to the way the entire squad is thinking. It also gives them more ownership of the work itself. I’m not as concerned about the stories being written in the same format as engineering stories. They should still provide any critical context and be generally informative.
Getting design properly calibrated and working hand-in-glove with product and engineering is hard work and requires trust and accommodation by all of those involved. But once integrated, the team will really start making a huge impact on the work to be done.