Building Frameworks to Shape How Teams Think

Callie de Roussan
HubSpot Product
Published in
9 min readFeb 14, 2020
Looking straight up into a blue sky framed by four sides of a classical building

Today, customer expectations are higher than ever. And for good reason. Products and services around the world have evolved their customer experiences into seamless end-to-end journeys. These experiences are nearly invisible, fitting nicely into customers’ existing day-to-day behaviors.

Companies that have achieved this level of success have learned how to construct a compelling story to tell users — learning how to architect the presentation layer of their customer experience to be consistent, compelling and cohesive — and they’ve learned how to align their underlying data models, technologies, and product teams in ways that support the presentation layer.

If you look at a cross section of any customer journey, it might look a little like this:

No matter how small your company is, it can be challenging to align all the moving pieces of your organization in a way that results in that perfect customer experience. But as your company grows — and your customer experience starts to be powered by many different underlying processes, tools, services, and teams — the challenge of maintaining alignment grows exponentially, too.

In a world where your customer’s experience is supported by many teams, methods you may have relied on previously to maintain alignment may start to fall down. For example, in a smaller company, having basic guidance around how teams should implement a certain component — let’s say, a color picker — works well. The teams consume the guidance, implement the components, and the presentation layer of their customer’s experience is consistent.

In a smaller company with a relatively contained experience, simple guidance typically works well.

However, for larger teams, when the same thing happens, the resulting experience doesn’t feel as aligned. Why? Even if these individual teams follow the component guidance exactly as it’s written, the company is now large enough (and the customer experience now broad enough) that these individual components can be implemented in vastly different contexts, solving the same problem in vastly different ways. Even if the components look exactly the same, they’re not being used consistently.

If we return to our color picker example, imagine how the more color pickers you introduce, the more complexity you’re adding to the customer’s ability to effectively manage their brand. What is the relationship between these color pickers? Does one color picker inform the default colors of other color pickers? In this world, guidance around what color pickers should simply look like isn’t good enough.

As soon as the experience broadens, in the case of our color picker, there’s a need for guidance around behavior, hierarchy, and customer mental models around brand management.

The problem is that most teams own a specific solution in a customer’s much larger problem space. As the company grows, and the customer experience spans potentially many different products, it becomes much harder for individual teams to understand where they fit in that larger journey. It becomes harder for these teams to not only maintain alignment at the presentation layer, but at all the underlying layers as well.

Enter Frameworks

When a customer experience extends beyond a single app, or has various underlying teams or organizations, it can quickly become hard to see the forest for the trees. This is where frameworks come in.

When I talk about a framework in this sense, I’m talking about bundles of system-level artifacts, deliberately organized and presented in a way that helps discrete teams reach alignment in a shared problem space.

Some frameworks may be mostly focused on aligning at the presentation layer. Consider an app’s design system: Not only does it have components and patterns, but it includes design principles, voice and tone guidelines, and other guidance that ensures individual UX and frontend teams are creating a consistent experience.

Other frameworks may focus on driving alignment at deeper levels of the customer experience, ensuring that teams are using consistent data models or thinking about a shared problem space in a similar way.

How to build a framework

Depending on the size of your organization and the complexity of the problem space, building an experience framework can be a massive undertaking. And since every problem space is inherently different, there isn’t a framework template you can pull off the shelf and take to the bank. What comes next will take some elbow grease and grit, but I promise you, your teams (and customers) will thank you when it’s done.

Identify your problem space

First things first: You need to clearly identify the broader customer journey you’re trying to improve with your framework and find a way to tell this story in a compelling way. Create a user journey map to illustrate what this experience looks like, and where it’s breaking down.

Audit for misalignment

With your customer journey in mind, look at different cross sections of the experience, assessing for misalignment. Loop in other members of your team who may have different domain knowledge . There may be areas of misalignment that are harder to identify if you’re less technical, tend to work on just one persona, or need a more global or cross-cultural perspective.

Here are some things to look for when you’re assessing different layers of the experience:

Presentation layer: Inconsistent components, patterns, or language; concepts being framed inconsistently from one part of the experience to the next.

Process layer: Inconsistent inputs and outputs, assignment, analysis, organization or prioritization of information that directly impacts the customer experience.

Tools/Services layer: Inconsistencies in how the information is being collected and logged by the team, how information is being transmitted between multiple tools, or how that information is being relayed back to the user.

Team layer: Inconsistencies in various teams’ cultures, mental models, style of communication, use of language, or vision; unclear and ineffective ownership within a team that results in the wrong (or too many of the right) people thinking about a specific part of the experience.

In the color picker example, you may notice that not only is there misalignment in how color pickers are being framed at the presentation layer, but there’s misalignment in the underlying processes and team mental models.

Focus the scope

Frameworks seek to solve really big problems, but big problems can’t be solved overnight. Once you’ve identified the areas of the customer experience where there is misalignment, flag the areas that you want to focus on first. These might be the areas of misalignment that are causing the most customer pain, or they might be things you believe are relatively low effort that teams can move on quickly.

If you notice a lot of misalignment at the team level, it may make sense to first align team mental models before attempting to align design direction at the presentation layer.

Define your opinions

Depending on how much you know about the problem space — how much collective research teams have done or how much data you have — this might be a good time to start defining your opinions on how to make the problem better.

These opinions will form the foundation of your framework and help you build a hypothesis to test and refine as you move forward. Depending on where the misalignment is in your organization and how misaligned your teams are, it may be easier to start defining opinions in a less controversial space. This part of the process can be a bit political (who’s to say your opinions are right?), so establishing some common ground right away is good.

These deliverables may take the form of principles, patterns, site maps, process flows, or other system-level artifacts. Once you have a first draft put together, start shopping it around to a few coworkers on other teams to check your direction. Choose three or four team members who have a stake in the shared problem space and can provide some perspective without slowing you down.

Scared to step on someone else’s toes? Taking a stand in a shared problem space can definitely be a little nerve-wracking, but when you’re working in a larger organization with a lot of moving pieces, it’s better to take a position and give other teams something to react to.

Remember, at the end of the day, the work you’re doing will make your team members’ lives easier, and most importantly, will make your customer’s experience better. Lead with that, and the rest will follow.

Identify stakeholders

With the scope of your problem defined and your opinions starting to take shape, it’s time to identify what teams you’ll need support from in building and executing on this framework. Make a list of all the different teams and individual team members who have a stake in the project.

The level of opinion you have at this point can influence which team members you need to loop in. For example, if you’re confident that there is a shared problem, but not certain what the solution is, you may primarily need buy-in from research and design. If you’re more confident in the direction teams need to go in, it’ll be important to get product managers and engineers involved.

Get funded

Before you make a formal call to action to the teams involved in your problem area, you’ll need to get funded. Since you’re trying to drive impact across several teams, each with their own opinions, priorities, and deadlines, it will be essential to have someone with some clout in your corner. By now, you should have a pretty compelling argument to pitch to leadership around this problem space. Bring the different pieces of your framework together and make your pitch.

Show leadership:

  • How this major problem is directly impacting business goals and the bottom line
  • What teams you need support from and what kind of support you’re looking for (such as additional research, design, product management, or engineering resources)
  • A high level strategy of how these teams can work together to make progress in this problem space

If the customer journey you’re focusing on is truly as painful as you believe, it shouldn’t be hard to tell this story and get support from leadership. This is also a great opportunity to partner with leaders in your organization to refine your strategy and prep for your kickoff meeting.

Schedule a kickoff meeting

Now that you have some powerful people in your corner, it’s time to rally the troops and make your public call to action. Schedule a kickoff meeting with the various key players involved, including your advocates in leadership.

In your meeting, you’ll want to go over:

  • The cross-team user journey that needs attention
  • Where the experience is breaking down — and how this maps to different teams
  • Your opinionated framework artifacts that will help teams start aligning in this shared problem space

Make sure to leave time at the end for questions, concerns, or other feedback from your team. And while you have everyone in the same room, you might use this moment to reinforce that this is a high priority mission that’s backed by leadership.

Empower teams to move quickly and test

Now that you’ve got everyone’s attention, it’s time to work with leadership and the teams involved to solidify your strategic approach. Take the lead on putting together a detailed game plan on what you believe the appropriate next steps are (again, they may vary based on how much opinion you have on how to solve the cross-team problem).

Clearly outline actions, owners, check-ins, and deadlines.

Reiterate to the teams involved that the goal is to continue to align in this shared problem space. As a result, you’ll be able to build more opinion into your framework and ultimately build a better customer experience.

Create a dynamic home for your framework

As various teams break off and try to run at this mission, you’ll want to make sure your framework stays top of mind. To do this, create a single space for these teams to reference framework artifacts, ask questions, share ideas and help evolve this direction over time. Depending on the complexity of the problem space and the strategy in effect, you may want to consider scheduling regular check-ins with stakeholders to make sure everyone is making progress.

Finally, take this opportunity to transfer the ownership of this framework to the individual teams themselves. You may have been the initial evangelist for this problem space (go you!), but at the end of the day, this is a shared problem and shared responsibility.

Celebrate

While the work is never really done, it’s important to celebrate how far you’ve come. Make a space for all the teams who contributed to this mission to gather and reflect on all that they’ve accomplished.

At the end of the day, nothing great is ever easy, but when teams come together for the sake of the larger customer experience, truly amazing things can happen.

--

--

Callie de Roussan
HubSpot Product

Remote product designer @hubspot, systems thinker and Freehand enthusiast.