Starting a Product from Scratch

The decisions you make in the beginning of a product determine a large portion of the headaches you will feel for the next several years.  The first month can make a huge difference.  (Think butterfly effect)  Here are my key tasks to do to when you look at the UX of a new product.

  1. Understand the scope of the product vision.  Products have visionaries.  You have to understand what these big brains (product manager, CEO, whomever) envision several years down the road.  How big will the product be?  What are the kinds of things its going to do?  You can not possibly plan the UX without this.  It leads to the next big item…
  2. Information Architecture. More than any single task, this is the one that you need to do well.  If you organize your thinking properly, the product will scale.  The worst thing in a product is realizing you need to re-arrange EVERYTHING to scale the product.  It throws users into havoc.  With a good IA, you are set to start building.
  3. Client-side framework. Choosing your client-side framework has enormous implications.  You don’t want to switch this willy-nilly.  The amount of effort to build a new feature is directly linked this technology.  For the last three years, I have used and loved ExtJS.  For the next several years, I am going to be working on a Flex product.  I can already imagine the kinds of things I will need to adjust to.  Key thought: You are not in the business of making modal dialogs work.  You are making a application.  Focus on what you are good at and outsource the rest.
  4. Component Library.  How should a scrollbar work?  Should the wheel on the mouse work?  How should it look?  How fast does it scroll?  These are key questions about the interaction design.  Now multiply that by all of the UI components.  You should spend a few weeks designing how those should work.  This is a living library, in the sense that it will need to be updated.  Having a library like this will ensure that engineers don’t go cowboy on you and invent some new kind of toolbar.  Engineering should make these patterns in code as reusable objects.
  5. Usage Library (Pattern Library).  How should a user choose one of many items?  It’s not always obvious what the answer is.  How should the user choose several of many items?  By designing the answer to these questions you can create a toolbox of user interface that the product manager or designer could use when describing a feature.  It’s a common language that everyone can get behind.  It means that engineer can reuse these patterns in many places making maintenance much easier.
  6. Common Wisdom Library.  Modals on top of modals are lame.  Feedback should be immediate on user input.  “Please wait” messages should be very consistent across the application.  These are some of the common wisdom that needs to be documented.  They are like “values” you can use to make decisions with.  Having clear guidelines don’t solve every problem, but they go a long way.

These are the big ones.  Everything on the list evolves over time, but the simple fact of having these at all will create a culture of consistency and attention to detail.  Plus it will get everyone on the “reusable pattern” bandwagon which is the most important aspect of all.

Glen’s Product Law #12: Pain of maintenance in later stages of a product is inversely proportional to the amount of reusable objects used.

One reply on “Starting a Product from Scratch”

Thanks for the insight Glen. We were discussing our product redesign project which is going to commence when I get back from BOS in a couple of weeks. I’ll definitely be asking my dev guys to read this post prior to our planning meetings.

Whatya think?