Editor’s note: On January, 18, 2019 the Dropbox Design blog featured a post from Product Designer, Jenny Wen, on working with engineers. This post covers the topic from an engineer’s perspective.
One of my favorite things as an engineer building Paper is how closely I get to work with designers. It’s an important partnership. When we share the same goals, work closely together, and understand what is important to each other we can create things that we would never be able to accomplish on our own. The opposite is also true. When we don't align early, when we work at a distance, or when we don’t consider what they find important we thrash, we lose momentum, and we build a worse product.
Through years of working closely with designers—some of whom helped with this post!—I’ve seen a lot of patterns that work. Here are some principles and practical advice for better understanding and working alongside designers, and how to avoid some of the failure modes I’ve seen along the way.
This stuff matters. We will build better products, faster, if we have a tight iteration loop with design. We can avoid a waterfall-style “product → design → engineering” delivery of requirements and specs. We will identify concerns faster, validate ideas earlier, and have an easier time making course corrections when we run into issues.
Develop an appreciation for good design
Learn what designers value. Ask about mocks, or even early sketches. Learn why the designer proposed what they did. Ask “what details of this design are precious?” Understand the desired user experience. Ask “what things do you really like about this design?”
Ask “how final is this design?” Designers and their tools are great at making things look polished and finished. But sometimes things look set-in-stone before they actually are. So ask! Ask what’s still exploratory. Ask what’s going to change. Ask which bits are finalized and ready to implement.
Learn how to tell when your implementation matches the design. If the designer tells you something doesn’t look or act right, make sure you understand why. Ask questions about their feedback, rather than just implementing it. With practice, you’ll learn to anticipate the feedback they’ll give you, which saves time and effort for both of you.
If something doesn’t seem right, say something. Even if you’re not a designer, you’re a user. And—importantly—you’re closer to the implementation than the designer, so you might have a better idea of how something should work. Use your intuition. You’re allowed to be opinionated about your product!
Understand and appreciate design systems. In my opinion, this is one aspect of design that engineers are often better equipped for than designers. When implementing a design, look for the patterns. Figure out the system. Understand how it fits into the larger picture. Colors are a great example of this. When designers use visual tools to mock something up, it’s not hard to pick the wrong shade of grey or variant of a color in the design.
When you understand the system, you can look at the current design as part of a larger whole and figure out where things don’t quite line up. You can help designs to be consistent.
Sweat the [right] details. Once you understand which elements are important about a particular design, nail those ones. Make ‘em perfect.
Sit with designers; work with designers
This is the fastest way to appreciate their work, and to learn what they care about.
One of my favorite ways to polish an implementation is to get it to 90%, and then finish it off with the designer, at my computer, in real time. Some things won’t translate exactly right from mocks or prototypes to actual usage; if the designer is sitting right there, they can course correct without the overhead of multiple iterations and mockups and reviews.
Switch up the order you build things to account for design iteration. Handle the UX, the data, the flow, the functionality, the general layout first. When iterating on unlaunched features, take shortcuts. It’s okay to make ugly things. Then work on successively more polished and precise implementations of the designs. Ideally, once the UX / data / flows / functionality bits are finished, ship those behind a feature flag, enabled only for yourself and the designer. It’s amazing how much can change once you’ve lived with the feature for a bit.
Help designers think through the details
Ask a ton of questions: How does this design change for different devices or screen sizes? What does it look like on mobile? What happens when this design is internationalized? Do the words fit just perfectly in the original design? Are things flexible enough to support German or Russian translations?
Establish the extremes, as these are often the cases that don’t get attention in mockups. What is the empty state? What if the user has a ridiculous amount of data or activity? What breaks? What copy, or illustrations, or delightful experiences do we need to plan for these extremes?
Help fill in the gaps. If a margin doesn’t quite work, or some colors aren’t exactly the ones in your app palette, or the design isn’t responsive for really large or really small screens, use your best judgement to fill in the gaps. Once you’ve got the thing built, it’ll be a lot easier to see why you needed to make that call, and whether you made the right call. Work the details out when you’re sitting with the designer for the last 10% 🙂.
Bring your own cupcake
“Little big details” are tiny designed experiences that bring more than their fair share of delight. Paper has plenty; some you might have noticed, some are still waiting to surprise you. If someone tweets something they love about Paper, there’s a good chance they’re tweeting about a little big detail.
At Dropbox, we call these experiences “cupcake”; it’s one of our five core values. Literally, it's just a picture of a happy cupcake.
Paper has a lot of these moments. Changing the favicon of your browser tab to an emoji from the doc title. Markdown editing shortcuts. Attribution. Converting “->” into “→” and “<3” into ❤. Many of our empty doc writing prompts. More typography details than you would even imagine—ask me about “hanging punctuation” when you have a minute… or twenty. The “emoji count” feature. /shrug. Doc previews. The keyboard shortcut help panel. The message we show when you try to “save” a Paper doc (Haven’t seen this one? Watch the “updated just now” timestamp at the bottom of the page and press Cmd+S. Wait for it to change back to the timestamp, then hit it again. And again. And again 🙂)
Each of the details in that list came from engineers. Find delightful details to add to whatever you’re making!
Help designers develop an appreciation for engineering
Explain engineering constraints. They’re not always obvious to non-engineers.
Get involved early in the process. Ask to see early concepts and rough sketches. Look over proposed designs for red flags. Help the designers understand fundamental issues with designs before they’ve spent a ton of time polishing them and getting them pixel perfect. The best time to raise concerns about functionality is before the design has gone through reviews and the designer has invested in getting buy-in from other designers.
They won't always be flexible on details. The “easier” approach isn’t always the right answer. Some designs are worth spending the extra effort on.
There’s a healthy tension here. Odds are, for any given project, there are elements the designer thinks of as important, but which should really be scoped down. Ultimately, designers should know which parts we’re spending extra effort on, so they can weigh the importance of those pieces against all the other implementation work.
Do your own design review
In hardware, there’s a concept called “design for manufacturability.” For any given widget, there are lots of ways to build it. A naive approach is to take the industrial designer’s CAD files and build them exactly to spec. But this is rarely the most cost effective, fastest, or best way to build things. Instead, manufacturers will propose a set of changes, with the intent of reducing materials needed, reducing tool time, improving durability, or optimizing for available supply of components. Sometimes changing the rounding of a corner slightly, or switching to a different material, or removing an undercut, or moving some screws around will make a significant difference in the “manufacturability” of a widget.
A similar concept can apply to product design and software engineering. Do an informal “design for manufacturability” pass on designs you’re given: look for the parts that will be hardest to implement, or that you have performance concerns about in production, or will otherwise be suboptimal. Suggest alternatives. Frame things in terms of time to implement, or maintainability, or a better user experience: “If we can remove this small detail, it’ll take two days less time to build” or “If we reuse an existing UI component that’s similar but not exactly like what you’ve designed, it’ll save a week of dev time, and we’ll have fewer bugs because the existing component has been in production use for a while.”
Negotiate the details
Not all designs are set in stone. Kurt Varner, Paper’s design lead, argues that “ no design is set in stone—especially if engineering hasn’t yet seen it.” Often there are a handful of things that are absolutely necessary, and a lot of things that are in the design because they’ll work. Many other things might also do the job, so if some detail will be a lot of work and you wonder if it’s worth the extra complexity, ask!
Do a little horse trading. “I can fit in this one important and difficult thing, but we have to find somewhere to cut effort elsewhere.” Designers are usually willing to make concessions to get the parts they really care about built. Knowing what the designer values in a given design will help you make these calls, and will ensure that both you and the designer are optimizing for the same things.
Involve your product managers. When weighing engineering complexity and considering tradeoffs, be sure to bring your PMs into the conversation. It’s their job to help navigate these compromises, so it’s important for them to deeply understand both the design needs and the engineering risks. They’ll help negotiate and evaluate the options, and will ensure that we’re having the appropriate discussions.
Push back against custom styles. Does a button look a little off compared to the default component style? Ask whether it needs to be different. It’s fine to do one-off customizations sometimes, but it should always be a deliberate choice. If it is an important change, ask whether this change should be applied to all other instances as well.
Propose alternatives whenever you want to say “no.” This is where understanding the intent of design comes in handy. Rather than saying “No, we can’t do that,” say “will this work instead?”
