Operating Manual for the Empathetic Craftsperson

A guide to thoughtful design, maintainable code, strong communication and data experiences that resonate

Engineer for Empathy

  1. Treat every visual and every DAX expression as a conversation with a human.

    The context might be understood now but will you or a colleague still understand it in six months time? Clarity now prevents costly confusion later. Every measure, label and visual should anticipate questions a user will ask. Assume they're smart, not psychic.

  2. Build for trust, clarity and continuity.

    Perfect numbers don't matter if nobody trusts them. A fast report is useless if it breaks when the user changes something or when you're on leave. In my experience robustness trumps accuracy and if the report breaks more often than not, you lose user engagement.

    Accuracy is the baseline but what builds trust is when your work is obvious, intuitive and stable especially when you're not around to explain it.

  3. See yourself as a translator between data and human insight.

    The dataset might be messy, contradictory or partial. Our role is to interpret that raw input into something meaningful and actionable. Translation means knowing when to simplify when to state the assumptions made and when not to show something.

    It's not dumbing down, it's being selective for the good of understanding.

  4. Talk like a teammate, not a textbook

    Although textbook speak is technically correct, the goal is to be understood and therefore to meet others at their level intellectually and contextually.

    It's not about showing off how much jargon you understand or how impressive you think you sound. Team dynamics may prevent others from asking for simpler explanations which could lead to meaning being lost. If the words cause confusion, it really doesn't matter that they were the correct technical terms.

    It's not about big words, it's about conveying meaning.

Write DAX like a UX Designer

  1. Every measure is an event. Make it clear, stable and understandable.

    Explain yourself and the logic when writing a measure, especially when it's a multi-step measure. Your future self and your colleagues will thank you.

  2. Comment generously

    If there are no comments, each and every time a developer looks at the measure, they have to spend a certain amount of energy to understand what it is doing. Avoid this additional cognitive load and time drain as much as possible by using comments in the measure to communicate what it is doing and why.

  3. Use the Description box to capture intent and meaning.

    This description box is a perfect place to record what the measure is for. The advantage of the description box is two fold:

    Firstly, the text recorded there can be exported from Power BI using the DAX INFO functions and then used as lightweight documentation for the semantic model.

    Secondly, any description added to a measure appears when hovering over a measure in the Power BI UI which speeds up future dev because it is immediately obvious what the measure is.

  4. Structure measures into folders and subfolders to prevent overwhelm and help navigation

    The number of measures in a semantic model can grow extremely quickly and two measures may look similar but differ very slightly. For these reasons, it is best to organise similar measures into folders and subfolders to help future developers find the measure they need.

  5. Avoid cleverness for its own sake - favour simple, robust solutions over clever, brittle ones.

    Often the best solutions are the simplest solution. When writing a measure to return a certain metric, my approach is to get it to work for one case. Then expand it to work for all cases and for all user interactions. Then I look at it and wonder if I can simplify the DAX somehow. Sometimes I can't and that's fine. But often I can and my future self is always grateful when re-reading a measure further down the line.

Semantic Layer

  1. Model should reflect how users think, not just how data is stored.

    Use business-friendly naming for columns and measures. Name the entities using human-understandable language rather than Factxxxx or tbl_xxx. The model should speak the language of the user, not the backend.

    Less is more, show only what's needed in the reporting layer. Hide ID and key columns, hide helper columns and intermediate tables to reduce overwhelm at the report layer.

  2. Group facts and dimensions conceptually.

    Use display folders to group similar metrics together in a way that would make sense for the user. So for example, put all Customer metrics in one place. Or all measures related to time intelligence.

  3. Use naming conventions that reflect mental models, not table joins.

    A user shouldn't have to understand the star schema to understand the model. Choose names that reflect how users talk about the business eg. use "Total Customers" rather than "Customer Count".

Visual Design

  1. Alignment

    If you do nothing else, use alignment. Where possible, align everything with everything else.

  2. Colour = Meaning

    Less is more when it comes to colour and usage should be deliberate and with purpose, not just because "it looks nice". The best use of colour is to emphasize or de-emphasize.

    Always consider accessibility (users who may have colour vision deficiencies) and so never use colour alone to stress something. Use icons, labels or position to support the message.

    Be thoughtful about saturation. Too high and the colour will hurt the users' eyes should they have to use the report for any length of time.

    Choose colours based on association - red naturally has negative connotations (risk, danger, failure) so don't use it to indicate positives (success, growth, pass rate).

  3. Whitespace

    Group and organise objects together if they are related. But don't put too many objects on a page at once. It will feel cluttered and overwhelming. Allow the report pages to breathe by making use of whitespace / negative space. This helps the user to identify objects that are related and conversely objects that are unrelated.

  4. Hierarchy and Typography

    Use font size to draw the user's attention. Titles should be big and noticeable. They should be bigger than subtitles which themselves should be bigger than normal text. Use consistent font to create a consistent report. Inconsistent font is jarring and is noticed surprising quickly by the eye.

  5. UX instruments, not cosmetics

    Design isn't about cosmetics, it's about making them functional. Every element should guide, inform or clarify. Often we're handcuffed by stakeholders' requirements but we should be asking ourselves questions like: Does this visual add value? Does the layout have a natural flow? Could a user pick up this report without needing a guided walkthrough?

    Don't over-design but do design intentionally and with purpose.

    Simpler is often better.

  6. Dark theme?

    7. I have nothing against dark themes. However my mantra here would be, much like colour, use with intentionality not just because "it looks edgy".

  7. Always test.

    8. When the design is completed or even as you go along, check that it still looks good and is robust. Click a few buttons, change a few slicers does the design stand up to this scrutiny or does something strange happen?

  8. Avoid semantic ambiguity.

    9. Be clear in labelling and be specific. Don't give the user scope for misinterpretation. For example "Last 12 Months" - is that the last 12 completed calendar months before (and excluding) the current month? Is it the last 365 days? Is it 12 months back from today?

Empathy Test Loop

Before delivering a new report or even new development on an existing report, ask:

My Toolkit