
5 still relevant learnings
From designing a bunch of gadgets almost a decade ago.
I designed a health monitor, a thermostat and a home energy manager during my days as a designer at Honeywell. While these products themselves have evolved or become obsolete over the years, what I learnt in those days has stayed with me and guided my work since. Let me share those learnings with you.
The Gadgets
A health monitor that recovering patients used to measure their vitals and share those with nurses tracking their progress. A popular home thermostat adapted for commercial and industrial environments. An interactive device to manage household energy consumption.
1. Model the problem
The first time that I tried to model a design problem was when designing the home energy manager. We had narrowed down a list of features for the product.

A day went by and I struggled to convert these features into a user interface. At this point, I drew a simple diagram of what information would a user see on this device and how could she react to it.

This allowed me to have a framework to categorize product features and subsequently translate them into a user interface. I have used models in some way or the other in every significant project ever since.

2. Use Analogies
Unlike homes, multiple thermostats need to be installed at an industrial site. These thermostats need to communicate with each other to transfer settings and user actions. They also need to allow themselves to be remotely accessed. To design how this communication could materialize, I explored how motifs from analogous systems could be adapted to this system.

This exercise gave me a large number of approaches to evaluate. The final proposal was developed after studying the pros and cons of all these approaches and combining the best parts of the better fits.
3. Prototype
Whether to communicate the initial concept for home energy manager or to detail out a feature for the industrial thermostat or to field test a proposal for health monitor with end users, prototypes have been my preferred design communication partners. They have proved more effective than flow diagrams and detailed mocks.



4. Listen to ALL the users
Health monitor users were required to measure their body vitals at fixed times during the day. These numbers would be send to the nurses and health care providers to track their progress. I talked to a number of end users of health monitor and included their feedback into the product. One of their suggestions was to introduce the ability to pause a vital measurement session.
“It is really inconvenient when someone shows up at the door and I can’t open it immediately as my session is in progress.”

However as I showed the modified prototype to nurses at a later meeting, they wanted the pause button to be removed.
“We don’t want patients to feel that there is something else more important than their health.”
It was a good lesson for me to check for competing requirements before committing myself to a design change.
5. Question the findings
We had a premise for a home energy manager and conducted an elaborate field study that supported it. We then created a product and found out that people were not willing to pay for it.

Did people have problems but also simpler ways of handling them?
Did people not perceive enough ROI from our product?
Did we ask users the right questions?
Was this even a management and monitoring problem?

We should have spent more time questioning our assumptions and defining the problem.
Conclusion
A lot has changed since I designed some gadgets at Honeywell. Mobile phones are now ubiquitous, mobile apps have redefined interface design norms, we are at the cusp of an A.I. revolution, conversational assistants and voice interfaces are slowly but surely taking over as the de facto way of communicating with technology… and in all this I find learnings from my formative years as relevant today as they were 8 years ago.
