What are common practices for syncing Engineering with Design?

Question

At my last job, I led a team that was building an iOS app from scratch.

We (the engineers) worked closely with a Design team. The two teams struggled to sync their work.

Design would produce UI mocks and share them with Engineering, and Engineering would come up with delivery dates for the components in the mocks. Then, Design would change the mocks again, and Engineering's previous commitments would no longer mean anything. This caused pain and confusion for both Product and Engineering.

Eventually, we agreed on a system where Design would publish sequential "versions" of the same component, and Engineering would commit to building a specific version for the upcoming release, regardless of what Design might do in the meantime.

Getting this implemented required a lot of advocacy by a single, determined engineer. The rest of Product, Engineering, and Design agreed that the problem was painful, but didn't make an active effort to solve it.

Is this kind of thing common at other companies? How do designers and engineers normally share and sync their work?

Are there standard tools and processes involved, other than posting links to Figma files on team Slack channels?

Answer 1

This is quite common, unfortunately.

It's helpful to know this type of Eng/Design issue seems common at other companies to.

I don't see how this is helpful. This is simply a failure of people to agree on how they should work together.

A lot of times people think about features they want, about what technologies they will use to build the application, when they want to release a version to users, what methodology they will use, etc, but fail to also agree on how the different roles need to make the whole effort happen on a daily basis, and how output from one role might impact the input and outputs of another role.

I'm deliberately using "input" and "output" words here to make a point. The output of the design is the input of the development. While you develop something, in order for the development output to match expectations, the design needs to remain frozen. But if it changes while you develop it, then what do you do? You either stop and build the new version of the design, or you keep on going with the initial design then figure out later what to do with the new design. Both approaches cause waste because you walked some time in one direction and then you have to walk away in another.

This is fine if you are doing some sort of an exploration to define the product and get user feedback, but it's not fine if the expectation is that "we build what was designed". Because if the design then changes, you have a problem that doesn't match the expectation.

When this happens people usually tend to impose that the design be frozen so that waste is not created while building it. Any changes to the design get ignored while you develop. But if the design changed for good reason, then you are still wasting time building the wrong thing.

Agile practices actually account for situations like this with a mindset switch of thinking about "outcomes" more that "outputs", and outcomes for the whole team, not outputs from individual roles within the team. What are we trying to achieve here? And how will we go about making that happen? How do we get feedback sooner rather than later and what do we with that feedback?

The emphasis is more on collaboration between different roles than on roles passing their outputs as inputs to someone else. There is a switch then from "this is not working for us as developers so you designers have to freeze your work to help us, and too bad for you" to "this is not working for us as developers so how can we work together so that it works for both of us".

This means that you need to sit together and talk about the outcomes and how best to achieve them. You are setting up working agreements and proper expectations. All of you.

What usually happens when you don't have this kind of collaborative setup is that some expectations are set, some ineficient way of working is selected or tends to settle in from how people were used to work, results end up suffering, and then pressure points start to appear, and people try to raise protection walls around their work, which makes things even worse. Basically everyone accepts a deficient way of working but they refuse to accept the consequences of that and just insist on the initial expectations, being upset that they are not met (which often also starts the finger pointing for blame).

So how do you fix it?

You are all adults, so sit together and discuss the matter and agree on ways to improve it. That's what retrospectives are for, for example. If your company thinks about itself as being Agile, then inspect and adapt should be the acceptable way of working. And also to try something out, figure out if it's working, then continue or try something else if it's not.

The current way you are working might be fine, or might not be depending on the root case. Why are designs constantly evolving? Was it because people don't know what they want an don't make an effort to express it? Was it because of some rapid feedback received from users? Or is someone not available for approvals or input and the feedback loop is large and you are already in progress with development when the decision comes? Maybe you don't pay enough attention to exploring the new features of the application before building a design? What's going on?

Discuss it together and find out what the issues are. Then decide how you might fix it. Do that. Then after a while, get back together and see if it's working. If it's not, try something else. Either way you are doing this, but it's best to be a collaborative upfront effort, instead of people with different roles trying to find ways to restrict what others are doing when they discover an issue.

Answer 2

Are there standard tools and processes involved,

There sure are. Depends a bit on the size of your organization and the scale of your projects. Good practices are

1. Have a PRD (product requirements document) that describes "one version of the truth" with all features that "must have" to ship. That's what we are building.
2. The document has a "life cycle". Early version can be a rough draft with lots of unknows, but things get more tied down as you learn and the engineering effort type of work is commensurate.
3. One way to manage the lifecycle is a "phase gate" process. The project is split into different phases: something like "exploration", "prototyping", "development", "testing", "deployment". The PRD and resource estimates have to pass a certain criteria before you can go to the next phase
4. Have design and engineering scope the effort interactively. Design wants a unicorn. Engineering can offer a donkey with a pointy birthday hat or a pretty white pony. Discuss and negotiate. The idea here is to find the sweet spot between features and development cost/complexity.
5. Have a robust change control process. PRD can change, but the review and sign off that's required to accept that change is a function of the life cycle stage. In "exploration" things are expected to change frequently, adding a new feature while you are in testing is extremely risky and should require sign off from the CEO.
6. Branch. If new features are coming up, but it's already late in the game, just push them into the branch for the next version/release.
7. Rapid prototyping is your friend. There are good prototyping tools available that design can use themselves. They shouldn't need engineering to figure out which workflow and/or screens work better. Engineering can still support, but lots of rapid prototyping with robust user testing can add confidence to a PRD at relatively low cost.