Redesigning the Information Architecture of an Existing Product
This year Lucidchart turns ten years old. What started as a simple flowcharting app is rapidly involving into a robust visual reasoning platform (our word for data visualization and analysis within the context of a process of system). When the UX team first arrived at Lucid, we fell in step with the fast-paced agile development cycle, built an iterative design process, and pushed the product forward quickly. Over time, as the product took on more advanced functionality (such as data integrations) for specific market needs, we situated them without accounting for the overall architecture. After a few years of this, we began to see the impact this was having on our work. As the product grew in our fast-paced environment, we encountered a number of product problems common in products that quickly grow from startup to high growth:
- Duplication
Different feature teams were beginning to arrive at the same workflow and UI conclusions through research - Inconsistency
Similar yet different experience existed in various parts of the product - Broken workflows
Customers struggled to anticipate where they might find a specific feature within our complex product
Over the last six months, these problems began to create roadblocks in product development and usability problems that couldn’t be fixed without rethinking the core architecture of our product. Armed with this realization, we set out to fix it.
Designing a new Information Architecture
Fixing the Information Architecture of a product is more than just cleaning out a messy closet. It’s kind of like untangling a fine-chain necklace — you have to take careful steps to keep it together without breaking the chains. Below are the steps we took to “untangle” the mess we had created, and were a result of the specific difficulties we were facing at Lucid. You may need to rely on different steps to help you and your organization rethink Information Architecture depending on the size of your organization or the maturity of your product.
1. Executive Sponsorship
The first step in fixing our product’s Information Architecture was admitting we had a problem. This happened over the course of a few months as teams began to hit walls and new log-jams in production popped up. Fortunately, many teams were sensitive to more than just symptoms, and traced these problems back to Information Architecture issues. Each of these teams planned to solve this problem, causing conflicting roadmaps and stalled momentum.
Teams communicated this need in design reviews, executive presentations, and other forums to create a clear, consistent signal that was recognized by our VP of product. Rather than initiating several fragmented efforts to define a bottoms-up IA, our VP of Product restrained teams until we could do it the right way, with the right people. This came shortly after mid-year major strategy updates that initiated a natural “reset” for many teams.
The window to define a new IA for us was rather small — and due to the urgency of the project, we were given one week to break ground. Without executive support, it would have been difficult to align 26 scrum teams between dozens of designers and product managers. Our VP of Product helped us find a window of time in our company’s strategy and took the time to communicate the value of such an initiative to the executive team.
If you need to reset your product’s IA, work with an executive that can support it and find a window in your company’s strategy to execute.
2. Forming a Team
When it comes to planning and developing the IA of an existing product, several people are required. This is because knowledge about your existing architecture, users, and workflows is likely spread throughout your organization. One of the hardest parts about cross-functional initiatives like this is that it’s difficult to form a representative team large enough to include all necessary perspectives, but small enough to make progress (especially with our small window of time).
This situation was no different at Lucid. Although several product managers and designers had great ideas about how to improve our IA and the product, we eventually chose only six individuals (2 UX, 3PM, 1 Eng) to lead the initiative. These people were expected to devote 80% of their time for one week, loosely borrowing from the Google Sprint method with 10am — 5pm sessions each day of the week. Once we had the confidence that we could move quickly with the right people, we made plans to begin.
3. Picking a Methodology
While there are probably many methods to assess and rearchitect a product, we used a method a few members of our product and design teams had experience using in other companies. We used a method based off of Karen Holtzblatt’s work and can be found in her book, “Contextual Design” that focused on User Environments (UE). For extra support, our VP of Product brought in a consultant to help create some momentum and provide coaching who had more experience with UE design. This consultant also helped audit our current IA from an outside perspective and trained us on the UE methodology, concepts, and nomenclature.
Because Information Architecture and User Environment modeling requires a higher level of abstraction than most designers are used to, making progress with new methodologies is difficult because a group of people have to learn new concepts to frame workflows, user needs, and product functionality. This was the hardest part of the architecture method we used — to let go of the way each of us had come to understand the product over the years, and reframe everything through new lenses of functional clusters, focus areas, and user intents. Our challenge was additionally compounded because not every team member had the same level of product fluency.
We quickly learned how important a positive attitude is during a project like this. We had to each help the team not get discouraged while experimenting with new methodologies. Sometimes it’s necessary to suspend disbelief or doubt to make progress.
Be mindful of how abstract some methodologies can be and be patient with each other as many members of your team orient themselves to architecture-defining activities. In the end we ended up in an incredible place with a strong shared understanding across the team, but it isn’t always easy getting there.
4. Team Breakout Sessions
Because the core team of six didn’t have context for the entire product, we reached out to other team members to gather insights and feedback. Breakout attendees were asked to think through features and experiences they were responsible for, and articulate nuanced value. They noted various intents and jobs-to-be-done that helped the core IA team organize user intents. This usually involved a short time to think through their current and past projects, lots of sticky notes, and group discussions around how to organize and cluster the group input.
It’s important to note that these weren’t just about the current needs of teams and customers, but also the future needs of the product we understood from our product strategy and insights heard in contextual interviews. This architecture we were to create, needed to support us for the next several years, and continue to scale as the product grew and evolved.
We took what we learned from all these breakout sessions and synthesized it into a hierarchical “intent map.”
6. Designing IA v1
Once our team had an organized map of intents for our entire product, we converted it into high-level architecture of groups based on functions and workspaces. Think of this view as a set of floor plans. It reveals the “rooms” in a house and how close or far a customer has to travel to move between rooms. It also helps reveal what a user can accomplish (or what their intent is) in each room. This was the working model we needed to continue to push and pull ideas without breaking the product. This is the level of thinking and understanding our organization needed to guide and strategize, without colliding into other teams.
As you can see, Lucidchart is a big product. It serves several different types of customers with varying needs and intents. The map below a small attempt to capture the IA of just our editor, which ignores our document management areas as well as our enterprise admin experience. We did all this work in just one week! In the small window we had to align teams and reframe our AI, we were able to architect only our editor experience.
Here’s an anonymized view of our proposed user environment:
Lucidchart is a big product, though. It serves several different types of customers with varying needs and intents. This map above a small attempt to capture the IA of just our editor, which ignores our document management areas as well as our enterprise admin experience. Though the purpose of this exercise was never to create an exhaustive map, it’s clear there’s more work to be done.
Next Steps
Because not everyone in our product and design teams could be involved in the week-long IA bootcamp, some of us learned the principles, nomenclature, and concepts needed to continue pushing this forward more than others. It’s important that those other teams be able to speak the “User Environment” language and continue to engage. It’s also important for the “experts” to evangelize and support. So we’re focused now on running smaller teams through similar exercises of mapping out user intents and generating more granular views of the IA. We hope this becomes a core skill for all design, product, and development team members. The work that lies ahead for us to continue to sustain this effort includes:
- Continuing IA Design
We’re far from done. It will take more than six people and longer than one week, but we’ll continue articulating and defining the details of an IA that will resonate with customers and create an easy-to-learn, intuitive interface. - Information Architecture Dev Team
For the first time, Lucid will have a development team dedicated to Information Architecture. This team will own the IA materials our group produced, and they will resolve any questions or considerations brought up by other teams who need to influence the IA. They will also start work to bring the current app in alignment with the future IA we produced. - Coordinated Implementation
Teams will be expected to tailor their projects to meet the guidance of the IA. When teams need to work in the same area, they will find ways to merge their efforts rather than racing for the fastest implementation. - Project Check List
We’re constantly tweaking, changing, and iterating on our product development process. We expect each team to take the product IA into account for each design project and release cycle. - Career Growth and Performance Reviews
Because of the importance of this effort to Lucid’s growth and success, we’re finding ways to reflect thoughtful IA consideration into year-end reviews to support and elevate team members who strengthen Lucidchart’s core IA.
What We Learned
Firstly, we should have done this a long time ago. If you are brought onto a new team, asked to design a new product, or are working with an existing product, I’d encourage you to ask about the IA. When was it last considered? How can you review it and understand it? And, if necessary, how can you redesign it?
Leadership at Lucid cares about design, and about doing things right. We’re learning the discipline to do things the right way (and not necessarily the fastest or easiest way). Having executive awareness is helpful, but having executive support is a must. This process can only work if it’s championed by those who have the greatest influence on resources and roadmaps.
We also found that Lucidchart is unique in both its depth and breadth. We don’t have the benefit of focusing on one or two personas who drive the primary features of our app. Instead, we have to consider several industries across various demographics, license levels, and collaboration behaviors. We narrowed scope multiple times on the project, but that doesn’t remove the work that we still need to do. The more you understand about your users, the better sense you’ll have of the work needed to support your IA.
Lastly, it’s going to be tricky to implement this new IA with 20+ scrum teams building on an existing product. We’re excited to have executive support and a fully dedicated development team to help.
We’ll be referencing these documents and plans for several years to come. The work we were able to accomplish while redesigning our IA creates a north star for teams to follow and use to provide consistent, cohesive, and intuitive experiences for our customers. If you join our team, you’ll be able to impact this IA too and improve the experience for millions of people.
