A Language for Design Problems

[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!



Add Yours
  1. 1
    Dorian Taylor

    Thanks, Christina, for advancing the conversation.

    What I’ve found over my career is that going into a project, you can often choose your disposition vis à vis the problems you face. The principal of a small Web shop, for instance, might think in such concrete terms as a shopping list of Drupal modules they can adapt to a list of requirements or feature requests, so they can write it into their contract. When somebody hires me, on the other hand, it implies they’ve already chosen a strategy biased toward (though not necessarily cemented into) the family of problems you’ve labeled “new”. Part of my purpose for writing my piece was to gin up some clear language around that idea that I could use in my own dealings.

    I also mainly do infrastructure, rather than products. So a question I frequently get to ask is “does this have to be a product, or can it be a constellation of products?” Is it an intranet, or is it an agglomerate of useful tools to abridge the manual work people have to do so they can focus their attention on the things that matter?

    One of the perennial ailments of transiting to a new medium is that people try to transpose onto it the language and the idiosyncrasies of the medium that came before it. The first car looked like a horse buggy. The first movies were just plays acted out in front of a camera. This condition is particularly pernicious when it comes to anything to do with computers, because being universal machines, they are inherently chameleonic. The media of architecture, industrial design and print and record publishing entail huge quantities of capital to devote to raw materials and labour. Cooper has said this time and time again: there are no variable costs in software. To which I add, based on my own experience and watching that of others: Software, and content for that matter, is dirt-cheap to write, once you know what you want it to say.

    My chief interest these days is how the deals to procure information systems (anything from mobile apps to signage, including cross-channel service design that includes mobile apps and signage) are conceived and subsequently financed. So getting back to the deliverables thing: If your contract is to deliver an app or a website, then that app or website is the deliverable. As in your job isn’t done and you don’t get paid until you deliver it. What that represents to me is an enormous, all-or-nothing risk to everybody involved, that imposes a process that is, even though parts of it may be Agile, still rife with arbitrary structure and CYA. I started doing something different because after half a lifetime of working with the media of software and the web, I finally took a hard look at it, and fail to see why we have to organize in the conventional way.

    Considering the more ephemeral stuff like service design is pretty nascent, I’m really curious to see how the deals around it are structured. What seems to be emphatically clear to me though is that it might pay for businesses to consider the acquisition of information systems as an operating expense, rather than a capital one.

  2. 2
    Dave Malouf

    Hi Christina, I generally like this.
    I know you are concentrating on software product design, but I’m wondering where do you think what Buchanan has called “Wicked Problems” fit into this. More simply we could say that the it is a problem where you are a part of a greater whole. Your part may be for software product, but it’s success is contingent on interrelationship to an eco-system some of which has direct collaborators and some are outliers beyond your control.

    Another type of problem I think slightly askew to your last one which is “Disruptive”. The amount of cultural change required to gain acceptance is great, which changes the way you have to go about it. The total context is important towards its delivery and parsing it out in small chunks gains you little useful feedback bc the whole of the product is the only way to represent the amount of cultural disruption out there.

    And yes, I’d love to be on a panel about this. Right up my alley in many ways.

  3. 3
    Austin Govella

    Feels like you’re conflating the problems and the solution. I’ve often seen it with the two separate (known problem, unknown solution). I like your classification better, but that leaves out an important option:

    Understood problems: unknown solution
    Maybe that really means you don;t understand the problem and you need more understanding so you can class it against understood or unsolved problems.

    And I think Dorian’s post conflated documentation with solving the problem. One has nothing to do with the other, in my opinion. I’ll re-read and post a comment there.

  4. 4
    Austin Govella

    …and no comments on Dorian;s blog, so I post here and snark on Twitter:

    Deliverables are communication tools. You are communicating something to the client. That may or may not be a problem you are solving.

    The real question is who am I talking to and what do they need me to communicate to them. Followed closely by what idea do you want to change in their head. The answer to none of these questions is limited to solving a problem for a client.

    If you only ever communicate problem solutions in your deliverables, then you’re refusing to answer the first two most important questions: who am I talking to and what do they need me to communicate.

  5. 5
    Dorian Taylor

    I don’t host comments; sorry for the inconvenience.

    Once again the definition of “deliverable” I’m using, or at least one facet thereof, is an artifact that acts as the content of one side of a commercial transaction (the other typically being money). So, once again, if your obligation in a contract is to deliver a website, the website is a deliverable (among many).

    As such I am implying no more in my use of the term “deliverable” than “that which is (to be) delivered”. Am I using the word wrong?

    Let me try to unpack this a bit. My overarching purpose is to look at alternative ways to strike deals around the acquisition of information artifacts, defined as anything that would be wrong if it said or did the wrong thing. These artifacts tend to be conceived and rendered as digital data, and as such the cost structure and risks around acquiring them are not governed by the costs of raw materials or rote labour, but rather that of gathering, concentrating, synthesizing and representing precursor information. The reason why I am interested in looking at alternative modes of exchange and financing of such artifacts is because I observe that these costs are inherently unknowable.

    While the cost of gathering, concentrating, synthesizing and representing a specific piece of information is unknowable, the costs of these operations in general is not. In fact, it has never been cheaper. This realization is what led me to consider alternate ways to do deals around these kinds of artifacts.

    What if, then, instead of striking a deal to deliver a complex artifact like a website, framed as a discrete capital investment, the deal was to deliver continual installments of simple artifacts that combine together over time, framed as an operating expense? That way, both actors in the transaction could ensure that they are getting value on an incremental basis, without the need for the risk exposure associated with a monolithic capital investment.

    At this point the problem becomes, how do we answer the client’s question of “what did I get for my money?” It occurs to me here that what is needed is some way of connecting the simple artifact, which may be many degrees removed from the client’s goals, to the bigger picture. That’s something I’ve been working on, which is what inspired me to write the original article.

  6. 6
    Dave Malouf

    Hi Dorian,
    There is a premise in your comment above that I’m not sure I agree w/. That the creation of the web site itself as a final deliverable can be priced any more accurately than the price of the amalgamation of artifacts (whether delivered to the client or not is irrelevant) that lead up to said web site.

    It also assumes that you, or your team are the only arbiters of the finality of the final “deliverable” and not collaborating on a broader team, such as corporate IT, Marketing, or even external partners such as Brand Consultants, or software service agents for enterprise software.

    This is moving WAY beyond what Cristina is talking about here so I won’t go further, but there are a ton of assumptions in your theory of what is a “final deliverable” let alone the value of intermediate deliverables as gatekeepers as part of the overall pricing structure.

    The risks of any fixed bid will always fall squarely on the consultant/agent and as a project grows in size the level of all uncertainty grows not geometrically but exponentially.

    — dave

Comments are closed.