A Designer’s Guide to Integrating with Engineers
One of the first things I struggled with as a product designer was learning how to ship quality products with an engineering team. In an academic setting, it’s easy to put together some design specs and say, “This is my answer!” without considering feasibility. I hit these problems pretty early on once I started working with Agile teams. I would hand off specs to the engineer only to learn that I’d missed tons of edge cases. During development, designs were rarely produced to spec or I would forget to include an asset. I would spend valuable design time creating detailed specs just to make sure the engineer wouldn’t miss anything. Worst of all, designs were sometimes never built because they weren’t feasible in the given timeline.
Over the years of working closely with engineering teams, I’ve picked up a handful of tips to share. I hope designers and engineers can start to blur the lines of responsibility so we can focus on the common goal of building the best, most valuable thing you can build. It all comes down to this: maintain a shared understanding of your work, challenges, and goals.
Kick off together
The most impactful way to maintain a shared understanding is to set the initial tone and context of a project with a kick off meeting. This is your opportunity to establish expectations, uncertainties, hopes, worries, and dreams.
Establish expectations for the project by talking about what you already know, what hypotheses you need to validate, and what you still need to explore. This helps both engineering and design set up more focused discovery sessions. By talking through the known business problems and design constraints, engineering will have a sense of scope right from the beginning. It will also be helpful to understand which functionalities will be technically difficult. These will need stronger validation in research or deeper design exploration.
One good way to build a mutual understanding of the problem early on is to allocate some time for collaborative sketching. Come into the kick off session with the main business problems and spend 10–20 minutes together sketching ideas for how to solve them. While you shouldn’t expect real solutions to emerge during kickoff, it’s a useful way to collaboratively reveal problems. After the session, tape up your sketches and use them as points of discussion throughout the life of the project.
Concluding a successful kickoff means the team has a mutual understanding of the problem and scope of the project. While this may change as you gain new information, having a shared first step helps set the tone for the rest of your time together.
Share work and learn from each other
Understand that you have a common goal: build a wildly useful product you are proud of releasing into the world. When you have that commonality, the lines separating your job titles start to blur. Treat each other as thought partners — bring engineering into the design process as early and as often as possible.
Once you have a round of sketches, invite your technical counterpart to a 1:1 or design review to talk about the different ideas you’ve explored. Be open to critique and invite more idea generation. As a designer, you should have a strong understanding of the problem you are trying to solve. Share what you know about the user like their name, role, company, desires, fears. I’ve found the best ways to do this are through Google Docs, research videos, or an information deck. As an engineer, you should not feel limited to code to express ideas. Some of the best suggestions have come from a simple ballpoint pen and paper sketch or a cut-and-paste edit of an existing design mock.
While you don’t necessarily need to learn how to code as a designer, always ask yourself, “How can I best explore and communicate my design ideas?” A design mock can only go so far. Use the appropriate tool to not only explore possibilities, but to clearly communicate your vision to engineers. Tools like these help you meet halfway:
- InVision is a great way to show visual concepts and user flows.
- Framer and Principle are popular tools for showing interactions on mobile devices.
- Codepen lets you whip together a quick HTML/CSS/JS prototype for small interaction details like loading spinners or button states.
Challenge each other with good intentions
Unless you’re in academia, every product designer runs into engineering constraints. How you navigate those constraints will determine the final quality of your product. To do this well, understand that constraints are a good thing. They challenge you to prioritize pieces of the design so that it delivers only what’s necessary and nothing more. When engineers ask how important each feature, functionality, or visual element is, it helps you form a stronger opinion about what’s most important to users. If, as a designer, you don’t have a good answer to those questions, you likely need to reframe the problem or review the research.
Likewise, engineers should have strong reasons for why a proposed direction is not feasible. To better understand those reasons as a designer, we don’t need to learn how to code, but we should at least understand the limits of software. Ask questions about why a particular piece of functionality will take X amount of time to build. Challenge engineering estimates and priorities, but do so remembering that you share a common goal. If the business need is clear, this conversation will either help engineers find new ways to build or encourage designers to find a more creative way to achieve the same business outcome.
Set a foundation for good design
In a magically ideal world, front-end developers would simply be able to brush against a design mock and turn it into a functioning product. This is far from reality as the tools designers use today live in a different paradigm from software development tools. Unless a significant amount of time is spent on specs, designers and engineers end up having to go back and forth about exact pixel dimensions, colors, line heights, and assets. Still, there are a few ways to bridge the gap.
Establish visual grids and best practices to avoid over-documenting. As an alternative to specifying every element size and spacing in between, laying down a grid helps quickly convey where elements should land. This avoids the back-and-forth about small visual details.
Build a style guide together. Zurb’s Foundation and Twitter Bootstrap have shown the value in a defined style framework to quickly build usable and beautiful web projects. Inkling is currently working on Common UI, a shared repository housing our design language, best practices, reusable code, and iconography.
Use tools to automate speccing. The days of manually redlining specs are almost over. It has evolved from redlined PDFs to fancy Fireworks plugins and now to tools shared by both designers and engineers. Both InVision and Zeplin.io pull from your source assets and allow engineers to see sizes and colors of individual layers. Xscope has also been a favorite for both designers and engineers. In addition to sizing, it offers spacing between elements and a neat color blindness preview.
Go for polish
The last 10% of a project typically feels like 90% of the work. While it’s easy after you’ve delivered specs to let up and cross your fingers in hopes that every pixel is built to spec, it’s important to stay committed to the final touches by having regular check-ins with your engineers.
Hold regular reviews at the end to polish implementation of the UI. This is where it’s important to taste what you make before you add more salt. Typically, before our push to stable, our team uses a simple spreadsheet to log UI issues that are inconsistent with the specs or require more design input. These issues are then triaged and entered into JIRA.
Hold company-wide testing parties to uncover bugs and design flaws. At Inkling, before a feature ships to stable, we invite internal team members from Sales, Research, Engineering, and Design to help catch bugs and usability issues. We then add these issues to the spreadsheet and continue triaging for following sprints.
Get to know each other as human beings
Without getting too warm and fuzzy, it’s important to know each other as people. Go out for coffee, have lunch together, have a drink, or throw balls at each other to gain a little more perspective outside of your work. This helps you “challenge each other with good intentions” by reminding you that you are working with a human being with valid thoughts and passions. It reminds you that you’re on the same team.
At Inkling, shipping well-crafted products depends on close working relationships between designers and engineers. We know how important it is to establish a shared understanding of everything you do from beginning to end. Our process isn’t perfect, but we’re also working on that together.
