(8) reasons why data visualization training for your BI team may not increase analytics adoption

(8) reasons why data visualization training for your BI team may not increase analytics adoption


"We need data viz training."

Me: "Oh yea, why?"

"People find it hard to use our analytics, reports, dashboards etc. We just bought [fill-in-new-BI-tool], but we're still not good at making it easy for our customers. Do you do data viz training?"

Me: "What do you want to get out of data viz training?"

"Adoption. Use. Simply getting people to use the technology and stop doing things the old way."

The customer's request here is, "data visualization training."

However, my job is to help them to unpack whether they're trying to develop a specific skill, or whether they are trying to get better at routinely producing value and outcomes for the users and business?

Because not all adoption problems with anlaytics will be solved with data viz training—despite the fact the industry seems to think design and data viz are synonyms.

The UI/viz is just the easiest (and possibly only) part of the design your customers can see to complain about. 

They won't ever say, "you didn't interview me properly or get to understand my workflow." Or, "You didn't evaluate the prototype early enough, or properly in the context of the work I do."

Focusing only on visuals, whether it be the aesthetics of your UI, or just the "data viz" aspects of your dashboards and analytics solutions is like saying, "we need Python training" when the team has no understanding of basic engineering principles, math, SQL, performance, or data structures.

Simply improving your team's Python skills isn't going to solve every technical problem you have.

While you may indeed have a skill gap around data viz that should be addressed, to me, this is a tactical approach to solving a strategic problem. 

If you seek to drive adoption and value with analytics, then learning how to apply human-centered design to the solutions will go a lot farther at producing outcomes than trying to throw data viz at every problem.

If you choose instead to relentlessly focus on data viz only, there are risks, because your team will not be doing the rest of the design work required to enable visualizations to routinely be successful.

So, here are (8) reasons why data viz training alone may not increase your customer's adoption of analytics:

  1. You can't quickly get to "better" if your team, and the stakeholders, cannot "see" what the current + desired future states look like.
    What type of analytics UX are you currently delivering to your users? Where are you under-delivering to customers/users? Where are you doing well, supporting decision making? What exactly does a "better future" look like? Hint: people need to see the gap. You can't just say "more adoption." This is not design-actionable.
  2. You need to be open to less building/data/tech; more listening/observing. 
    A human-centered approach means frequent, consistent time spent listening to and observing customers/users and developing empathy. It also means involving them in the design creation process and realizing what people ask for initially may not satisfy them in the end.
  3. If you still think Design and UX are this "hand-wavy" fluff thing, you may not be ready for change.
    First it was data-viz. Then it was data-storytelling. The data world loves to avoid using the term "design," and I get it: it's not analytical, black/white, and UX sounds subjective—especially to the analytically minded. Regardless, if you really want to put people at the center of your work, a product mindset and a realization that the design of the solution matters is essential. Look: the vendor / BI tools keep getting better, but data-driven projects still fail at a consistently high rate. What does that say? (I know what Tom Davenport says: the analytics field gets a 2/10 for value creation). Do you need more data to understand how poorly we're doing with providing useful data-driven solutions?
  4. "Data visualization" is only one aspect of designing human-centered data products.
    Design and Data Viz aren't the same thing. Why should you care? Because you can keep training your staff on the ink skills, and still fail to deliver value with analytics. A better data-driven user experience may involve little to no tables or data graphics, but it still requires intentional design if it is to be effective at producing decision support. Understanding how to apply human-centered design gets your team thinking at a higher elevation, so that every idea isn't just limited to what they can generate in an XLS doc, or your BI tool.
  5. It can be hard to measure the efficacy of design…if you don't define progress and success metrics early on.
    TLDR: if you don't know how to measure it, you probably want to get help, however you will likely see positive progress over time if you simply implement  the behaviors as a routine part of your solution-making process (aka "product development," but I know you may not call it that if you're an internal team).
  6. Design is everyone's job...but certain people are better at it than others.
    I am not talking about "raw talent." Instead, I think you can "practice" your way into being quite competent at design, and having a "designer" title isn't likely what you or anyone on your team cares about. When I come into a client engagement, I can usually tell pretty early on which "non-designer" (read: architects, engineers, other analyst/technical people, etc) will be good advocates and can likely become internal design leaders within the org. You will likely scale faster if you can identify these people first and put extra effort into their skill development so they can then become the next teacher. Ultimately, you want to level-up into a product mindset, but first, get them leveraging design in their daily work.
  7. Lack of adoption may require behavior change that has nothing to do with good or bad data visualization.
    If this were true, then getting people to exercise more and eat better would simply be a matter of showing them better charts and graphs of their current state and progress. Certainly, you may have room for improvement on the visualization side of things, but you can't assume every analytics adoption problem is a "data viz" problem.
  8. Data viz won't tell you how to extract unarticulated needs from users, or how to objectively measure the quality and usability of a given design/report/artifact/dashboard.

Look, it comes down to this:

The software industry learned a long time ago that if you want to design effective, usable, useful solutions, you have to give thought to UX if adoption is important.

Enterprise software no longer gets a free pass either.

Despite BI tooling improvements, the research trends suggest the data analytics community is not much better off at creating value despite the maturation of vendor software.

Even when they put "AI" next to the latest release.

You can't "python" your way out of every technical problem any more than you can  "data-viz" your way out of every problem related to customer adoption of analytics or data product design.

You need to start looking at analytics as a people and data problem—one that does not start and end with putting ink into tables and charts.

Human-centered design operates at a higher, strategic level.

When your team has that skill under their belt, you're much more likely to repeatedly produce the indispensable data products, analytics and business outcomes that your stakeholders seek.

Taking the Next Step: Moving From Data-Viz Training to Human-Centered Design Training (or UX)

(7) Alternatives to Regular Data Visualization Training

So, if data visualization training isn't "enough" to drive significant user adoption over time, what else can or should you do if your real goal is to drive adoption of analytics and provide amazing decision support solutions?

In short, learning to apply human-centered design to projects and products—not just data viz—will allow you team to more routinely produce useful, usable solutions that actually get used.

Below are some ideas on how to accelerate this process, roughly ordered by cost and/or acceleration:

  1. Tap your existing product/UX/design leaders in your company to help you—even if they're in another division of the company. Get the conversation started, whether it's about getting hands-on support, or having them train you. Most teams will be taxed for time, but will be glad you reached out. If their design/product leadership is good, they will want to involve themselves in your work. Keep in mind, some of your staff might actually be stronger at data viz than some of the designer may be, depending on the type of work the UX group does. However, their knowledge of UX/product design can compliment and "complete" the skill gaps your team may have. Keep in mind that UX is also an evolving practice, and a lot of companies still struggle to find good UX talent, however you shouldn't dismiss the power of the discipline simply because your company  doesn't have the right people to assist your ghroup.
  2. Hire a FT senior UX/UI designer, principal designer, or VP/Director of UX to develop a way for design to have impact within your existing organization. If you have some strong data-viz people already, focus on somebody primarily with UX skillsets. If your team needs both data viz and UX help, a hybrid person with UI and UX skills may be best, but be sure they have a strong UX background. (Many UI designers eventually move into UX, but many do not like doing UX or can't do it). If they have UI experience, look for data viz in their background. That said, what you probably need more is a UX skill set aka human-centered design in some circles. The person you hire's early goal may not be to do design or data viz work themselves on your products, but instead, to help you figure out "how do we scale design properly within THIS org and culture." Let them help you assess whether you need to hire or train etc.  Personally, I think this is your best long-term investment, and possibly the most rapid way to accelerate adoption of your analytics and BI work would be to have experienced staff assisting you. That said, you may not be able to find an analytics specialization in your UX hire and it may take time for this hire to get comfortable with designing data products and decision support solutions. That said, most designers are very comfortable with and used to changing domains and industries.
  3. Engage an advisor/consultant with design, management, and analytics expertise to help you assess your particular situation and how you might approach this. Note: A "data viz" expert may not be the right fit as they may be focused on hands work/execution/implementation, and not on the other skills you need to bring to your team. A lot of companies do not need crazy/complicated data viz outputs; most users of analytics need simple, familiar visual vocabulary (line charts, bar charts, sparks, etc). Yes, this is something I do and you can set up a free discovery call if you need help. Whether you work with me or not, this may be the fastest way to get results if you're really needing to improve adoption, usabilty, and utiltiy of analytics in the short term. 
  4. Hire a FT individual contributor or contract UX, product, or UI/UX designer to assist on a project basis to build up some early wins. You can "try out" what it feels like to go beyond data-viz only, and apply UX and human-centered design to a project. Finding a suitable person may be difficult, as many contract UX/UI people aren't going to have analytics specialization, and a contractor will primarily be looking for direction from you, vs. leading the engagement unless they are quite senior.
  5. Train yourself or your staff on design: this can be individual, or group, and in both public and private settings. There are many generic "design thinking" courses as well as UX courses and finishing schools that may help, but I recommend you look for training that is specialized in the space of analytics and data products, and something that is not focused on trying to turn your staff into titled "designers."  I run an Instructor-Led Seminar and a Self-Guided Video Course that are heavily customized to serve  data professionals (analytics/BI, data science, and technical product management leaders) if those are helpfiul. There are also Masters programs now in human-factors/information design etc, such as the one at Bentley in Waltham, MA, however these are not going to be focused on the data product community.
  6. Attend product/UX design conferences and meetups to "soak in" what people are doing. Check your local listings. See if there is a local chapter UXPA group in your area or look online; Meetup has many events, and there are many UX Slack groups out there with specific Event channels you can follow.
  7. Read books! I can't point you to one book that really will teach you about design for data products, but I am likely going to write it at some point. In the meantime, here is my suggested reading list!

Need further help? You can contact me with questions via my Contact page. If you found this article useful, I publish an Insights mailing list and podcast you might find helpful as well. Subscribe using the form below.

***

Photo by JC Gellidon on Unsplash