After Building a Dashboard, I Needed to Design How to Read It | Ohayou Kanojo #68
Introduction
"Ohayou Kanojo" is an X account where a girlfriend says goodbye to you every morning at 7:30. I write its development log on note every day.
Around the time I passed 60 articles, I built a dashboard that automatically retrieves article data. PV, likes, like rate, and day-over-day changes. The numbers accumulate on their own every night.
The problem was what happened after that.
I would open the dashboard every morning, look at all the panels, think "Hmm," and close it. Before I knew it, 15 minutes had passed. I hadn't made any decisions, yet I felt like I had looked at it.
What you should look at on weekdays is different from what you should look at on weekends. Unless you design for that, a dashboard becomes nothing more than a "device for staring."
On weekdays, look at only one line
What I want to know when I open the dashboard on a weekday morning is simply "what kind of day yesterday was."
There is a phrase from an article by KITAcore that left an impression on me.
What matters is not the "point" but the "arrow"
"Hypothesis Memo" for Reading note Operations with Data #126
How things moved from yesterday is more important than what today's numbers are.
So, I borrowed the three KPIs advocated by KITAcore.
Reach Power = Total PV ÷ Number of Articles
Action Power = Total Likes ÷ Number of Articles
Like Rate (η) = Total Likes ÷ Total PV
I display the day-over-day change for these three KPIs using arrows (↑↓→). Then, I set it up to automatically generate a one-line status memo based on the combination of arrows.
An automatically generated status memo below that.
For example,
if it's "Reach ↑, Action ↓, Like Rate ↓,"
it says "Exposure increased but it didn't resonate. Possibility of a title-driven result."
If it's "Reach ↓, Action ↓, Like Rate ↑,"
it says "Possibility of relative effect due to PV decrease."
There are 27 patterns for the combination of the three arrows. I assigned a one-line status memo to each one.
On weekdays, I copy this one line and paste it into my mini-log. It takes one minute. I don't overanalyze it.
On weekends, I look at the category balance.
What I look at on weekends is the decision-making material for 'what to write next week'.
I classify my articles into six categories: A (Design Philosophy), B (Trial and Error), C (How-to), D (Reflection), E (Character-based), and G (Special).
The trend of like rates differs by category. Categories A and B, which have primary information at their core, have high η, while how-to and reflection articles are slightly lower. This was a pattern I saw when I sorted 60 articles by like rate.
I added a category-specific like rate comparison panel to the dashboard to check every week if this trend is being maintained.
The 'primary information zone' of A and B and the dashed line of the overall average.
This is what I look at during my weekend check.
Were there two or more articles in categories A and B this week?
Is it biased only toward C and D?
Which categories are most frequent in the top 20?
With this, I only make the decision to 'include two or more A or B articles in the seven for next week.' If I am too conscious of categories before writing, I get stuck in a mold, so I only focus on the 'number of articles'.
I only look at the panels when I want to dig deeper.
There are other panels on the dashboard.
Like rate ranking top 20. PV x Like scatter plot. Like rate dot plot for the last two weeks. Daily PV transition by article.
With category color-coding, you can see at a glance
which article is in which zone.
But there is no need to look at this every day.
When my status memo says 'Reach ↑, Action ↓' and I wonder 'Why didn't it resonate?', I open the scatter plot. If the ranking is disrupted during the weekend category balance check, I check the relevant article in the ranking.
In other words, the panels are 'tools to dig deeper when you are curious,' not 'things to look at every day.'
What I designed was the 'decision not to look'.
Building the dashboard itself wasn't difficult. I use GitHub Actions to fetch data every night, save it to a CSV, and render it with HTML. It all runs for free.
What was difficult was deciding 'what not to look at'.
If you make everything visible, you end up looking at everything.
You end up saying, 'Oh, look at the time.' That is exactly the trap I wrote about in #53.
So, I look at one line on weekdays and the category balance on weekends. I don't look at anything else. If I want to see more, I open the deep-dive panel.
Since deciding on this distinction, the dashboard has changed from a 'viewing device' to a 'decision-making tool'.
Conclusion
Designing how to use it is harder than building it.
Related Articles:
Rinka's Word:
What have you decided not to look at?
👉 'Ohayo Kanojo' is posted every morning at 7:30 AM at @ohayo_kanojo
#GenerativeAI #AIIllustration #Programming
#PersonalDevelopment #DevelopmentDiary #Record #RealExperience #MorningRoutine
#AIUtilization #Observation #Diary