An acquisition conundrum: Company A, which owns one or more established products, acquires company B, makers of an up-and-coming product in the space. Company A intends to integrate company B’s products into its portfolio. And therein lies a challenge.
For company A to realize value from the acquisition, it must bring company B’s product into the portfolio — i.e., including redesigning its UX to fit in with the rest of its products — but doing so might reduce its appeal and utility.
Company A’s products have been around longer. It has a larger portfolio; it developed some products organically and acquired others. As a result, company A’s product UX is a mixed bag, with somewhat inconsistent nav structures, layouts, flows, etc.
Company B’s product is more focused. It does fewer things, and some of the things it does might be novel or different. (This is part of what made it an attractive acquisition target.) Because it doesn’t try to boil the ocean, company B’s product UX is more effective.
It’s a classic information architecture challenge. Each UX might use similar labels for different features or different labels for similar features. They may have overlaps, gaps, contradictions, etc. Clear labels in the new product might be ambiguous in the portfolio. What to do?
I’ll tell you what NOT to do: don’t start by sketching changes at the level of screens. Before drawing screen-level artifacts, you must define a conceptual model for the unified system — an abstract representation of the conceptual space users will encounter.
You start with research. Aim to understand the people who use the system: the tasks they hope to accomplish, their mental models for the domain, the language they use to describe features and operations, etc.
You audit both sets of experiences — i.e., map the critical words and phrases users will encounter and how they relate to each other. Are there gaps between concepts the system must expose to users and concepts users expect to see?
You must also answer critical strategic and technical questions. For example, will both systems keep separate account structures (e.g., logins) for a while, or will they be integrated soon? Is the business model changing? Etc.
Once clear on these questions, you explore a new unified conceptual model. The model is the foundation upon which the team will design navigation structures, labeling systems, screen layouts, etc. It brings alignment and clarity to a complex challenge.
But, you may wonder: what if company A has a design system? Won’t that take care of the issue? No, it won’t. A design system will ease front-end design but won’t help with labeling and information architecture. Only the model will do that.
Bottom line: integrating disparate product experiences isn’t easy. You shouldn’t tackle it by starting with the front end. Developing a solid conceptual model will bring clarity and alignment to what is otherwise a complex challenge.