The Toilet Method for Product & UX Design
Here’s my secret trick to product ideation. It applies equally well if you have a technically superior system that needs a bit of “UI/UX magic”.
For any problem we want to solve, I ask:
- What would the simplest solution look like, for the user?
- What would the best solution look like, technically?
Then we marry the two: the user should experience the simplest solution in the interface and interactions, and under the hood, it should be implemented as the best solution, with the “glue” in between as necessary for the simplest solution’s interface to power the best solution’s engine.
Think of the toilet. The easiest solution for the user is a simple button to flush. The best solution, technically, would avoid the need for pumps and power, instead using a siphon. The glue is everything in between: when you push a lever, it pulls a chain that lifts a stopper filled with air, so that it then floats on top of the water until the tank drains, causing the bowl to fill, triggering the siphon like a Pythagorean cup, flushing the toilet without pumps or power. All from the push of a lever. The toilet is actually a genius piece of work.
This is how we think of everything we’ve made at Mindsense: Mail Pilot, Throttle, and a few forthcoming projects. Here’s an example.
With Throttle, we were trying to figure out how to identify newsletters or mass-mailings in your inbox. We do this in Mail Pilot, but it has always bothered me that it’s not air-tight. Even the best algorithm can’t be. So we brainstormed, and went down two threads.
The simplest solution.
First, I said it would be ideal, for me as the user, to just click a button next to all newsletter signup fields that could pop up part of an app that would allow me to tell it that what I’m signing up for is a newsletter. Sort of like an authorize button you might use on websites to sign in with Twitter or authorize a 3rd party website to have access to your Facebook or GitHub data. Just a dead-simple, drop-in authorize button. Technically, however, we knew that wasn’t possible. That’s just not how email works. Once you give someone your email address, anyone can send to it, not just that domain. So it still wasn’t air-tight. Not a win.
The best solution.
And then it hit us — the best technical solution would be if you gave every sender a different email address. This way, you could segment out their emails from your inbox and collapse them into a daily digest, you could shut down any specific sender’s access to your inbox as needed by turning off their unique email address, and you could see if someone stole or sold your email address. In terms of UX, however, generating a new email every time they want to sign up for something isn’t feasible.
The former is the simplest solution, the latter is the best solution. Neither are winning solutions, because the former isn’t technically possible and the latter would be unusable for people.
The Magic.
How do you marry the two? It hit us pretty quickly. All we had to do was put an authorize button in all email fields that would generate a random email address and fill it into the email field. This is the glue. You get the UX of the simplest solution — just click an authorize button in the form. And you get the best solution under the hood — every sender has a different email address, so you get all of those benefits.
Would we have to contact all publishers? Would we have to get MailChimp on board, etc.? Nope: we could just build a browser extension to detect those fields and add a button to them.
The marriage of the two is a winning solution, and we knew it when we were sitting on it. We just didn’t know how much. When we talked about it with others we quickly found out just how much this solution would mean to people. So we zeroed in on the idea, and worked it from idea to launch in a matter of months. It’s actually such a winning solution that since originally writing this article, it has become one of the top launches on Product Hunt of all time.
Here’s why this process works: it ensures that you end up with a technically superior system, as measured by whatever metrics matter most for that product. It’s cross-compatible, or it’s air-tight, or it’s not a resource hog, etc. You end up with a technically superior system given what is technically important.
Second, it ensures you also end up with the easiest solution for the user to get on board with; one that is not bogged down by major technical complications, and that’s not dragged away from being ideal by either a compromised solution or a solution that ignores the user entirely.
This method isn’t easy, because you have to have the creativity to come up with “the magic” or the “glue code” that binds together the interface of the simplest solution with the technical underpinnings of the best solution. With Mail Pilot, that involved figuring out how to get our advanced functionality to work on a standard, old IMAP server. With Throttle, that involved the browser extension, generating lots of unique email addresses, and building our own email server.
If you use this method to come up with anything, I would absolutely love to hear about it. If for nothing else, I’d love to cite it as an example, or at least just find out how it’s doing for you.
Happy innovating. And if you didn’t catch Part 1 of this series, read on:
