Improving Communication Between Development and Design – InApps Technology 2022

Ah, development and design – two practices that are so different, yet so complementary to and dependent on one another. When these two practices are siloed from each other, it can quickly become a breeding ground for miscommunication and wasted work. But, when they can collaborate with free-flowing communication, they can become a truly dynamic duo.

We know breaking down silos between development and design can be challenging. From setting expectations to documenting project requirements, there’s a lot of room for things to go wrong. Setting a process that allows design and development to work closely is easy to say, harder to do. We’ve seen great success in the way our teams work together by leveraging a variety of check-ins, meetings, requirement-gathering processes and other techniques.

In this blog post, we’ll walk you through tried-and-true ways our team breaks down silos between development and design throughout different stages of a project. As product designer (Brian) and engineering manager (Andrew), we work together on a regular basis, so everything you’re about to read is straight from our real-life experience making ZenHub.

The Common Goal

Product definition ensures dev and design are working toward a common goal.

The first step to avoiding silos between development and design is to create alignment as early as possible. One notable method we use is a “three in the box” meeting. This involves making sure we have technical (development), user (designers) and business (product managers) perspectives when discussing an upcoming feature or project.

The first meeting is used to discuss goals and understand complexity from different perspectives. Discussing feasibility and complexity as early as possible helps us set realistic expectations.  Following the initial “three in the box” meeting, we’ll have check-ins about once a week to improve visibility across the product development process and realign as necessary.

From a Designer POV

Using “three in the box” meetings, our design team can start identifying complexity as early as possible. Typically this would happen before any design work has been started, so development can leverage an unbiased opinion on feasibility. For designers, “three in the box” 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 with the project.

Our design team sometimes facilitates workshops during the starting phases of a project. This may include things like design sprints or affinity mapping and helps build a collaborative process across functions.

From a Developer POV

At the product-definition stage, our development team identifies 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. During product definition, our developers will offer alternatives to address the business and user needs. For example, at ZenHub, instead of building our own notification system, we might consider leveraging the GitHub platform to help us ship faster and bring improvements to our users more quickly.

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. Once it’s finished, we re-evaluate if any of the out-of-scope issues are worth finishing before our initial release.

The project spec outlines these features and breaks them down into user stories and design specs. Once the dev and design teams believe they have enough definition on the spec document, we break them up into GitHub issues and estimate them. Aligning on the technical breakdown ahead of time creates better approximation for scope and deadlines.

From a Designer POV

When building out a project spec document, we’ll create an epic in ZenHub and document all relevant information there. (Epics are a theme of work in ZenHub that contains several issues, or subtasks). It will then be broken down into individual issues as they become ready to be worked on. Designers use the squad’s task board, as well as the Product and Design task board, to keep track of work being completed per squad and per function. Workflows are configured so that as issues and epics move across pipelines, there’s visibility for both the product team and the squad on what’s in progress.

From a Developer POV

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.

At this stage, there’s a lot of back and forth between the disciplines to decide what’s absolutely necessary to deliver customer value. The ideal outcome of these conversations is the smallest backlog to get us to an initial release. The phased epics give us a logical place to keep track of additional work we discover during the project, which we evaluate after the initial release. 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.

Alignment Between Design and Development

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 working on the project will 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.

From a Designer POV

Having designers attend the backlog refinement meeting has helped remove silos and fill gaps of information that may be missing with 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 assets are necessary.

From a Developer POV

In standard agile fashion, the dev team estimates issues in the minimum viable product (MVP) epic so we can identify any gaps in understanding across team members. After everyone understands the spec, developers will use planning poker to collaboratively estimate on each story. This lets the developers have additional discussions and will provide a more reliable estimate and accurate sprint prediction.

We’ve been experimenting with moving most of our discussion around requirements into the comments section of GitHub issues before grooming meetings so we can have 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 synchronously in a meeting.

Better Information Sharing Between Designers and Developers

Once the project scope is agreed upon and organized into issues, our workflow is pretty standard Scrum, but with some handy automations to cut out the boring stuff. Sprints are organized and built using an ZenHub Sprints tool, which automatically creates the next sprint and moves over any uncompleted issues into the next sprint at the close of the current sprint.

Issues are assigned and pulled into the ‘in progress’ pipeline manually, but once a pull request (PR) is pushed and associated with the issue, it automatically tracks the completion status of the PR so our issue is completed as soon as the work is merged. When we experience scope creep or missed requirements along the way, we’ll generate new tickets and decide as a group if the additional scope belongs in the current epic or in phase two.

From a Designer POV

Clear definition of pipelines allows for visibility across teams to understand what’s being worked on and what needs attention. 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.

From a Developer POV

We rely on PR templates to help us automate some tasks and keep the developers on track to completion. 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 and if it requires any special testing.

Design Review and Code Review in One Place

All our work needs to be code reviewed, QA’d, and approved by the product owner. We use additional pipelines within our workspace to indicate these statuses, so we can visualize the bottlenecks in our workflows and talk about them in our daily standups.

From a Designer POV

Screenshots or videos provide a history of changes and are a quick way for designers to do asynchronous review. Oftentimes, designers, QA or developers can jump onto a call after the release of a PR or if an issue is tagged requiring design review. Having designers directly in GitHub means there is less context switching, and we can leverage built-in reviewing features.

From a Developer POV

We’ve been leveraging the GitHub code commenting interface to provide threaded and resolvable feedback on PRs as they move through our workflow. QA and designers can drop comments into code, and the developers can resolve them one by one, so we can see the progress and have some history of the long-running reviews.

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!

Feature image par Ryan McGuire de Pixabay.