A board is a set of widgets somebody looks at regularly. It is the surface most people meet Analytics through, and the one most likely to rot.
Building one
Widgets come from the library or are built straight into the board from the studio.
Arrangement matters more than it sounds, because a board is read in a fixed order regardless of what you intended.
The one number that matters goes top left. That position is read first, always, and everything else is compared to it.
Detail below. Breakdowns, trends and tables belong under the headline, not beside it.
Six to nine widgets. Past that people stop reading and start scanning, which is a different and much shallower activity.
Widgets that belong together
A board reads better when its widgets answer one question from several angles rather than several questions from one angle each.
The pattern that works: a headline number, the trend behind it, the breakdown that explains it, and a table of the records to act on. Four widgets, one subject, and a reader who arrives cold can follow it top to bottom.
The pattern that does not: eight unrelated numbers, each perfectly good, with no relationship between them. That is a library page, not a board.
Sharing
A board can be shared with colleagues.
Two habits make the difference between a board people use and one they open once.
Share it with a reason. A board arriving without context gets a polite look and no return visit. One sentence about what question it answers changes that.
Give it an owner. Not a creator, an owner: somebody responsible for whether it is still correct in three months. Boards without one are the reason organisations end up with forty dashboards and trust in none.
Adding a widget
Widgets reach a board two ways, and the choice matters for reuse.
From the library, when it already exists. Always look here first.
Built into the board, from the studio, when it is specific to this board's question.
A widget built into a board is still saved and still reusable, so nothing is lost either way. The habit that matters is checking the library first, because building a second copy of an existing chart is how a library becomes untrustworthy.
Scheduled delivery
A board can be delivered on a timetable rather than visited.
Daily, weekly or monthly, at an hour and minute you set. Weekly picks a weekday; monthly picks a day from the first to the twenty-eighth, which avoids the month-end problem where the thirtieth does not exist in February.
Recipients are colleagues, chosen from the staff directory, plus external email addresses where somebody outside needs it.
Formats are spreadsheet and CSV. PDF is shown and clearly labelled as unavailable rather than quietly missing, so nobody sits waiting for one.
A period travels with the delivery: the last week, month, quarter, year to date, and so on.
The timezone comes from your organisation's operating settings, so a nine o'clock delivery is nine o'clock where the business is.
When a schedule is right
When the audience will not visit. An executive who will read an email and never open a dashboard is the case this exists for.
When timing matters. A Monday morning number that informs a Monday morning meeting.
When it is wrong
When nobody has asked for it. A scheduled report nobody requested becomes a filtered email within a fortnight.
When the answer needs exploring. A delivered file cannot be drilled into. If the recipient's next question is always "why", send them the board instead.
Existing schedules can be paused, edited or deleted, and each shows when it last ran and whether that run succeeded. Worth checking occasionally: a schedule failing quietly for a month is worse than no schedule, because everybody assumes they would have heard.
Board types
A board is shaped by what it is for, and three shapes cover most of it.
A command board answers "is anything wrong right now". Few widgets, mostly single numbers, read in ten seconds and usually left open.
A review board answers "how did the period go". Trends and breakdowns, opened deliberately at a cadence.
An investigation board answers one question during one push, and should be deleted when the push ends.
Mixing them is the usual reason a board fails: a command board with trends on it is too slow to scan, and a review board with only current numbers has no context.
Boards go stale quietly
A dashboard does not break. It keeps rendering, keeps looking authoritative, and slowly stops describing the business.
The usual causes: a pipeline gained a stage, a measure was redefined, a team reorganised, or the question the board answered was settled six months ago.
None of these produce an error. All of them produce a board people glance at and quietly stop believing, which is worse than a broken one because nobody raises it.
Keeping a board alive
Review quarterly. Fifteen minutes.
Delete widgets nobody looks at. The instinct is to add; the discipline is to remove.
Check one number against its source. If the board disagrees with the operational screen, find out why before anybody makes a decision on it.
Retire the board when its question is answered. Boards made for a specific push should not outlive it.
Who should own one
Every board wants a named owner, and the right person is whoever would be embarrassed if it were wrong.
Not the person who built it, and not a committee. Somebody who uses the board to make decisions has a reason to notice when a number drifts; somebody who built it as a favour does not.
If nobody will own a board, that is a strong signal the board should not exist.
The failure to avoid
The reliable way to ruin this surface is to build a board per request.
Every board added dilutes attention across all of them, and an organisation with forty boards has no boards, because nobody knows which one is authoritative. Prefer changing an existing board to creating a new one, and prefer refusing a board to building one nobody will own.
Did this answer your question?
No, ask a person