Design in a merging world
Photo by author
As industries consolidate, we face the challenge of joining products that were designed in isolation. It requires making connections, across screens and between people.
The story, and what follows
For a while now, EdTech, the domain in which I work, has been in its consolidation era. It is not unique. As companies merge and acquire in order to meet strategic needs and keep up with competition, their product portfolios swell.
On a purely narrative level, the sequence of events looks clean and logical: the business identifies a strategic need, finds a product that fills it, and acquires that product. The acquirer is on an upward trajectory, continuously building on success, each new acquisition a step on the staircase.
Here in the UX trenches, where it falls on us to turn that narrative into a coherent experience that provides actual user (and business) value, things are messier. The merging of products creates a system of systems, which raises new and unique design challenges. This piece will dig into some of those challenges, and offer suggestions for navigating them.
Merging products — the risk and the reward
When we talk about the collection of products that coexist under a shared umbrella, we tend to use optimistic metaphors. We have a suite, a portfolio, or an ecosystem. This makes sense in an aspirational way, and it reflects the vision. An ecosystem is characterized by balance and harmony.
There’s another metaphor we could use, though, that serves as a cautionary tale: the story of Frankenstein’s monster.
Dr. Frankenstein had two main challenges in his quest to create life, both daunting. First: make a coherent organism out of disparate parts. The vital systems must connect and the pieces must fit together to form one functional whole. Here he succeeded.
Second: don’t freak out the villagers. Here is where he failed, and where we should pay attention. As we stitch together our products, even if everything functions as designed — identities are connected, data flows freely, and users can navigate between apps — all of our efforts are wasted if our new amalgamation fails to improve on the disjointed set of product experiences that our users are accustomed to.
We hope, in making these connections, to create a whole that is much greater than the sum of its parts by enabling each product to build on and enhance the value of the others. But, if we’re not painstakingly thoughtful about how we proceed, it could all go wrong, and quickly. Before we sketch any sketches or move any pixels, we need a firm grounding in:
common user tasks and needs across the products we’re connecting (how could using these things together make one’s life better?)constraints and requirements within the specific domain (what are the rules we need to be aware of?)the mechanics of each product (where is the devil in the details?)
In the absence of any of the above, we risk creating change for change’s sake. Few things enrage a user more than having to relearn a system for no benefit at all. Let’s not rouse the angry mob.
Mapping the system
Our job is to take the overwhelming complexity underlying our nascent system of systems and channel it into an experience that looks so clear and logical that it seems obvious, even if it was far from obvious when we started. In order to get there, we have to wade through a giant mess.
Use cases
Once we have conducted research to sufficiently understand who our target users are and what problems we think we can solve for them, we can narrow down to a prioritized list of use cases. At this point, a good way to make sense of our current state and the work still ahead is to make it visual. For each use case identified, we can map the specific connections, as well as the inputs and outputs of each product.
Diagram made in Figma
It’s crucial to be thorough and specific when documenting the gaps. For example: “Data from Product C synchs on nightly cadence, but to adequately support Use Case 1 we need to feed all user activity from Products B and C into Product A’s recommendation engine in real time.”
Once the gaps are documented, ask: are they showstoppers? What would it take to address them? Can we work around them? Do the answers to those questions change how we want to prioritize?
To platform or not to platform
As we analyze each use case, we notice a recurring need to define logic that will govern what information to display, what actions become available under which conditions, and, sometimes, what to recommend. Where does all this logic live? Is it spread out among the products, or is there a central logic layer that handles it all? If form follows function, then this line of thinking may lead us to the idea that we need a central platform experience connecting the products.
What does that look like? Again, it’s useful to diagram all of the data that must flow into the platform from the products, and vice versa.
Diagram made in Figma
As we fill in the details, the map begins to look quite wild, and we will naturally question its utility. This does not look like an artifact we would hand off to a dev team. So, why did we do it, and who was it for?
Three things: first, the artifact itself is less important than the journey we took to create it. Having immersed ourselves in the process, we have gained a deep and abiding understanding of the challenges we face and what we have to do to meet them. Second, despite its complexity, it can be a very useful reference when creating actual documentation for hand off. Third, hopefully at least one member of the dev team was deeply involved in this process, and has gained the same deep understanding.
Tactics
Once we’ve established our conceptual framework, we turn our attention to the equally challenging questions that arise as we start to make it all tangible.
Balancing I.A.N.
Let’s now consider our new platform, connecting all the products in our ecosystem. What is it, exactly? It can be useful to think about each screen as having some combination of three components:
Information (what can you learn here?)Action (what can you do here?)Navigation (where can you go from here?)
The tendency and the temptation when combining multiple product experiences is to go all in on navigation. In many cases, this approach — the wall of tiles — is perfectly fine. These are the cases in which each product is mostly inert and self-contained. In other cases, though, this approach leaves a lot on the table.
I.A.N. is unbalanced
The front page of our platform is incredibly valuable real estate. It’s where our users may be introduced to newly-added products, and it’s the primary provider of an ecosystem-level context. So, let’s ask ourselves: how can we help users save time here that would otherwise be spent hopping from app to app attempting to gain a holistic view of their current situation? What insights can we provide that incorporate information from all of their apps? What recommendations can we make based on those insights, and how can we make them easy to follow? How can we do all of this without overwhelming our users with too much information? In other words, how do we balance our I.A.N.?
Cross-product navigation
When you introduce a new product to your ecosystem, you may be connecting your users to an unfamiliar experience. We hope we have built up enough credibility and loyalty with these users that they are willing to trust that this product that has abruptly appeared in their lives is worth the time and effort it will take to incorporate it into their routine. That trust can be quickly undermined if the cross-product experience is confusing and disjointed.
We are responsible for helping users understand why they are being sent to this new place, and what they can do when they get there. To that end, good UX writing is invaluable. If we are unable to briefly and clearly explain why this product integration is beneficial to the user in context, that may be a sign that we need to re-examine our strategy.
A stark mismatch in look and feel can also add to a feeling of incoherence. While a wholesale UI update across all products based on a new, shared design system is likely unrealistic, there are smaller steps that can be taken to reassure the user that they have not been suddenly transported to Oz. Brand identity is key here. Even limited alignment of product logos and strategic adjustments to color palette and typography can go a long way to establishing a visual connection between the familiar experience and the new one.
Think of a fully consistent, ecosystem-level style as a longterm goal, and take a phased approach that allows you to continuously, if slowly, keep moving in that direction.
Where’s my cheese?!
It’s inevitable: when we change a core experience, no matter how thoughtfully we planned and how much we believe we have improved it, a subset of users will be angry. They will also be vocal. Be aware going in, and prepare yourself emotionally, while also recognizing the validity of their anger (as well as the validity of our need to step away from it and take a breath).
Change management is a tough nut to crack, which is not to say that there’s nothing we can do to make the transition less painful. To the extent that we can help our users anticipate the coming change, we should. Even better to provide a level of control over the transition by giving users the ability to opt in and back out of the new experience for some set amount of time.
Living through change
While the focus of this piece has been on the impact of corporate consolidation on product design, there is a larger picture to keep in mind here. When companies combine, the impact on workers can be dramatic. The joining together of people, products and systems creates work, disrupts routines, and shakes up the social order. It is not surprising that employees tend to leave en masse in the wake of these events.
Within a newly-expanded UX team, the change may mean more meetings, new processes and tools to learn, and more layers of decision making. It can feel slower, and less nimble. As a team gets larger, communication becomes harder. But as we adapt to new ways of working, we learn from each other. Fresh ideas keep us from getting stuck in old habits.
For many of us, particularly those of us who are neurodivergent, the expansion of the team can be jarring and uncomfortable. We have established routines, habits, and trust with our old team. Now, we feel like we have to rebuild our professional equity from scratch. But hopefully, as we form relationships with new colleagues, we remind ourselves of our strengths, and reaffirm our value.
We may feel defensive, as our design debt and the state of our design systems are suddenly exposed to strange new colleagues. But, as we feel defensive, we recognize those same feelings in our counterparts, and realize that we all have room to improve along with reasons to be proud.
Relationships are everything
For workers in startups and smaller companies that are acquired by one of the big fish, it’s reasonable and justified to worry about assimilation into the larger system. They may feel a sense of protectiveness over this thing they so lovingly designed, and a fear that the special qualities that won over a devoted base of users will erode as they get incorporated into the big new platform.
These new teammates are crucial to the effort. The ecosystem is defined by its dependencies. We rely, heavily, on our partners to also commit to making it work, and so we must build trust with a wide range of stakeholders, each of whom have competing incentives. This commitment will eat up large portions of their roadmap. It will require engineering teams to connect disparate technologies, and to work through the bugs and frustrations that inevitably arise in the process. It will present design challenges that can feel overwhelmingly complex.
It may be tempting, after a point, to declare “good enough!” on the organizational level and consider it a wrap. Don’t give up! The most profound benefits of an ecosystem, and the most rewarding relationships made along the way, can take a long time to develop. It’s our job to create the conditions under which they will prosper.
Building a product ecosystem was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.
