The Interface Is the Product
Note: This is one of those posts you write just to unravel what’s in your head. Nothing definitive.
Musing #1, or why interfaces matter
As far as the customer is concerned, the interface is the product.
Wrote Jef Raskin, the originator of the Macintosh project and author of The Humane Interface, published in 2001. It was true from the point of view of Raskin, because for Apple, their OS was the product.
But in 2001 it was less true for say a bank, whose website was just a channel (and a tiny one) to access their range of products and services.
This has changed. Tom Greever makes the observation that “web and mobile interfaces have transitioned from being only platforms for products to being the products themselves.”
He writes that for many businesses, a website was something that originated in the IT department. If a user did not know how to use something, you educated them. Does a password require a complex combination of characters? Just add messaging that lists all the requirements.
But, now in 2019, starting a decade ago with access to smartphones and data, websites and apps have changed from being a thing to the thing. The interface (or to use the loaded word ‘UX’) for solving user and business problems did not matter as much before, but it does now.
Even if your own business has not hit that transition where you app or website is the thing, customer expectations have been raised. As Jakob Nielsen says
Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know.
Through some form of social learning, the minimum bar for what customers and users find acceptable has risen. In short if your sign up form is stuck in the 90s, you’ve got a problem baby.
Musing #2, the interface is the culmination of all prior work
There are many ways of visualizing a sequence of problem solving actions, but a good one is the “double diamond” by Design Council UK
The ‘diamond’ shape is just to signify that you need to first “diverge” or generate a bunch of things and then “converge” or pick one thing (or a synthesis of things).
This process though is not visible to a customer, all they experience is the end product. Like Raskin said, for the customer the interface is the product.
This is what I mean when I say that the interface is the culmination of all prior work, so it is important that This also means that an insight found during discovery would translate to the interface.
Musing #3, on how this works in organizations
In the few organizations I have worked with in India, the work is divided like so, with transition boundaries denoted by some kind of a deliverable (a requirements document, a wireframe), and the overall process facilitated through all team meetings.
The PM also sherpas the process all the way through. So they become responsible for getting an insight to the interface.
Musing #4, the design gap in PM (in India)
In my experience in India, many folks that get moved to a “product” role have woefully limited experience in actual interface design. Their past skillset is often software development engineering with an MBA. To be fair, I am not asking for a design degree, just whatever you have spend your 10000 hours on.
This causes two issues:
- It limits their ability to generate nuanced interface ideas. Many PMs just pick obvious answers, or choose whatever is doing. This is the “synthesis” gap.
- It limits their ability to critique the interface ideas they receive back from the designer. This is the “craft” gap.
And so if this scenario plays out, you get some bad interfaces.