Keep It Simple - But For Who?

The Mantra

Every team I've worked on, every organisation I've worked for they've had one thing in common: the belief to keep things simple.

But we need to go beyond this straightforward phrase and ask the follow up question "simple for who?"

This question poses the uncomfortable truth that some teams like to keep it simple for themselves, rather than for the product users.

Simple For The Developer

Simple in this context means keeping development effort as low as possible so that the tickets are completed in a speedy manner and velocity remains high. Little focus is given to how the user will experience the product or even what the downstream effects of these choices are. The team keep it simple for today to close the ticket quickly.

This tends to manifest itself in the following ways:

• Using only native visuals even when less intuitive.
• Adding page-level filters rather than putting the logic into the measures themselves.
• Avoiding custom visuals because of the effort to learn.
• Not actioning feedback. Taking the view that what we have already "sort of" gives what's needed.
• Writing basic "quick and dirty" code that works for now.
• Copying code from Google that seems to work, without understanding it.
• Using implicit measures
• Discounting a viable option because of an "unwritten rule" that we don't use it.
• Concluding a spike with options but no recommendations.

The reason this path is taken by teams is that it creates the appearance of velocity and efficiency. Tickets are being closed down, work is being done. These are excellent, visible metrics for management.

But this is the very definition of Technical Debt. Prioritising comfort and ease above rigour, documentation and long-term thinking leads to a fragile, hard-to-maintain codebase for future developers. More importantly it leads to a frustrating and abrasive experience for the user.

Simple For The User

The main goal is to reduce friction for the user. This is both the user of the product being developed as well as future developers who can be thought of as users of the codebase.

In both cases, the goal is to reduce cognitive load and ensure that they have a smooth, easy, efficient experience.

This can be done by implementing the following:

• Spending extra time building a custom visual which makes the insight unmissable.
• Writing explicit measures so the logic is correct "at source" and is portable and idempotent.
• Commenting code so the next developer (or your future self in 6 months' time) can understand it.
• Using the best option for the job even if there are "unwritten" rules about using it.
• Asking "why?" before building to ensure what is built actually solves the problem and doesn't become a vanity project.
• Taking the time to listen to feedback and evaluate it: What is the user actually asking for that the current solution doesn't provide?
• Once the SQL, M, DAX code is working, ask yourself if you could refactor it to make it clearer and/or more efficient.
• Concluding a spike with a decision, not just a data dump. Abdicating the recommendation is leaving the hard work for someone else.

The benefits of this approach are that it creates a durable, trustworthy and adopted data product. It builds long-term velocity.

However it looks like over-engineering and risk-averse thinking to a team focussed on short-term outputs. It requires more deep thought and time upfront.

The Trade-Off

The "simple for the dev" choice is like a short-term loan. Yes it's quicker and easier now but you end up paying interest forever in the form of user education, user support, bug fixes and misinterpreted data. Indeed in some cases you will also have to deal with user frustration and negativity.

The "simple for the user" choice is a long-term investment. It takes longer in the moment but reaps rewards forever in the form of user trust, clarity, reduced need for user support and increased user satisfaction. And user satisfaction is important because a happy user is your best marketer.

So when you hear someone say "let's keep it simple", to build the best data product your response needs to be "Are we making this simple to build or simple to use?"

The answer to this is the difference between an exceptional data product and a mediocre one.

Simplicity is a Promise

"Keep it Simple" is not an excuse to cut corners. It's a promise and it's a sign of respect to the end-user.

True simplicity is not about having fewer lines of code, it's not about using simple tools as opposed to complex ones. It's about removing as much friction as possible so the user experience is as smooth and pain-free as possible.

The most sophisticated, complex piece of engineering behind the scenes can still be described as simple if it results in a single, clear and trustworthy insight for the user.

So the next time someone tells you to "keep it simple", make sure you ask "simple for who?"