HRTECH Product Managers: Decouple Application and UI Now. Learn from Disney!

SHARE

Screenshot 2021-03-30 at 18.51.04I think about user experiences and user interfaces a lot, but I'm not a designer.  I buy a lot of design books, cos they look good, and I read some of them so that I can make polite conversion with designers. 

UX and the HRTECH

In the market at the moment there is an almighty squabble developing over the front end. A couple of years ago I wrote about how end users need to develop a UX (user experience) strategy, and this is now playing out. Every vendor wants to "own" the user experience. Fasten your seat belts, filling in your address or adjusting your leave balance has never been so glamorous. 

At the same time, a new wave of SME HRTECH vendors have developed instagram-like UIs, making many of the enterprise products look significantly dated. This is a brutal cycle. Cool concepts emerge in consumer land, and then get quickly adopted by SME vendors, eventually the enterprise vendors almost catch up, and then the cycle starts again. The 1990's are back, and the portal is hip again. 

What do you need to build a great UI?

Some people will tell you that you need an awesome UI (user interface)  expert, with deep design skills. They are right. Others will tell you that you need the latest front end technologies to be competitive. They are, in the main, right too. Others will tell you that you need to really understand your users, and the business process. They are right too.

But what you really need to build a great UI is the ability to do so quickly. If SaaS UI demands and fashions change every 3 years or so, and it takes you 18 months to switch out the UI, your ability to innovate at a functional level is compromised.  You also can end up having some code on the new UI and some on the old, which, rather than making the new UI look good, merely serves to show how dated the old one is, and exposes your architectural inadequacies. 

To build a great UI quickly there is one fundamental requirement: A separation between the application logic and the UI.  I came across this video the other day that illustrates the power of this sort of decoupling brilliantly. Prepare to have your childhood innocence compromised. 

 

Thanks to Laughing squid for the inspiration. If you spend a few minutes on youtube you will find many other examples of how Disney creates a magical animation experience leveraging the same underlying "engine".  

 

Back to API

In software terms, it comes back to our old friend, the API. Design application functionality  with the assumption that the UI will change many times before the application does, or even that you don't build the UI, but someone else does. While building a great UI with a new application is an impressive thing, if you really want impress this cynic, do it again, a couple of years later.  So if you are just starting out, design for decoupling from day one. Make it a baseline non-functional requirement. If you have significant product already, it is never too late to start....