Enterprise data viz design strategy
As a data viz consultant, I saw some really common patterns. From Fortune 500 enterprises to small organizations like government departments or start-ups, there were motifs of tension between IT and “the business”, lack of adoption, and unmet user analytic needs. I’ve seen arguments and accusations between IT and the business during meetings, crazy workflows users had invented to get what they need, user-crated databases that lived across 10,000 Excel files, and even analytics performed with pencil, paper, and a smartphone calculator.
What’s interesting is that most of these organizations had really strong Business and IT strategies. This may seem counter-intuitive — if there were so many problems, how is the IT strategy strong? The IT strategy was strong because the technological architecture existed to meet the business goals. There were robust, fairly well-architected data warehouses. The business intelligence tools were integrated with these platforms. ETL was efficiently scheduled. Data security was top notch. Development followed an agile methodology to quickly create accurate dashboards and reports. Essentially, all the technology pieces were there.
The problem was that the design was wrong, not the technology. IT provided all the necessary pieces, but they remained inaccessible, unusable and uninterpretable because the organization lacked design strategy.
Design strategy in action
Design strategy is a common practice in product development and marketing. At the simplest definition, design strategy couples creative direction with business strategy. Design strategy focuses on addressing customer needs in ways that will advance the business in line with the business strategy.
As an example, I worked with a healthcare organization to develop an entire portal of products. The organization told us that their strategy was to move their user base from analysts to executives, and to help their customers become more strategically data-driven. We did a lot of discovery and user research, performed some basic journey mapping, and learned two key points. First, their current product offering required skills their executive users didn’t have, such as a robust understanding of the technology platform. Second, that the analysts were typically using the products to prepare reports for weekly strategy meetings.
This knowledge informed our design strategy: we were going to bring analytics to executive users by designing dashboards to be used during weekly strategy meetings. We were going to eliminate the manual, repetitive meeting prep, all while providing weekly exposure to a portal that the executive users could access on demand.
As a result, some of the our client’s key points of contacts became executives, rather than analysts. New channels of communication were created between our client and their customers, leading to new opportunities for revenue generation. Essentially, we designed a path to key decision makers.
Applying design strategy to enterprise data viz
Many of the IT groups I’ve worked with have really strong BI methodology. Traditional, agile BI methodology is fantastic for rapidly producing technologically sound dashboards and reports. However, technologically sound is very different than usable and interpretable, and this is where analytics often fail to run parallel with the business strategy.
The technology is sound, but the design isn’t. We have data experts building data tools for non-data experts. We understand databases and aggregations and complex charts so well that it can be hard to remember everything we had to learn — and what our users will have to learn to use what we create. The users aren’t stupid; they just don’t carry our sophisticated background in creating and reading charts.
There’s no reason why we can’t keep the strongest components of more traditional BI methodology, but pair that with a design strategy that brings an understanding of the users and business strategy:
The fundamental idea behind executing a data visualization design strategy means design happens with thoughtful intention. Every piece of the design — from the organization of dashboards to the formatting of text and the colors used — are intentional choices. There’s little (if any) design for the sake of “making it pretty”. It’s understanding the function and the form.
Preferably, this thinking happens at the enterprise level, and then cascades down to each design. In very siloed organizations, it can make sense for it to happen at the business line or departmental level. Of course, if you’re struggling to get buy in at the enterprise level, starting with your team is a great way to produce strong content and get the word out.
Here’s some of the core pieces of the successful data viz design strategies I’ve seen:
- An in-depth understanding of the business strategy, including the markets where they want to enter or grow, and the markets they aren’t interested in. A key feature here is understanding the “levers” available to overcome obstacles and accomplish these goals, such as “targeted email marketing campaign to convert new customers” or “physician engagement and education to align with prescribing standards”.
- As strong of an understanding of the users and their needs as possible. The research should be curated into a library of role-based and use-case based user personas, so that designers can reference them during their design process. In my organization, we’ve actually used this as a form of “testing”, where we ask the designer to reference the user persona to justify certain design choices. (Note that a criticism of Design Thinking questions whether designers can objectively understand and empathize with users. We shouldn’t ever assume that we know our users well enough to speak on their behalf — but that doesn’t mean we shouldn’t try to understand.)
- Content governance that describes the information needed and where it lives. This governance is aligned with the business, not IT. I think of data governance as a core foundation for content governance, where data governance supplies all the necessary details (like calculations) and mappings to the technologies (e.g. database tables) for a strong content strategy. These are often stored in content maps, which allow you to identify where information exists across all your dashboards and where users will find the answers to certain questions.
- Product and information architecture that ensures the designs fit into a bigger picture. This helps curate your collection of dashboards and reports. I’ve seen a lot of servers full of hundreds of reports that were just quickly built from a user request, and often they are organized into folder structures that make sense to IT but not the users — consequently, users have no clear path to explore and navigate, and often only get part of the answer they really need to make the best decision. Creating a bigger picture of how all of the dashboards fit together from a content / information perspective, the navigation from one dashboard to the next, and a map to user personas ensures every new dashboard strengthens the overall ecosystem for everyone. More traditional models may strengthen the offering for one user with a new dashboard, but this extra dashboard makes it harder for everyone else to navigate and consequently weakens the architecture for everyone.
- Design principles that fit the users, rather than the author (or blanket “best practices”). This refers to standards guides and style guides that designers reference when creating. These should be specific to your user population — informed by best practices and research — but carefully fitted to your audience. A great example can be found in the best-practice advice of preserving accessibility by avoiding the colors red and green: for some organizations, red and green are colors that are ingrained as part of the culture (“we’re in the red” or “in the green”). Rather than simply applying the common best practice advice, a style guide in this organization may include reds and greens to preserve the culture, but with different saturation or luminosity to preserve accessibility.
The results of a successful design strategy
The most valuable result is the acceleration of the path to business goals, but as a related benefit, the improved relationship between the business and IT. You’ll no longer see the business hesitant to involve IT, or lengthy workarounds to avoid involving them (a strong concern voiced by a few of clients). In addition, IT’s increased understanding of the business users’ needs leads to new respect for their roles. Ultimately, the business can often trace specific wins back to the contributions of IT.
All dashboards and reports fit into a comprehensive ecosystem. This streamlines navigation away from complex, IT-defined folder structures into natural click streams so that users can find what they need without lengthy bookmark lists. New content is released within the ecosystem, either as an update to, or a new link from, an existing dashboard. Every dashboard has a consistent brand and UI, so learning is only incremental for new features. Adoption is higher because pain points are being solved. Technology is being implemented in a way that not only gives users data, but it gives it in a way that makes their work easier. The rewards are, by far, well worth the effort. It’s worth slowing down, if only a little bit, to get the creative direction right.
For organizations that are just getting started, this is a way you can prevent paying a consulting firm hundreds of thousands of dollars on “report consolidation” five years after you’ve rapidly produced content. For organizations already in that situation, it’s helpful to carve out a space where you can create a design strategy, learning from your past and cleaning up along the way. Design strategy also accelerates innovation. It’s common for IT departments to be bogged down with backlogs of basic, ad hoc user requests, and the issue is that the users typically aren’t technology or data people — which means they don’t know the art of the possible.
As you understand the users better and curate a holistic ecosystem, you start to see how you can propel them forward in ways they never imagined — and, you’ll have the time to really drive the innovation that makes all those IT dream projects a reality that excites the users as much as the engineers.