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.
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.