If there's one thing I see a lot of in my work, it's dashboards. 

I don't talk about dashboards a ton because a dashboard alone is neither a data product nor an experience. It is an output and artifact that is part of a user or stakeholder's overall experience, typically in our case, in some decision making context. One of the key issues I see designers (i.e. anyone who is in control of the dashboard's design / UI / UX / data) making is that they do not understand the current or aspirational experience of the people using their solutions. They're focused on the data.

For many of you, the action points—the decisions—that are supposed to be informed by dashboards don't actually get enacted in the dashboard. They happen elsewhere. However, designers need to be thinking about these downstream decisions when we design—since ultimately, there's always a next step in the user's journey even if it's not taking place within the world of your app, Tableau, PowerBI, or whatever.

None of this generally changes whether you're using ML or not.

As a result, I am a big fan of journey mapping and service blueprints as tools that anyone can use to start getting into the heads of their customers. Of course, you have to do the requisite customer/user research before you can produce a real journey map, particularly an aspirational one that reflects a better future you want to provide to your users, but what it helps teams do is get their head out of the data and the outputs they have been asked for, and focuses the team on where decisions will/should get made, when, in what order, and how people are feeling along the way.

Now, you may find out that doing a journey mapping exercise also begins to uncover the fact that not all the people using your service—despite sharing job titles or responsibilities—make decisions the same way. Which then leads to the question, "should they be?"

For internal data product teams (and maybe commercial data product teams to,o at times), this is an opportunity.  One of my clients who is head of analytics at a large healthcare company once said to me early on in our discussions about his team taking my private seminar, "we don't want to be perceived as data widget builders." A sure fire way to have your most senior executives continue to see you in the "dashboard widget maker" category is to keep building one-off widgets and solutions for each user, even when those users/stakeholders are essentially part of the same persona or category of user. (A persona is a design tool to help us focus on real classes of people we're designing for. Two examples might be a regional head of sales who looks at dashboards as monthly scorecards and a sales rep who use your tool daily as an operational tool. The key point is that your "Sally the Sales Rep" persona is informed by real research you did with lots of actual sales reps—even if none of them were named Sally).

Anyhow, one way as a data product leader to stand out, to bring more business value, and deliver better UX to everyone, is to bring these different users—who seem like they should be under the same persona umbrella—together to do some collaboration around how they make decisions. Where does data fit in? Are there magic numbers they all agree to? ("if this sales KPI drops below 15, is anyone else besides Molly concerned and calling their regional contact?") Is there a valid reason why these teams—who seem like they should be making decisions the same way—are not?

This is also a great setting to bring in different low-fi designs to test and get feedback on. Dot-voting can be great here too. I call these Design Jams, and this type of jam is one where you get the magic juiciness of "divergent thinking."  Team A learns something about how Team B makes decisions that they never thought of which then spawns a new idea from Team C. Out of this comes—bing!—better "requirements" for what the product needs. You might find nobody needs to see all the historical overlaps of widget X in the warehouse, because that's not actually how these teams decided to make decisions going forward. 60 days of data engineering—saved!

The one thing I like about design as a tool to help data product teams is that it helps get the triple win: your users start saying, "Yes! Can I have more? Can you also do this?" Your stakeholders are happy because they see the outcomes of your dashboards and data product work creating a desired change for the users and other humans in the loop (you know, like actual paying customers even?!)  And finally, you and your team will be happier too: because you're working on technology that matters, gets used, and creates impact.

The status quo is calling. You can respond with a "yes, we can build that dashboard" even if you don't know why. Or, you can start giving the gift of questions: "why do you need that and how will that help you make a better decision? how will you use this to make that decision? Tell me more so we don't build a technically right, but effectively wrong solution you can't or won't use."

It's tricky, but the dashboard isn't really the thing they want.

Photo by Brett Jordan on Unsplash