How is it that some software lets you accomplish just as much as competing software, all while maintaining a much simpler interface? Basecamp, by 37signals, is a great example. With just a few features—each with a simple interface—you can complete all the same tasks as more complicated project management applications.
Ryan Singer from 37signals introduced me to an idea that he calls “judo,” for radically simplifying interfaces for a particular feature.
Let me use one of Ryan’s examples to show you what I mean:
I was working on an app that was related to doing memberships, and we had the idea that we should have some kind of detailed model to track if they had been given a gift in return for their membership. If it was a gift, like let’s say it was a T-shirt, we would want to know what size they are, so that next time we give them a T-shirt, we give them the right size, and stuff like that. And the data model was getting really complicated with all these attributes, so we decided, how about instead of all that modeling we just put a text area? And then you can add additional notes any time something happens.
A single text area replaced a huge number of fields and a complicated data model. Now, it isn’t without tradeoffs, as Ryan goes on to explain:
And the upside of that is it’s really flexible, and will handle any kind of case we want. And we can build it in 10 minutes. Of course we’re not going to be able to query to see how many people have a size small shirt so that we can order the right number of small shirts, right? It’s really about the simplifying stroke, this idea of Judo, and what is the momentum of the situation, and make one simple design decision that just massively simplifies the problem.
Ryan saved three to four weeks of development time on the project by making that simple change. That sounds pretty good, right?
Judo in practice
The concept can be applied in so many ways that I want to take you through a few examples so that you can see the range of what is possible.
Gumroad, my favorite payment provider, allows pay-what-you-want pricing. When enabled, a buyer is presented with a field to enter how much they want to pay. The seller can also set a minimum price for product. So it becomes “pay any price so long as it is at least $x.”
How would you design the interface for this? Here’s one (slightly contrived) option:
The seller uses radio buttons to select the type of pricing, then has the option to select a minimum price. You could use animations to only show the minimum price if “Pay what you want” is selected. Let’s see what this could look like when you use some UI judo:
See what’s different? They just let you add a + into the price field. To let the buyer pay any price you would enter “0+” and if you want to set a minimum price just enter “20+” or whatever your minimum price is. So much better. If things need to be more clear you could add a tooltip explaining the options that only displays when the price field has :focus.
Gumroad has another simple feature that I really like. On the sales page for each product there is a line that says “You get ______” the blank is filled in with “an MP3”, “a PDF”, or whatever else you uploaded. That’s nice information to provide to the buyer, but what if the files are bundled in a zip? So then a bundle of MP3s is listed as “a ZIP.”
The Gumroad team thought of a way to unzip the package on the server and programmatically determine the contents. At least then it could return “12 MP3s” or something more descriptive. But that’s hard to do.
The “judo” solution is to make the blank a user-editable field. It defaults to what has been uploaded, but lets the seller change it inline. Sellers have customized this to say things like “12 awesome songs” or “a ZIP plus a smile.” Letting the sellers personalize the message adds a human element—and makes programming much easier.
I encounter over-complicated interfaces in my own designs quite often. A recent case was when designing the interface that allows subscribers in ConvertKit to be added to a course. At first I had this design:
But after a little thinking I was able to cut the number of elements in half (removing the checkbox) by adding a blank or no course option to the select menu:
The time tracking application Freckle has a very clean time entry form at the top of the page. The interface will let you type in your client name and will autocomplete with the most likely options. But instead of returning “no results” for a new client, it offers to create one on the spot:
That means I can track time and create a brand new client all in a single form. Pretty slick!
Fantastical for Mac allows you to enter your event details in sentence format and automatically fills in the rest of the details. So typing “Lunch on Thursday with Nathan” creates an event at noon. When you include the address, that one input field does the job of an entire form!
Ask yourself, what are the fewest interface elements that allow the user to complete this task?
Cutting too many UI elements may complicate the problem and not be the right solution, but designing the most minimal solution will show you new methods you wouldn’t have thought possible before.
If you enjoyed this article, you’ll love my book Designing Web Applications. I go into detail on many more topics that will help you design great web apps. Also included are the interviews where I got many of these ideas. You can learn from designers like Sahil Lavingia (Gumroad), Ryan Singer (37signals), and Trent Walton (Paravel).
I also have a free 30 day course on designing better web applications. Sign up below to get the first installment of the course tomorrow.
A free video course on designing with CSS3
Just let me know your email address and I'll make sure the course gets sent directly to your inbox.