Simple User Experience : Simplicity is the ultimate sophistication

In my previous blog on product requirements documents I had highlighted the need for  developing prototypes along with other artifacts like use cases/user stories etc for driving product management activities.  I highlighted the reason why ...since requirements and user experience are intertwined . They need to be looked at from one eye to define a usable product that provides value to the end users.  Lets review this topic in detail by looking at a famous quote that is often used in our industry today. I included a non IT definition to illustrate the important of simple user experience.

• "Simplicity is the ultimate sophistication" - Steve Jobs
• The ability to simplify means to eliminate the unnecessary so that the necessary may speak - Hans Hofmann (abstract impressionist painter)

Here are the core principles for delivering a great user experience that product managers must follow and stick to it at any cost. 

• Focus on the end user and only the end user. End users interaction with the software is what should guide your requirements/design / development. Focus on a few features that would make your product usable.  Make it simple for end users to use .

• Say NO to everything that compromises the user experience. This most importantly applies to your requirements , to the features you prioritize to the downstream development code that gets into the product. This implies that you would say NO to a lot of good ideas, a lot of customer requests, feedback from the internal teams, analysts etc. But, stick to this principle...this would help you eliminate complexity in the product and adapt the 80/20 rule. 20% key features that provide 80% value.

• Provide a direct path to get the task done….a straight path is what you need.

• Don’t pile features . More features would make the product complex and unusable. Focus on a few features that are usable.  Mathew May , author of In Pursuit of Excellence ,says the best ideas have something missing and what's missing leads to a more elegant solution .  Hint : iphone, ipad ?

• Don’t just focus on how things look. Get to the next level and focus on how things actually work. A good UI does not necessarily translates into a simple user experience for the user .

• Ship with minimal documentation.  A product that is usable does not require pages and pages of manuals.  You hit the mark if you pass this test.

How can you start to implement these principles ?

I'm not straightforward to implement these principles especially with existing products with legacy customer base . But you got to start somewhere and the further you delay these decisions the more complex your product becomes. Here is a quick recommendation to help you get some discipline around it :

• Review the value proposition of your product?

• Identify why your customers buy the product?

• Understand how they use they use the product ?
• Create your customers profile (buyer, user)?  List all the tasks they do?

• Keep this profile on your desk or as the background image on your laptop/desktop?

• Keep the core principles in sight ? Always

• Review every features, request, additions to the product from this lens

What’s wrong with the Product Requirement Documents (PRDs)?

PRD is the most commonly used mechanism for product managers to describe product requirements for a release. PRDs forms the basis of requirements for both Waterfall and now even with Agile software development processes. However, there are some fundamental challenges with the PRD model and I’m sure if you take a step back and analyze the pros and cons of the PRDs...you will find commonality between your thoughts and what I have shared below.  Not sure who invented PRDs but I’m sure this person/organization didn’t have just the word document as the fundamental way to define products.  So, lets start with the challenges first :

Take Time to Write

Product Managers spend considerable amount time on the document.  During this time your product teams are in waiting mode and management is anxious to figure out what’s next. So, cycles are wasted and engineering management cannot plan for what’s next from a staffing, budget , platform perspectives until this document is firmed up.

User Experience is an after thought

This is the biggest challenge with the PRD. They are a bulleted list of requirements ...very verbose but cannot describe the user experience. User experience is the most important element of a requirement...experience does not only imply the UI. It's every touch point the user has with the product. 

Static in nature

PRDs are static documents. However, development is a dynamic process...in fact, agile development is used today to help give structure to this dynamic nature of software development. On the other hand , the most crucial document that is used for software development is static.
 

Error prone scoping Analysis

Engineer cannot actually provide the scope of the work until he really understands the requirements, gets a chance of putting a high level prototype or design document . However, we hardly give this "must needed"  time and force the engineering team to come up with the estimates to help identify the next spot on the roadmap . Thus, what you get usually are high level estimates with a significant error margin in them and off course very conservative.  PMs are still not done.  Then, the next round of discussions start around the negotiations. Give and Take...

What you ask for is not what you get ?

We all have lived through this. What is specified in the word form in the document is different then what you get? Why is this? Because requirements are subject to interpretations ...PRDs cannot capture the entire context of the requirement.

Cycles after cycles are wasted

The ping pong game between engineering and product management on requirements is a waste of time and crucial product release cycles are wasted. It causes frustration, results in lack of trust, results in throw away work. PRDs usually start with the complete wish list from a PM and ends up with what should have been there from day one prioritized as the right feature set for the release. This is a significant waste.

Cross functional teams have no clue what’s in the release

Even though PRDs exist but honestly the only teams that read it are usually the engineering staff. As a result, cross functional teams are in dark and they all wait for the final PRD and some kind of a dev milestone to understand what is in this release. So, they are in dark and cannot plan for future deliverables.

Too long to read and it changes...

Hardly a few engineers read the entire PRD which takes time and by the time you read it usually changes . Infact, the change is constant since you are going and forth from a market perspective but also adjusting based on all the discussions.

Management is left in dark

Executive team usually gets a few bullets on a power point to help illustrate what the next release would look like. These bullets form the basis of budget approvals, decisions and pretty much the “Go/No Go” decisions for the project.

Do not describe the requirements but end up describing the solutions

In order to be precise and to make sure what you ask for is what you get product managers end up identifying the solutions to the team instead of the requirements. PRDs suffer from this common problem.

Cannot be validated

There is no way to validate the PRD and the assumptions associated with the requirements. It’s not something you can put in front of the customer ans ask for feedback or lead them to discover new requirements.

This list can go on and on...but I’m sure you will find a connection between your process and these data points . On the positive front...PRDs in its true form are a useful document when you know the exact set of requirements and can clearly / very clearly articulate it and expect little to NO changes to it as you move through the release. Usually, this is true with waterfall development models or shorter releases.  This is hardly the case in the software world we live in these days. 

So, what’s the solution...

Solution lies with the startups and entrepreneurs who have built companies from scratch. This will be a topic for my next blog...but here is the hint. What do startups do differently? What do Entrepreneurs focus on initially when they have limited availability of everything ...money, cycles, resources etc?