The morning coffee dashboard

Last week I hosted a workshop for Airtree's Pathfinders program, and I thought I would share some pointers from my very passionate (I hope!) speech. The topic was understanding your users. I am not a UX designer, so by default not the most qualified person to talk about this, but I think I can share some approaches and gotchas.

In my head, analytics is the perfect instrument to get from bets (intuitions: I think this is needed, I think this is easy) to data-driven decisions (N users never make a purchase, N users never leave the main page).

In the old times before AI, analytics was a bit of blind poking. You look at the user journey, you identify the events you need for the analysis, you attach those events to user actions, you aggregate, you learn that you missed some events, and you do it all over again. With AI speeding up the development cycle you need answers much faster, and it is very tempting to say "Dear Claude, add me analytics" and consider it done.

This is a bad way of doing things. At least now, in the AI era. Imagine you can deploy an analytics event on any sneeze. On any experiment you want to run. The opportunities are limitless. The possibilities to get lost in the forest for the trees are also limitless.

That is why my main recommendation comes from the best software engineering practice there is. Think first.

Look at all the bets and intuitions you hardcoded into your product. Look for decisions that seem strange, new or disputed. For things you implemented because they were a morning shower idea. For Larithea I am making some strange (intentional) design choices. For example, you lose the tutorial fight. Are you going to rage quit or not? I am betting on not, but it would be nice to check, wouldn't it? Another bet: shortcutting crafting with a button that creates the necessary materials for you will result in players doing more crafting, not less.

It is a very good mental audit of all the things you would like to confirm. And then you can take the list to Claude and ask politely whether you already have analytics events for them. If you don't, describe what you want from analytics and get it out with the next release.

And then go and do a cool AI thing.

Describe the current state of the project in MARKETING terms. Something like: "We just released a demo on Steam. We want to know the wishlist number, but we are also concerned about the tutorial and the drop-off between the different tutorial states, and it would be good to know how stable our server is." And then ask Claude to create you a FAKE dashboard.

I cannot overstate the importance of this. If you want to make data-driven decisions, you need data. But having data and understanding data are really not the same thing. With the fake dashboard I am trying to force you to think about data representation a lot more than about data structure. I personally call it the morning coffee dashboard.

I am having my morning coffee and I open my analytics dashboard. What do I want to see? How do I want it represented? Let's go back to the marketing description. I just released a demo, so I want to know how many people played overall and since yesterday. As a company of one, my main focus for now is wishlists, so I need the overall number and how it changed from yesterday. I also need to know if anything crashed for anyone, so I can open an engineering chat and poke Sentry.

How do I want this data represented? Numbers? Timelines? Scattered dots? It is very important to jump into representation first, because you are building this for you. If you don't understand it at a glance while drinking your morning coffee, the value of it is zero.

My own answer turned out to be boring, and that is the point. The page opens with one section called "The one thing to read first": if something needs my attention today, it is there, and if nothing does, the section says so. Below it are plain numbers with the change since yesterday next to each. Players, wishlists, how long people stayed, where each player stopped. Then a list called "What broke", which on a good morning is empty. No pie charts. Nothing I have to squint at.

One more thing I learned the hard way: count people, don't divide them. At tens of players a percentage is noise that reads like a result. "Tutorial completion went from 60% to 75%" sounds like a finding, until you notice that it is fifteen people. So my dashboard shows how many people did a thing, not what share of them did, and the percentages wait until there are enough players for them to mean something.

And only after you have your list of questions and an idea of what the answers look like can you ask Claude to connect the real data to the dashboard — and maybe add a trigger so it refreshes every morning at 7am, so you can look at it around 8.