5 key product design terms for non-designers
Collaboration
Amanda Pell
Oct 2022
You know how frustrating it is to spend hours on the phone with an older relative, explaining how to use the TV remote or fix the WiFi router? That’s what I assume it was like for designers and developers to talk to me when I started out as a project manager. I struggled to put my ideas into the correct terms, and I had to ask nearly everyone to pause and clarify anything they said to me because there was always at least one word or phrase in there that I wasn’t familiar with.
Working with someone who doesn’t speak the same language is frustrating on both sides. Those with the necessary knowledge feel slowed down, and those without it feel like a burden (even when they’re not). It’s in everyone’s best interest to pause at the beginning of any project and ensure the whole team is on the same page.
Now that I’ve worked with design and dev teams for a few years, I’m thankfully (mostly) fluent in product development speak and can pass my knowledge on. Brush up on these terms to save yourself a few of the headaches I had along the way.
1. Design sprints
A design sprint is a five-day event in which teams complete an entire project, bringing it from conception to working prototype over the course of a week. In this context, “design” refers to design thinking rather than literal product design, so a design sprint can be used to prototype anything user-focused, from a new check-out experience on an ecommerce website to the ability to transfer funds on a mobile banking app.
Google Ventures designer Jake Knapp developed the concept of a design sprint to reduce waste and frustration. The design sprint keeps things moving by enforcing time and resource constraints and forces the team to find creative ways around roadblocks instead of getting “stuck.”
Stages of a design sprint
In a five-day design sprint, each day is dedicated to one of five stages:
Understand: The sprint team receives the sprint challenge, discusses potential solutions, and maps out the challenge’s critical issues.
Sketch: The team gathers inspiration from competing organizations and other industries, then breaks out to work individually on sketching design ideas.
Decide: Individuals present their sketched ideas to the group, and the team begins putting together storyboards and wireframes for their prototype.
Prototype: Designers build the prototype created during the Decide phase, working with the sprint team to implement any modifications necessary before testing.
Test: The team brings in a representative group of target users to test the prototype and records their feedback.
At the end of the design sprint, you’ll have a working prototype and valuable user feedback to guide your next steps in turning your prototype into a final product.
2. Handoff
Design handoff is the transition phase that takes place after design creation and before development when designers finalize and package their designs and send them over to the engineering team for implementation.
If you’re unfamiliar with design handoff, you might think it’s straightforward: The designer finishes work on their designs, adds all of the specs and accompanying documentation, packages it up in a neat little bundle, and sends it to the developer. The developer receives the product designs, specs, and style guides, has no questions, and gets to work on the product build. Boom, done, the product is shipped.
In reality, handoff is a much more complex and collaborative process that involves frequent clarification and alignment and is rarely that simple. By definition, handoff is almost always going to be messy. However, there are a few things that designers and developers can do to overcome handoff challenges between design and development, including adopting a Design Delivery approach.
3. Design Delivery
Design Delivery is Zeplin’s take on the handoff process, designed to eliminate confusion, increase collaboration, and prevent handoff from becoming a bottleneck that holds up the product development process.
Here are the key differences between design handoff and Design Delivery:
Design Delivery takes place in a shared digital space that’s accessible to the entire product team, allowing designers and developers to collaborate with each other and others on the project, like researchers, managers, and writers.
The collaborative Design Delivery environment is entirely separate from the design canvas. There is a clear distinction between the designer’s ongoing work and “locked” designs that are ready for development.
The design screens, components, and style guides stored in the Design Delivery department are named and organized in a way that can be easily understood by everyone working on the project (including non-designers).
The Design Delivery environment also contains the shared, agreed-upon design system for the product, ensuring that everyone involved uses the same standardized set of reusable components and styles.
If design handoff is an activity, Design Delivery is the house where handoff takes place. You can do handoff outdoors, but it’s going to be a lot messier — you’ll have to deal with bugs, weather, and weird people who wander over to talk to you in the middle of what you’re doing.
Design Delivery, on the other hand, creates a spacious home in which to set up your handoff headquarters. It’s a reliable, permanent structure. You have control over the house’s layout, so you can ensure it’s welcoming not just to designers and developers but to everyone on the product team. And since you’re not breaking down your HQ between projects, you can streamline the process, create reusable snippets of code, and ship more products more quickly without sacrificing quality or organization.
Design Delivery is a reimagined way of doing design handoff. It’s a resource infrastructure that, once built, will make all of your future handoffs easier, quicker, and more effective.
4. Design system
A design system is a comprehensive resource containing all of the UI components and style guidelines used throughout a project. It acts as a single source of truth for everyone on the team, ensuring that the product design and user experience remain consistent across the board, no matter who is working on them.
Anything that should remain consistent across a project belongs in the design system. Design systems typically include:
Product components
Component frameworks
Color palettes
Typefaces and font styles
Icons
Logos and trademarks
Voice and tone guidelines
Front-end style guides
Patterns and layouts
With Zeplin, the developers’ code base integrates into the design system — meaning that each of those design components has a corresponding code snippet defining its functionality. For instance, the design system defines what components the team is referring to — when designers ask developers to “add a rounded button,” developers aren’t stuck looking at four different components that could be what the designer is referring to. Instead, the design system lets designers pinpoint that component, allowing the designer and developer to work within a shared language.
5. DesignOps
DesignOps, or design operations, describes the management of a design team’s tools, resources, and processes. Depending on the size and structure of a design team, companies will either have a dedicated DesignOps manager or team, or DesignOps priorities will be considered part of the design lead’s roles and responsibilities.
A DesignOps manager’s main priority is to take everything that isn’t an actual design task off of their designers’ plates so that designers can focus all of their energy on doing what they do best. In practice, that means DesignOps typically includes things like:
Forecasting work and managing resourcing
Driving day-to-day project flows
Identifying new tools and proposing a tech stack that supports the product development lifecycle Creating and improving design workflows
Building paths for smooth collaboration between designers and other teams
Troubleshooting obstacles and bottlenecks
Finding ways to increase the quality and volume of design outputs
Why is DesignOps necessary?
At first glance, DesignOps might not seem like anything new. It’s a given that design team managers also handle their own team’s tools and processes, right?
The difference between DesignOps and regular design team management is that DesignOps requires continuous evaluations and improvements to design processes, workflows, and tools. Product design is becoming increasingly complex, challenging, and impactful, and companies are investing in DesignOps to maximize design’s value and impact. It represents an understanding that there needs to be a point person (or people) taking a proactive approach to constantly improving the quality and efficiency of the design team’s outputs.
These five terms are far from everything non-designers need to understand while working with product teams, but they’re a start! With these definitions under your belt, you’re well on your way to communicating and collaborating better with your team.
Fin
