[T]here are known knowns; there are things we know that we know.
There are known unknowns; that is to say there are things that, we now know we don’t know.
But there are also unknown unknowns ie “ there are things we do not know, we don’t know.”
”United States Secretary of Defense, Donald Rumsfeld“In clear opposition to the meaning of trivial, non-trivial means: I do not know how to solve this problem completely.
Non-trivial contains dangerous unknowns. Some part of it is not yet understood, or lies outside the range of things the programmer has done before, or can quickly imagine a workable solution to. The more experienced the programmer who tells you a problem is non-trivial, the more concerned you should be.”
Charles Miller,The Fishbowl
I’ve long admired Charles Miller’s Description of how engineers rate problem difficulty, and how they deal with it. I’ve decided, after some lively tweets with Dorian Taylor to do my own strawman of what a Product DESIGN PROBLEM taxonomy would look like. I’ll keep it short, so others can add….
The goal of this taxonomy is to recognize that some design work is easier than others. This means that some design work can be easily and accurately estimated, but other kinds of problems are sufficiently complex that the designer may not be able to estimate until after so research. Finally there is a kind of design problem (the same as the start-up problem of product-market fit) that cannot be estimated, only chased.
As well, different problems take different approaches and even different people. In these days of scarce and desirable design resources, do you really want to waste the designer’s time on designing a registration form, where there many good examples a smart PM or engineer might work from?
Problem Family: Understood problems
These are problems that are fairly well understood, with existing approaches to solving them. Some of these require hiring a designer, preferably with subject-matter expertise, but many can be done by a competent design-capable PM or engineer.
Problem Type: Solved
Description: For your project, you need some standard elements, such as a shopping cart, a check out process, or an email client. because this is not the key competitive element, you want to spend as a little time as possible on it and focus on the more important parts of the business.
Approach: You will grab best practices (example), or “fast-follow” the current best design you can find. It’s usually less than a week’s worth of work, maybe a day or two unless the product is complex (i.e. email takes a long time to reverse engineer). In very small lean teams, a design-friendly product manager can do it, and no designer is necessary.
Problem Type: Reboot
Description: You are doing something that has been done a dozen times before, but your team is innovating on it in a significant way and the design needs to reflect the innovations. Sometimes the innovations just need to be surfaced in the design, sometimes they demand a complete rethink of the design. For example, reinventing email using a search approach led to gmail’s design.
Approach: Examine best practices, and do competitive analysis on both the current space and complementary spaces. Then create a design that is either a hybrid of existing solutions or a modification of them. Even with reboots, it is important to have enough familiar design elements so that the consumer can smoothly transition. Time estimates will be harder, and based on the degree of innovation. Hiring a designer is valuable.
Problem Type: Context Change
Description: “Porting” existing solutions to a new platform, i.e. web-to-ipad, or web-to-new hardware (in a car, on a medical device).
Approach: Designer must understand both the existing design and why the decisions there have been made, and the future application. This means either the designer must be given an extra one-two weeks to understand the half they don’t know, or must be partnered with an expert in the other half which may save time if there is good synergy between the two people. Or, if you are lucky, they know both. No matter what, this is never a trivial effort (with the exception of designing for a web browser on a new device.) Estimate will depend on how different the devices are, how different the user base is, and how much ramp-up time is needed for designers. Finally, if two designs are divergent, there will have to be ongoing updates for two different designs.
Problem Family: Unsolved
These require new design work unlike what can be cribbed or copied, and it is always best to hire a talented senior designer to work on these problems.
Problem Type: No-Size-Fits-All
Description: The customer base varies so widely that it is almost impossible to make an interface that suits them at all. Example: CMS. (thanks Christian for the suggestion!)
Approach: Some solutions currently existing will match your collection of disparate users, and you can adapt and improve on those. However, it is quite possible that there is none for the combination of user types you are serving, and you will have to decide if you’ll make multiple interfaces, a generic one, or an adaptive one, then design it and test with a larger number of users than are typical required. This will take a lot of time, and estimates will vary based on solution and number of customers.
Problem Type: Everything Sucks
Description: For whatever reason there are examples out there of what you are trying to build, but research shows that the customers hate what they currently use.
Approach: Treat as a new problem AND an solved one. Understand why the current product is the way it is (was it a mater of being first to market? Is it because design doesn’t matter, as in many enterprise markets?) and note whatever is important, and any good solutions in amidst the mess.
Then treat as a BlueSky/WTF problem, and design from scratch, sketching, testing, iterating with customers. Estimate: hard to do, and will be slow. You may be able to break it into sized phases that can be estimated, but some may have to be repeated until product/market fit is complete.
Problem type: Blue Sky/WTF
Description: You have never seen this before. And from some googling around, neither has anyone else.
Approach: Competitive analysis will be on any related products. Then expect to enter a rapid iterative design cycle with frequent testing with potential users. This is one of the places where hiring a talented designer or two and spending the time on a full design process will prove invaluable.
And of course, different classes of problems require different classes of documentation and deliverables, as Dorian speaks to in his post, Deliverables: Simple and complex
Now You:
More Ideas? Different organization? Smart alec comments? I’m particularly interested in how you describe, source and estimate design work where you practice your craft.
Want to make this a SXSW panel? Let me know!