What will UX look like with the current SaaS & micro-SaaS Cambrian explosion?

Doğa Armangil
3 replies
The average employee was using 11 applications even before the micro-SaaS phenomenon. Nowadays SaaS vendors are offering an ever-growing number of ever more specialised applications. 𝗧𝗵𝗲 𝗾𝘂𝗲𝘀𝘁𝗶𝗼𝗻 𝗶𝘀 𝘁𝗵𝗶𝘀: Would employees be content with juggling between too many applications, or would they prefer using only one application that fits their role and their line of work?

Replies

Nitesh Jamod
With the SaaS and micro-SaaS explosion, UX will focus on hyper-specialisation, simplicity, and seamless integrations, prioritising personalised, intuitive experiences that cater to specific user needs while maintaining scalability and flexibility.
Share
Doğa Armangil
@nitesh_jamod I agree with you that UX will/should focus on seamless integrations, but which integration technology will enable seamless UX? To me a core feature is 𝗰𝗼𝗺𝗽𝗼𝘀𝗮𝗯𝗶𝗹𝗶𝘁𝘆, and by that I mean a SaaS application must be able to call another SaaS application which must be able call another SaaS application etc. So let's look at how composable the current integration technologies are: * 𝗥𝗘𝗦𝗧, 𝗚𝗿𝗮𝗽𝗵𝗤𝗟, 𝗝𝗦𝗢𝗡-𝗥𝗣𝗖 𝗮𝗻𝗱 𝗼𝘁𝗵𝗲𝗿 𝘄𝗲𝗯 𝗔𝗣𝗜 𝘁𝗲𝗰𝗵𝗻𝗼𝗹𝗼𝗴𝗶𝗲𝘀 𝗮𝗿𝗲 𝗻𝗼𝘁 𝗰𝗼𝗺𝗽𝗼𝘀𝗮𝗯𝗹𝗲. Why? Because when a REST API calls another REST API behind the scenes, then how do you authenticate the end-user? Also, composing these APIs brings with it the risk of network timeouts, because you never know how long an API call will take. I was even able to obtain a software patent from the USPTO on that last point. * 𝗠𝗶𝗰𝗿𝗼-𝗳𝗿𝗼𝗻𝘁𝗲𝗻𝗱𝘀 𝗵𝗮𝘃𝗲 𝘃𝗲𝗿𝘆 𝗹𝗶𝗺𝗶𝘁𝗲𝗱 𝗰𝗼𝗺𝗽𝗼𝘀𝗮𝗯𝗶𝗹𝗶𝘁𝘆. Micro-frontends typically cannot be nested beyond 0-2 levels at most, because the screen real estate that is allocated to each micro-frontend diminishes significantly with each nesting level. * 𝗧𝗵𝗲 𝗠𝗔𝗖𝗛 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 𝗶𝘀 𝗻𝗼𝘁 𝗰𝗼𝗺𝗽𝗼𝘀𝗮𝗯𝗹𝗲. In this architecture that is used for consumer applications, there is only one web frontend (typically a single-page application) and many SaaS/API backends, and all integration happens through the frontend. This means that a SaaS or API cannot decide by itself to call another SaaS or API, it must wait for the frontend to approve and implement the integration on its behalf. To my knowledge 𝗤𝘄𝗼𝗿𝘂𝗺 𝗶𝘀 𝘁𝗵𝗲 𝗼𝗻𝗹𝘆 𝗶𝗻𝘁𝗲𝗴𝗿𝗮𝘁𝗶𝗼𝗻 𝘁𝗲𝗰𝗵𝗻𝗼𝗹𝗼𝗴𝘆 𝘁𝗵𝗮𝘁 𝗼𝗳𝗳𝗲𝗿𝘀 𝗳𝘂𝗹𝗹 𝗰𝗼𝗺𝗽𝗼𝘀𝗮𝗯𝗶𝗹𝗶𝘁𝘆, and this makes Qworum a technology supplier to consider when developing any sort of web application. Do be aware though that Qworum requires a browser extension to be installed, and that's why I am currently targeting the business applications space. Feel free to give Qworum a whirl, local development is free, and for this Product Hunt launch I am offering 3 months free on the paid subscription.
Share