This is the final article in a 4-part series covering the challenges from idea validation to MVP creation, maintenance / new feature creation, and finally this article on Upgrading UI.
Kleeen Software is about to launch our 3rd generation Kleeen Authoring UI in Q1. And this isn’t a bad thing. We created a front-end, saw customers use it, learned from their real-world experience and feedback, then re-created it. As we learn and revise, we still have a shipping product. And the effort to overhaul most of the supporting parts of our product (navigation, configuration, data/visual analytics, management) can be measured in days or at worst weeks – because only the unique or custom parts require manual development.
We call this…
Disposable UI
The notion that we don’t have a deeply vested commitment to the front-ends we have built – because our value proposition is in the back-end, the systems, the services, algorithms and data. The front end is just the gateway for our customers to access our value.
And this approach has freed our company up. Why would any company want to “keep” their existing user experience, after hearing what their customers need, when they know it is lacking? Product designs that tested well, still may not work when customer data is plugged in. A workflow that worked at launch and continued after the first N features might fail at feature N+1. But the cost (time, money, people) is just too high to rebuild your UI once, twice or even three times a year.
Some, very large, companies have adopted a “similar” approach. Apple is notorious for this. How often have they taken a software product, and released a completely new user experience? It seems fairly regular. Apple mail, photos, and a host of other applications on their phones and desktops seem to have major updates every few years. But most of us aren’t Apple. But we all wish we had their resources.
This disposable UI approach isn’t accessible to most companies. But it should be. You should iterate at a micro level, learn with prototypes, and not be afraid to reboot the UI. Your older versions should be able to be “supported” with minimal effort, and you should be able to get feature parity not long after.
At its heart, this series is all about disposable UI. You should be able to validate your vision with a real UI, and not be afraid (time/money/resources) to throw it away. You should be able to make an MVP and take it to market in weeks, and not be afraid to change it up wholesale a quarter or two after (as your customer knowledge grows, and as your backend/data evolves). You should be able to maintain a product, and add new features in a day/week or two, and be 100% ok to make a better version a release later – so you can respond to customer feedback immediately without impacting your larger product plan.
In the coming months, Kleeen will be sharing a new way to design, build, validate, and maintain front-ends. Turning these exact 3 moments (validation, MVP, maintenance/new-features) into places where a change can happen in your organization, where a new type of solution can change the trajectory of your project.
And Kleeen Software can help you and your organization have disposable UI too.
Cover Image Photo by bady abbas on Unsplash
