Collaborative Design: A Guide to Successful Enterprise Product Design

You have probably heard of Agile software development, Kanban process management, and Lean UX. Collaborative design is a different philosophical and tactical approach to enterprise product design.

Collaborative design is the process of designing in a participatory, engaging, and realistic all-hands or brain trust environment. It is NOT designing in a vacuum; instead, as the name implies, collaborative design puts the designer at the center of the various teams and departments to work with everyone in order to build a cohesive product. In this way, no one is left out, and the product can be built with all the stakeholders involved.

Every enterprise organization is different, and corralling stakeholders around any idea or task can seem like herding cats. In this guide, we’ll review tips and tricks to working with the major players, not only to get their input but also to bring them on board with this new design-centric approach.

Meet the Players

Designers are great at a lot of things, but their role begins with solving problems. That requires knowing who the experts are and working with them. Every member of the product development team has their own needs and responsibilities, so getting to know them is as critical as actually completing the given assignment.

So without further ado, let’s meet the team:

• Product managers define the scope, requirements, and development iteration cycles for products and features; they are often the gatekeepers for features in advance of a final yes/no and are practiced at communicating with the entire organization, including executives.
• Engineers build the product, so they understand technical capabilities and limitations. This makes them a critical resource for determining major concerns including development timelines, technologies to use, scope, and often design feasibility (if our concepts are even possible given the technology and time limitations).
• Database and system architects know how data is integrated and have a deep understanding of what is required to maintain performance while continuing to build on top of the existing product/platform.
• Internal subject matter experts (SMEs) are intimately familiar with the business processes, use cases, history, and politics, as well as general expectations from management, clients, and users.
• Sales focuses on presenting the product to prospective customers. This makes sales the first point of contact, so their understanding of the product is critical for closing (and often creating) leads.
• Trainers (or in SaaS, customer success agents) have direct exposure to the sales team and new or trial users, and they can contribute volumes of useful information about how the product is performing in vitro and beyond.

When all parties working on the product are involved in the design process (one of the fundamental principles of Agile methodology), the resulting product has a significantly greater chance of achieving success—not because designers are working with stakeholders, but because stakeholders, more often than not, understand specific user and business needs in a way we may not. Working collaboratively always seems like the best option, but how do we do it?

How to Collaborate with Stakeholders

Product Managers, the Product’s Gate- and Time-keepers

Product managers often have a personal attachment to the product and are held to very high expectations within the company. They also have to answer to the users or customers of their product(s) when there are problems, unmet promises, or requests for a new functionality.

They value simple communication highly and need to be kept up-to-date on progress, issues, and any changes. They like to see drafts first and frequently, and because they can work at various scales (several levels away from direct product development to hands-on with even minor changes), your interactions with them can vary greatly.

Because PMs spend so much time communicating with various stakeholders (internally and externally), it’s important to keep them apprised without expecting them to check in with you. Set regular check-ins with your PMs to present iterative drafts, listen to their feedback, and always end with a list of action items for the next meeting.

It won’t take long to learn what their goals are for product functionality. PMs know that designers are problem solvers, so designers need to deliver data and analysis to prove their reasoning. Whether you’re right or not doesn’t matter. Prove that building the best product is the goal and you will earn a PM’s trust!

Engineering: Responsible for Bringing Designs to Life

Engineers (also called developers) are the people closest to the product; they build it! This gives them an edge because they get to directly experience and test individual components of the product in action. This is great because, without a doubt, they will find the weaknesses in any design—sometimes before building anything—which is doubly great because it is a huge advantage on so many levels to find the flaws before the software is coded.

The best way to earn the trust of an engineering group is to either produce comprehensive and complete product specifications or to involve them early on… or both.

When developers are considered true stakeholders, they are more than willing to discuss use cases, scenarios, technical challenges, and the options to overcome them.

It’s easy to forget that engineers are true product architects; they have a vested interest in solving problems with the designer, especially when the challenge is difficult or could be handled another way.

Database and System Architects, Guardians of Data Structures

Database and system architects know how the product works behind the scenes. They know all about how the data is stored and structured, what can be integrated, and how all the systems talk to each other. They tend to be less concerned with how the product works for users than how it interacts with various systems (which is what they’re ultimately responsible for).

They may be especially difficult for user-centric designers to deal with. It’s important to remember that even if a database/system architect never interacts with end users, their focus is always to benefit those users—be it through product reliability, speed, or simplicity.

Their knowledge of how data structures operate—and the ramifications of any changes to the product’s functionality—are too easy to miss without their expert input. It’s important to invite and include system architects in meetings and discussions on product changes, even if their position doesn’t seem to directly relate.

One way to collaborate with a system architect is to create a checklist with the following questions:

• Does feature X impact the current data structure?
• Is there any additional design/development work considering the current architecture?
• Does design Y conflict with any existing user inputs/outputs?
• Are any external services affected by feature X?

This simple list will point you in the right direction, even without a clear understanding of how pre-existing (and possibly) monolithic data structures work. Anything checked off is an area that should be investigated with a simple discussion.

Subject Matter Experts and Business Analysts, the Information Wizards

Subject matter experts are aptly named; they are experts in the subject matter and can be a gold mine of unique and valuable information. Often, they have earned specialized degrees in the field, or they have spent the bulk of their lives working in their industry. They have hands-on experience with how the business is supposed to operate, and they recall the long, painful history and politics that led everyone to where they are today.

A business analyst knows the ins and outs of how the organization operates and often fulfills the same function as an SME if the data is available but there is no in-house expert.

Engage with the SMEs to learn how the project is perceived by management to make sure that internal expectations are being met and that you are not treading in dangerous territory. Invite analysts to the design sessions, telling them in advance that they are the experts and asking them to share their knowledge of historical failures, political strife, and other issues that may be critical to a successful product release.

Customer Success Managers, a New Client’s Point of Contact

When new clients are finally onboarded by sales, trainers—or, for SaaS companies, customer success managers (CSMs)—take over to teach new users how to actually use the product. So it goes without saying that trainers spend a lot of time talking to novice users. A CSM has a unique perspective because they interact with customers who often weren’t involved in the purchase decision for their company.

With this unique perspective, trainers/CSMs can provide valuable information for design decisions, both for customer onboarding and new user behavior. Many enterprise organizations track and monitor how their new clients use various products and tools, and log everything from calls to complaints, but the trainers have a sense of what customers really struggle with.

Include a senior trainer in all major design meetings and inquire about any decisions with them. Ask questions like “What are the top three most serious customer complaints?” and, “Are new clients on average happy with the product?” and, “What changes do you think will provide the greatest positive impact for you and your team?” This way, we all learn about what the happy path is; trainers are our eyes and ears for all the ways clients actually use the product.

Sales, the Product’s First Contact with Customers

Sales and design are often at odds. Some organizations are sales-driven while others are not, but no matter what, there is a clear difference in goals: The sales team wants to increase sales while design wants to improve the user experience. They don’t always align.

That doesn’t have to be the case. Most salespeople have very reasonable gripes to contend with: They have little to no control over product decisions, are asked to make commitments they can’t really promise, and are driven to hit specific revenue targets despite everything. It’s no surprise that sales and product teams have heated arguments regularly!

Nevertheless, like trainers, the sales organization has a unique perspective on customer needs, and often, that perspective is the difference between making a small sale and bringing in a whale! Understand the different areas that the sales team struggles with. Try to sit in on every type of call, and learn how those prospects communicate.

This will open the conversation with sales. It isn’t just about having their needs heard; it’s about improving the experience for potential users at every stage, from first communication to after onboarding. Find out what salespeople hear from prospects the most, what challenges they have when finalizing the deal, and what the biggest concerns are after it’s closed.

Design in Enterprise Doesn’t Have to Be a Nightmare

As a designer, all of these moving parts can be very challenging to manage, especially when you are not considered a “manager” in the official sense of the term. As a key stakeholder in cross-team communication, the gathering of requirements, and design feedback, you should have access to all of these professionals at some level.

The most critical, yet simplest, way to do this is to listen to all parties and take their feedback seriously. In most organizations, the next step is to take that feedback and work with the product manager to organize requirements into actionable work.

From there, it depends on priorities and filling in the gaps. Ultimately, the goal is to design the best product, and we need the help of all product development staff. Recognizing that each role is important and making those personnel aware of their value in the product development cycle opens them up to providing the information a designer needs to make better product design decisions.