How to scale internal tool to white-labeled software as a service (SaaS) ?

How to scale internal tool to white-labeled software as a service (SaaS) ?

This is a story about a custom software that begin as a internal software, but they decided to expand it to SaaS project.

Since this project was NDA, all the screens have been modified to not represent the company or project and therefore there's no connection to the client.

How did we approach this project?

Firstly they wanted to add on their platform another feature which would be interesting to clients outside of their organisation. They also wanted us to adjust a bit and for us to help them with accessibility and the UI that it looks a bit more modern. We created the new feature in the existing style, but along the way we fixed some things, the client really liked the new approach and asked us to redesign fuse screens so they can see how would the new version look like. After we did some screens, the client liked them and said that we are doing the whole design and that we take all the current screens that they have in the platform and estimate how much would it take to do a redesign.

At first, we estimated the whole redesign to around of 20 hours, but along the way came a lot new things we needed to fix which was uncovered. Only when we were able to see the whole platform broken into chunks and screens.

Prototype as a way of presentation

To be able to show this to the stakeholders and investors, we created a prototype which we had to show few different roles and how they see the platform. This was the easiest way to show all the different roles and permissions especially for easy understanding.

The internal version had a lot of usability mistakes clumsy flows and which was easy for internal users to adapt to because it was easier than the alternative: endless excel sheets, but if we want to expand us to a bigger market, we need to be sure that we don't get a lot of customer support and that we have clients that convert and love to our software.

Solving the right problem for faster results

What turned out to be the best option for the software is to firstly define what we want to solve then how would we like to solve it and how can we solve it. Getting problems from the clients who know what they struggle with us, sketching designs and taking UX and technical knowledge as our tools in solving the problem was the most effective way of solving things. When we would do this, we did the part of a feature once and all the others we always had to come back to it. So it's always easier to go step-by-step and see what problem we want to solve and combine our knowledge both clients and ours to get the best of both worlds.

Designer’s tales

What was also very interesting for me as a UX designer was creating a change log inside of Figma so we can export all the screens with the new changes and send them to the client so they can print it out. I've struggled to create frames or maybe that we group stuff, but at the end using sections that don't affect the frames and allow us to do a prototype on the same page was pretty cool.

Interested in more?
Check these ones out!

Interested in more?
Check these ones out!