My partner and I recently traveled through Scotland for a while. This was a very special trip for us (we got engaged!), so we stayed in nicer accommodations than average, ate at a few fine dining spots, and generally sought experiences I would describe as luxurious, comfortable, and memorable.
In the process, we stayed in four hotels.
At one of the four-star accommodations, we realized that the original builders had tried so hard to do everything that many of the smaller, foundational basics were missed or underperformed. We had a huge room, gorgeous views of Edinburgh’s Old City, and beautiful finishes. However, they weren’t particularly functional. For example, the bathroom didn’t have a light switch inside at all. To use it, you first had to wander to the hotel room’s entryway, flick the switch at the front door, then walk back down the hallway to the now-lit restroom. It isn’t worth writing a full review over, but it certainly grates on the user after their fifth awkward, toilet walk of shame.
This got me thinking about how the same experience translates to the applications and data flows I build and plan day to day. Very romantic thoughts for an engagement trip, I know.
Regardless, my data and process brain cannot simply turn off. I had recently attended quarterly leadership meetings that got the gears turning in my head about how lean principles and a “minimum viable product” are sometimes the kindest thing a product developer or designer can provide to a user. By anticipating the most basic needs of our users and keeping our focus anchored there first, we can add bells and whistles far more thoughtfully, with much better results.
We work with engineers constantly and, as any engineer reading can probably relate, they like seeing their numbers. Many of our dashboards start simple, yet somehow requests for version five appear before version one is even fully out of testing. It starts with, “Well, John Doe does a special type of project and needs this different, magical unicorn calculation factored in. Just add it in between these two columns, and then build a drill-through off of it.” By the end, ten John Does have doubled the size of our initially approved project.
Six months later, somebody comes to us asking why the table is so large, with so many unnecessary data points. It’s confusing their team, and they really just want column ten moved to the front so they don’t have to scroll to it every time.
Often, the fear of leaving out an extra feature that only ten percent of users badly want outweighs our commitment to providing elegant, easy-to-parse data. The same pattern appears in luxury accommodations and restaurants under a critical eye: by trying to accommodate everybody’s one-off needs rather than doing one thing very well, they don’t become the hotel that is good at everything. They become the hotel with an okay spa, middling customer service, and rooms that aren’t quite compatible with real life. I imagine the bathroom design process went very similarly to the way dashboard design sometimes goes. Nobody meant to put the light switch outside the room, but once they’d added the walk-in shower, the soaking tub, and the wall of windows (also uncomfortable while I’m taking a bath, but that one is beside the point) there wasn’t anywhere to easily place the switch that wasn’t in violation of electrical safety codes.
We spend so long adding features to cover every edge case that we lose the ability to test every workflow to its fullest extent. Six months later, we find ourselves with a full soak tub blocking the area where the light switch is meant to be. The light switches and broadest use cases must come first. Then (and only then) can we consider the extra bells and whistles that elevate the experience from a comfortable bathroom to a luxury accommodation.
With all that being said, I think I’ve hit my yearly quota of comparing my own hard work to toilets. Here are some lovely engagement photos from our photographer, Meghan Gibson, as farewell.
Paige Cleary 