Applying Occam’s Razor Principle to Product Design – Lessons learned from our Project Management Software design experiences


Occam’s Razor principle by a 14th century English philosopher states that “plurality should not be posited without necessity” or “when there are multiple approaches to solving a problem just use the simplest approach”. Seems like such an obvious statement but so much of the products we build and use today totally ignore this principle. The following best practices are based on the mistakes we made and lessons learned in building a project management software application.

Applying Occam’s rule to product design and development could go something like this:

  1. Design features that are simple to use
  2. Provide just one way of performing a function
  3. Don’t oversimplify

1) Design features that are simple to use

If you can implement a feature using several design options choose the simpler one. However, for most product development teams choosing the simpler design is easier said than done.
Here’s why:

  • There is a tendency to try and build an all in one comprehensive solution

    Since a variety of internal and external stakeholders participate in the analysis phase, designers often keep adding complexity to satisfy the many parties and differing agendas involved. Therefore, often a product that was intended to automate a simple function or provide a simple service turns into a complicated device that can “do it all”, right out of a science fiction movie. 

  • Developers are naturally biased towards paying much more attention to handling extreme cases and boundary conditions at the expense of basic patterns of usage

    I have seen the negative impact of this firsthand at Tenrox. The complexity of software developed is increased by a factor of ten when developers try to cover all possible scenarios. Let me provide an example, a few years ago our R&D team redesigned Tenrox Project Workforce Management’s rate engine so that it could support a variety of cost and billing scenarios. When the new software was released, to our surprise, a few large customers with simple cost and billing rules reported significant performance issues with the new rate engine. After some analysis we discovered that these customers were using standard hourly rates, and yet the rate engine’s new design, which had absolutely nothing to do with hourly rates had been overcomplicated and slowed down a simple calculation that was working just fine before. Of course, the engineers went into emergency mode and had to come up with short and long term fixes to their overly engineered design. It takes considerable senior executive attention to reduce this bias and it is an ongoing battle in our product management and R&D teams.

  • Iterative reviews focused on what is missing complicate product design

    After working with our R&D team on several product releases over a fifteen year period we have identified this as a recurring pattern to avoid. Here is an example. We met about a year ago to redesign our software’s budgeting feature. The designers had come up with what they thought was a simple elegant solution that they claimed would address 95% of the requirements we had encountered. The meeting started on a positive note and everyone participated in the design review. A few people made suggestions of small things they thought were missing. Eventually there were many more ideas, new, even some commonly observed, usage patterns the designers had not considered. Within minutes the simple design was thrown out the window, and a complex multi headed beast of a budgeting feature design reared its ugly head. We all walked away from the meeting a little more tired, uncomfortable with the outcome. R&D ran with the feedback and put a few good developers to the development task. Six weeks later we were invited to another meeting to get a more in-depth view of the design, including some design mockups. The meeting was a disaster; the feature had become so complicated that virtually everyone agreed that the entire design should be killed. After wasting six weeks of development time, the designers went back to the drawing board and re-designed the feature from scratch. The second revision had fewer features than the initial design they proposed! But it was just the right combination of automation and ease of use. Our third design review meeting was an overwhelming success and the new budgeting interface was a hit.

2) Provide just one way of performing a function

As any product evolves, especially of the software type, we keep on adding more and more new functions. For example, in a version one, you can only create a project from the setup page. But based on customer feedback, by version 5, you can create a project while on a dashboard page, from the project manager summary page, from the customer page, while creating a portfolio… However, if you look at the products that are often viewed as amazingly simple yet effective designs such as the iPod or Google ‘s user interface the user is given very few choices of performing the same function. I had our R&D team hang pictures of the classic iPod with just five buttons in all their meeting rooms so they are constantly reminded of the importance of this bare bones “get it done” philosophy.

3) Don’t oversimplify

This is perhaps the hardest rule of all. Let me explain with an example. Developing a timesheet application seems pretty straightforward these days and is considered by most to be a simple application to buy or develop. That is until you get into the details of the varying department specific time tracking user interface and timesheet policy enforcement requirements, cost allocation, billing, leave time and overtime calculations, and approval processes that have to be accounted for and automated. Not to mention the complexities of integrating a timesheet with payroll, accounting, project management software, and CRM applications.  We are often faced with prospects who try to oversimplify such requirements, choose an under-powered product or do not make the proper investments, and pay a very heavy price when these issues resurface in the tail end of the implementation.

However, even if your product can and must handle complex functions, always focus on the most common use of a function. If you need to implement complex or boundary scenarios they can not impact the average use of the function.

In a future blog, I will apply Occam’s Razor principle to making IT investments.

Share and Enjoy:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • E-mail this story to a friend!
  • Live
  • MySpace
  • Print this article!
  • StumbleUpon
  • TwitThis
  • LinkedIn
  1. No comments yet.
(will not be published)