Product Design: Best Practices
I’ve been pondering upon whether there are any best practices or patterns, which are used in designing great products (e.g. Tesla, Kindle, AWS)? And can we templatize it?
In process of finding answers to the above question, I learned a few things. Although I’m too far from templatizing best practices, few learnings were quite logical and can be easily implemented in any product.
- Simplicity
The designer needs to be obsessed with the simplicity of the user experience. e.g. over the years, we have dashboards on cars, which show speedometer, fuel level, accelerometers, etc. Does the user really need them? Or ideally, the system should just tell him when fuel levels are below some threshold? In short provide ONLY actionable inputs.
2. Quality
Let take an example to illustrate this. Products are advancing to have near-zero downtime with cloud technologies. To secure an organization from losing billions of dollars, AWS S3 offered 99.9 availability. This promising standard roughly translated to 2 hrs of downtime in a whole year. It also required products to be written in top-notch quality to maintain almost zero downtime. Products causing outages impacting availability are just not acceptable.
Gold standards for quality are -
a. Observability —In addition to monitoring and alerting, the application state should be continuously observed for impact due to different problems faced by applications. e.g. what impact workloads have if storage space goes beyond > 90%
b. System should continue to operate at the same optimal level irrespective of workloads.
c. Near-zero outages, Near-zero errors, Near-zero performance problems, Near-zero security vulnerabilities, Near-zero upgrade times…
3. Listen to customers
Amazon coined the concept of working backward. It is somewhat similar to design thinking. The concept is to be customer-obsessed. First, write the press release for the product or new feature, evaluate how it will get perceived, then design, scope and implement.
Think broader when customers open tickets or provide any feedback. Just not focus on S1/S2/S3/S4 buckets. Every customer pain is an opportunity to improvise product multi-fold. e.g Amazon got feedback from an old lady that she is impressed with Amazon's services. But whenever a package arrives, she needs to call his grandson to open the package, as she could not open the package herself. If you look at the feedback and how courier logistics operate, it is actually common practice to use hard material to protect the content inside the package. But, Amazon thought hard about this problem and came up with multiple innovations in packaging, so that durability is maintained along with it is easy to open the package.
4. Focus more on usability and design than implementation
Traditionally engineers are more focused on implementation, estimates, and time to deliver (/deadlines). And leaders keep asking questions around similar metrics. All crap.
With technology advances like orchestration platforms (Kubernetes), ready-to-go services on the Cloud platforms, out of box performance due to cheaper and faster hardware (especially processors), development is not that complex. Developers should focus on product usability, diagnostics capabilities, and inherent security aspect of product and design products that will meet customer needs to have near-zero maintenance.
6. Product Launches
Traditionally product launches are associated with Sales and developers hate to do that job. But, if you closely observe all tech biggies' product launches, it is senior engineers, who are providing feature demo and writing marketing material. It is long back that buying decisions from customers have shifted from CEO to CTO. And CTOs depend on feedback from their developer community. So, in short, to excite customer developers community product developers should talk…
to be continued…..
