Look and Feel in product design – Product Management

Design is not just what it looks like and feels like. Design is how it works.

– Steve Jobs

Product Design

Design is almost a favourite topic in the standard product management meetings. General UX conversations for me mostly tend to be about improving accessibility and convenience in a product. This in other words take the parlance of look and feel of a product.

Although, I agree  to the school of thought of continual improvement, I was often required to balance this with the business priorities. In the role of product manager, it usually came down to the business plan to understand which part of the product needs more boost. The most common reason for this was – As an organisation, we only have a limited resource. Unless we balance this with business priorities, things will go amiss.

This is where I think the role of a product manager is so important. The role requires almost an objective balance between customer requirements and business possibilities. In addition, we will need to balance it against the ease of creating something new which is all about resourcing.

In this post, we discuss about design for design’s sake. In particular, I would like to focus the discussion on design which is about look and feel.

What is look and feel?

Going to the very basics, I would consider look and feel as a synonym for customer experience. A customer facing role would normally identify priorities which have a direct influence on what a customer experiences.

This is particularly extremely important in B2C products. If I look at gaming designs, this is almost as important as a functional requirement for the product. However, in the B2B sector, this might take a slightly secondary stature.

However, if the product design is considering usage of a mobile phone the look and feel is synonymous with customer experience which rates its priority much higher for product management.

Look and Feel Vs Functional requirement

This is often a bone of contention. I recall many discussions where we focus the resources on.

What are the trade offs if we go for functional requirements over a look and feel?

The common answers I have made peace with are:

• Functionality defines what the customer uses. If we are able to improve the range of possibilities with a product, a secondary development would be improving how this functionality would be used.
• Agile Manifesto: This ties in very well with the concept of MVP releases in line with the agile manifesto. The concept is highly linked to minimum wastage. If we can start improving these functional or basic requirements, the next stage is about how well we use it.
• Prioritisation: Although this works very well for a new functional requirement, more challenging conversations are when we trade off look and feel improvement of an older feature vs creation of a new feature. A resolution for this mostly comes into the realm of business case to prove which trade off gives us the best resolution.

Trade Off Theories and Practices

With the many challenges these things shape into, there are a few theories which really provide a framework to balance these thoughts:

Feature Prioritisation: MOSCOW Principle

In this scenario, I would like to bring the thoughts back to MOSCOW principle for feature prioritisation. What are the main functions we focus on – The Must Have, Should Have, Could Have and Won’t have tend to balance some of these discussions extremely well.

RICE Methodology

This is one of the most basic aspects. The weighted mechanism of scoring features offers a layer of objectivity to majority of discussions. It has often worked as a great tool to bring priorities of product development into perspective.

The difficulty with product management is in balancing views from different departments in a company. There have been instances where a strong sales team can define new feature requirements as opposed to bug fixes which form the customer centre team. In such scenarios, a RICE scoring mechanism clearly gives us an indicator as to which feature can make the roadmap.

Satisfiers Vs Dissatisfiers

This has worked as a guiding beacon for me. Look and feel most of the times seem to take a secondary state when I look at product enhancements. The question I do often ask is – Is this something which will disappoint our existing customer?

A requirement of product management is that we cannot give a special preference to one single customer. Although I agree with the pareto principle that 80% business comes from 20%/customers, I still think a product is more about fulfilling the need of the wide customer base.

Even with all the above, I still feel that the role of product management is key in balancing these priorities. If we weigh the look and feel requirements in relation to the above principles, they might show themselves in a different limelight. Maybe a level of comfort is in looking at a lovely quote from Steve Jobs as I open this discussion for some wonderful comments and thoughts from you:

Design is not just what it looks like and feels like. Design is how it works.

Steve Jobs