How Are Product Designers Organized at SendGrid?
February 20, 2019 • 11 min read
February 20, 2019 • 11 min read
One of the most common questions I receive while interviewing potential UI/UX team members is about how UI/UX is structured at SendGrid and, specifically, how product designers are organized relative to product managers and other roles.
Product designers have two families that they must form strong and durable relationships with in order to be successful: 1) their cross-functional product delivery team (“scrum team”) and 2) their design team.
The product delivery team, often known as a Scrum team, is a cross-functional team consisting of a Product Manager (PM), Product Designer (PD), Engineering Manager (EM), software engineers, quality engineers, and a ScrumMaster. In order to consistently deliver value to our customers, this team must have shared customer and product understanding, alignment in priorities, standards, and responsibilities, and a sense of trust and comradery.
At SendGrid, we “embed” our product designers into product delivery teams in a dotted line relationship. Our goal is to keep our ratio of product designers to customer experience building delivery teams at 1:1 so that they have the bandwidth to 1) uphold their research and design job responsibilities with pride, and 2) participate as a true member of the delivery team. For example, we expect product designers to attend the team’s agile ceremonies and to plan their work in 2-week sprints. This encourages transparency and trust in how each team member is contributing to the team’s shared goals.
One of the most critical product designer relationship is with the product manager. We expect product managers and product designers to function as a true partnership, working hand-in-hand throughout the product development lifecycle, including customer research, problem understanding, and solution design, iteration, and testing. Think Han Solo and Chewbacca, Mario and Luigi, or Barack and Michelle Obama.
We expect product managers and product designers to function as a true partnership; think Han Solo and Chewbacca, Mario and Luigi, or Barack and Michelle Obama.
A true partnership means that both the product manager and the product designer discover customer knowledge together, share it freely and openly, and use it throughout the product development lifecycle to validate each of their hypotheses. This is particularly beneficial when those hypotheses are at odds with one another. Customer data - acquired through direct interviews, observation, and quantitative measures - can and should be the defacto answer to nearly all disagreements that arise within the product development process.
Joining forces in a partnership also creates shared ownership and accountability for the product and its adoption. When the product designer plays a more strategic role in the solution and deeply understands the customer, they are intrinsically motivated to make improvements on behalf of the customer, even when it requires reworking their own design. In organizations where the product designer is handed requirements and is disconnected from first-person customer data, it’s far too tempting to pass blame and responsibility along to the product manager.
To accelerate the formation of this partnership, we facilitate working agreement meetings. We discuss the overlap and differences in the respective roles and ask the pair to proactively state how they want to work together and how they will deal with common situations that could arise during the course of a project. Product leadership also makes it an explicit expectation for all new product managers and designers that we must validate our problem and solution hypotheses directly with customers before we begin building a production-quality experience.
Similarly, the relationship between product designers and front-end engineers is critical. Just as designers are marginalized in organizations where they are handed product requirements to design without customer context, the value of front-end engineers can be equally marginalized when they are handed design specifications. This robs them of an opportunity to provide input on feasibility, performance, and component consistency.
Just as designers are marginalized in organizations where they are handed product requirements to design without customer context, the value of front-end engineers can be equally marginalized when they are handed design specifications.
Having the product designer as an accessible and trusted teammate encourages collaboration early in the lifecycle of a solution concept. That same relationship pays dividends again during implementation when the developer is able to easily ask questions about unexpected edge cases or complexities and address them within the sprint.
To help foster this relationship, we ask product designers to invite engineers to participate in design studios to kick off the solution concept stage of a given project. When engineers express interest, we also happily invite them to attend our customer research calls. This provides them with an opportunity to gain first-hand knowledge of the customer’s problem and the customer’s reaction to the proposed solution.
Later, once the design is starting to solidify based on customer feedback, we have product designers spend time deconstructing their designs with front-end engineers, cataloging existing component patterns from net new patterns, discussing options for implementation, and identifying open questions.
At SendGrid, we made the decision to have product designers report directly (solid line in the org chart) into a UI/UX department. UI/UX at SendGrid is part of the Product department and a sibling to the Product Management department. Myself, and our VP of Product, both report into our Chief Product Officer.
Although there are many advantages of having product designers embedded on product delivery teams, one downside of this arrangement is that they are often the only voice for research, design, and experience. At best, that can feel lonely. At worst, it can marginalize their impact and hurt their engagement, particularly when they feel outnumbered in decisions or perceive a lack of understanding for their role and responsibilities. By complementing the delivery team embedded model with a direct line reporting relationship into a UX manager, we are able to counterbalance the isolation with a strong craft-based UI/UX support system and leadership.
Being at a company where you can work side-by-side with others in the same role is an incredible force for career growth particularly when you’re early in your career. As a member of a team of product designers, you have incredible exposure to each individual’s unique talents: their approach to design, the variations and results of their designs, and their style for collaboration. This body of knowledge across a team is so vast that it provides each individual with a rich environment for rapid learning. We encourage visibility and sharing of our team members through InVision, a shared research calendar, a Slack channel, and a dedicated “buddy” for each designer on the team.
Unlike most other disciplines, design teams have a long history of practicing critique. A constructive critique culture is an invaluable resource for a designer to identify important issues and open questions in their design. This team practice can help supply an important holistic product or customer context or provide a healthy dose of input to designers who have developed blind spots with their design. We offer design critique sessions twice a week and encourage peer-to-peer ad-hoc “take a look over my shoulder and let me know what you think” critiques via a dedicated critique slack channel.
We encourage visibility and sharing of our team members through InVision, a shared research calendar, a Slack channel, and a dedicated “buddy”.
Your manager is typically the strongest influence on your engagement and development. It is amazing when you have a manager who deeply understands the craft and will advocate for you to have time to conduct customer research, voice your opinion on prioritization and quality, and give you access to the best possible tools and techniques.
At SendGrid, we have developed a detailed career development framework for all of our UI/UX job families. It is still so common for designers, particularly when they are not within a UI/UX team, to lack clarity about what’s required for next-level career growth. We use our framework to make those expectations clearer and we encourage both manager and peer 360 feedback to help designers understand their strengths and development areas. Great user experience is holistic; that’s hard to do without a team thinking holistically.
The Nielsen Norman group defines “user experience” as “encompasses all aspects of the end user’s interaction with the company, its services, and its products.” Users don’t know or care what department or designer created what part of that experience - they will make decisions to use your product based on the entirety of their experience. Therefore, it’s our responsibility to design for the entirety of the journey in a way that’s intuitive and cohesive.
Users don’t know or care what department or designer created what part of that experience - they will make decisions to use your product based on the entirety of their experience.
When designers don’t have a “home” department but rather report into different teams or departments, that cohesive experience becomes incredibly difficult to maintain over time as the product footprint expands. You may see it as brand inconsistency (colors, logos, style, tone, copy), interaction pattern proliferation, quality level differences (performance, errors), or wide and noticeable shifts in experiences from section to section.
We try to encourage holistic thinking through our shared Sketch library, style guide, React-based UI components, and centralized research database. Each quarter, team members are able to identify a quarterly goal that they want to work on that will help contribute to the UI/UX team or process. Many of our shared tools and processes originated from these quarterly goals.
How do you measure the success of a given organizational structure and set of processes? You can consider how it impacts the people and how it impacts the work product - the experience that is ultimately delivered to the customer.
SendGrid’s first team of three designers operated as a centralized agency model and reported into a non-design manager. The team was understaffed, underappreciated, and frustrated with the quality of the experiences they were able to deliver. Here are the verbatim challenges that we captured in the team’s first retrospective:
Fast-forward three years and we have high engagement scores, a style guide, clear priorities, time for research, and the relationships with PM and Engineering that allow the team to feel proud of the work that reaches customers.
While we continue to pay down design debt from the early startup years and have our share of new challenges to tackle, the way we’ve organized the team and invested in critical cross-functional relationships has paid off. This is the foundational system, along with smart people and an exciting product vision, that makes product designers want to bring their best each day to the company and our customers.