And after you define your default use case, you must make sure it is the most obvious and easy thing to do. Yes, this sounds like a very obvious and universal thing, but many products fail to recognize that.
Here are a few examples of products that do it right:
- The default use case of google is searching. They make it pretty obvious – you have one text box and one button (well, two actually). It is the most straightforward thing to do with their interface. Of course that is not the only thing that you can do – you can customize your search, customize your language, you can advertise or visit their side-projects. But all these are options at the side of the screen. The default use case has all the focus
- The default use case of Amazon is purchasing. Do they make it obvious? Yes – you pick your items and you click the 1-click checkout button. Extremely simple. And the most obvious thing to do. Of course you can customize all the steps in your purchase, you can be a seller yourself or you can write reviews to items, but these are “side-options” that are available if you look for them. But you immediately see the default use case, and it is the easiest thing to do on the site
- With the Java collections framework you have two main steps of usage: fill the collection and then iterate the collection. Every novice programmer can create an ArrayList, fill it and then print its elements. And for many things this is all you do with a collection. Is it simple to do? Sure – collection.add() and the for-each loop. Are there other useful features? Tons of them. Synchronization, read-only views, search, different collection semantics, etc. But these options are usually not needed, so they are not part of the Collection interface, and they are not the first thing you learn about collections.
To prove that this is not obvious, let me give two examples of products not focusing on their default use case:
- The other day I wanted to buy a ticket for a concert. The site that sold the tickets had 10 steps for purchasing a ticket, some of which included clicking on one of several links within a free text. The other links showed you more details about the concert hall, the price class of the ticket, and other information that is not required for the default use case. Which could be brought down to three steps – select the event, select a seat, pay. I bet they are losing tons of clients because they get lost in the UI. Because the site owners didn’t focus on their default use case at all.
- The Java DOM API. This is a good example by Joshua Bloch. What would you normally want to do with a DOM API? 1. Parse documents and store them in memory 2. Create documents in memory and write them. How to do the latter? Here is how. You need a Transformer factory, a transformer, and two adapters – a DOMSource and a StreamResult. This is the least straightforward thing to do, and I won’t tell you how much time I had to spend to write that snippet of code. The API should have instead provided that “printDocument(..)” method.
It sounds simple, but it is very easy to overlook this important detail, and make a product that is tedious to use. So before you start, define your default use-case(s). And constantly verify that you are on track. This is for product managers, architects, project owners.
Am I telling the obvious? Yes, but note the generalization of “products”. Anything has a default use case – not only software. Even a cafeteria has it, and if you have to go through 6 steps to order a simple coffee, they will probably lose you as a customer. So whatever you do, be sure to focus on your default use case.
Reference: The Default Use Case from our JCG partner Bozhidar Bozhanov at the Bozho’s tech blog.
