Reducing silos between development and design teams

🥳 What’s new: June 1, 2023 

We’ve updated this blog to include some exciting new features in Zenhub that could help break down siloes even more: 

• Zenhub Issues allows non-technical teams (like Product & Design) to contribute Issues to the Zenhub board without needing a GitHub account. Zenhub Issues can also now be converted to GitHub Issues.
• Team members without GitHub accounts can now view GitHub issues on their boards.
• You can now embed Figma and Miro files into Zenhub

—————————————————————————————————————————————————————

Development and design – two practices that are so different yet complementary to and dependent on one another. When they operate in siloes, miscommunication, and wasted work can ensue. But, when collaborating effectively, magic happens. 

We know breaking down silos between devs and designers is challenging. From expectation setting to documenting project requirements, there’s a lot of room for things to go wrong. At Zenhub, we aim to foster processes that allow design and development to work closely. We’ve seen great success in how our own teams work together by leveraging a variety of check-ins, meetings, requirement-gathering processes, and other techniques (yes, even our product in some cases!).

In this blog, we’ll walk you through tried and true ways our team breaks down silos between development and design throughout different stages of a project. The coolest part? You’ll learn from the perspectives of two of our very own team members – Brian Leung, Product Design Lead, and Andrew Nickerson, Engineering Manager. These two work together on a regular basis, so everything you’re about to read is straight from their real-life experience making Zenhub!

Create alignment with the “3-box” method

At Zenhub, the first step to breaking down silos between development and design is to create alignment as early as possible. One notable collaboration method we use is a ‘3-In-the-Box’ (3IAB) meeting. 

What is a 3-in-a-box meeting? 

We’ll run a 3IAB meeting at the start of every project. A 3-in-a-box meeting is a collaborative decision-making process where three key individuals representing the technical (development), user (design), and business (product manager) perspectives come together to find alignment on an upcoming project. 

The first meeting is used to discuss goals and the project’s complexity from different perspectives. Discussing feasibility and complexity early on helps us set realistic expectations. Following the initial meetings, we’ll have check-ins about once a week to prevent silos and improve visibility across the product development process. As these conversations continue, the scope of the project starts to take shape.

Design POV: 3IAB

Using 3IAB meetings, our design team can start identifying complexity before any design has been started so that devs can have an unbiased opinion on feasibility. Our design team may sometimes facilitate workshops during the starting phases of a project, this may include things like design sprints or affinity mapping to gain customer empathy and build a collaborative process across functions. 

For designers, 3IAB meetings are a chance to showcase artifacts from different design phases (user research or usability results), allowing us to drive the conversation from a user perspective. The ultimate goal is to ensure the team feels confident moving forward.

Developer POV: 3IAB

At the product definition stage, Zenhub’s dev team is looking to identify any potential technical challenges so that we can break down work into actionable steps. Any functionality that’s not already in the product and has some complexity needs to be identified as needing a spike, so we can work through the details before we commit to any work. As a team, we focus on shipping as early as possible. While we define our product, our developers will offer alternatives to address both the business and user needs. 

Technical breakdowns help with scoping and story pointing

As the project comes together, design and development work together to identify implementation challenges and to collaborate on feasible solutions that satisfy the use case. The technical breakdown allows us to prioritize the core experience first. The project spec outlines these core experience features and breaks them down into user stories and design specs. Once the dev and design team have enough definition on the spec document, we break them up into issues. 

When creating issues, the development team will use GitHub Issues, and the design team will use Zenhub Issues, to enable the design team to work without GitHub access while maintaining alignment. Now that Zenhub integrates with Figma and Miro, the design team will also embed their documents within the issues as they work on them. 

Designer POV: technical breakdowns

When building out the spec document, we’ll create an epic to break the project into issues. Designers use the squad’s Workspace, as well as the Product and Design Workspace, to keep track of work being completed per squad and per function. We’ve configured workflows in Zenhub so that as issues move across pipelines, there’s visibility for both the product team and the squad team on issue progress. 

For designers that don’t have a GitHub account, they’re still able to create Zenhub Issues, they’ll just convert them to GitHub Issues if required. They’ll still be able to see any GitHub Issues on the board, they just won’t be able to edit them.

Developer POV: technical breakdowns

Developers will take the epic put together by design and translate that into individual units of work, which can be split up across team members. In the spirit of shipping fast, we usually create multiple sub-epics representing the phases of release, with the MVP being the first. As we’re interrogating the requirements, we slot issues into the MVP epic and a later phase two.

The goal is to keep the dev team laser-focused on the work at hand without forgetting all the nice-to-haves we think of along the way.

Agile events for alignment

Once the project spec is in place, we use agile events to understand what’s achievable in our bi-weekly sprints. Developers, project managers, and designers all attend the backlog refinement, sprint planning, and daily standup meetings. The goal is to discuss the finer details and build a reliable estimate of stories. We find detailed questions around designs, edge cases, or missing spec details tend to surface.

After everyone understands the spec, developers will use planning poker to collaboratively estimate each story. This lets the developers have additional discussions on execution and will ultimately provide a reliable estimate and accurate sprint prediction.

Designer POV: agile events

Having design attend the backlog refinement meetings has helped fill gaps of information that may be missing from the project spec. Specs could be updated or reduced while the refinement process is happening to ensure a timely sprint. As we move into sprint planning, designers get a good idea of what customer-facing improvements we’ll be shipping and what’s necessary. 

Developer POV: agile events

We’ve been experimenting with moving most of the requirements discussion into the issues comments section before grooming meetings for more focused backlog refinement sessions. We’ve been finding that it helps us have better conversations when the team has more time to think about the requirements instead of trying to decide in a meeting. Planning poker also helps us cut down on time by weeding out the issues that don’t require much discussion so we can focus on more complicated one

Project automations for better alignment

Our workflow, once the project scope is agreed upon, is pretty standard Scrum but with some handy automations to cut out the boring stuff. Sprints are organized and built via the Zenhub sprint feature, which automatically creates the next sprint and moves over any uncompleted issues into the next sprint. We’ve also set up PR automations so our issues are “closed” as soon as the work is merged. 

Designer POV: automations

Through workflow automations, our design team is able to move items from design to development boards without having to hand off work manually. When there are designs or assets that are being worked on in parallel with development, developers can easily tag a designer or mark an issue as blocked. 

Dev POV: automations

In the Zenhub repos, we rely on PR templates to help us automate some tasks and keep the developers in sync with the “definition of done.” Our template prompts the developer to use a “Closes” keyword so that Zenhub will automatically associate the PRs with their issue. We also identify what kind of review we expect, if the change is user-facing, does it require any special testing, etc.

Conclusion

There’s no one answer that will help you completely remove silos from your teams. However, through consistency, open communication, and some of the techniques we’ve shared above, we believe you can unlock new levels of productivity for your design and development teams. Not only that, they’ll be much happier working together – and that, to us, is the true win!

Want to learn more about creating high-performing technical teams? Check out our free guide Focused Teams: A Field Guide to Focus-Driven Development.