Designing the software “environment“

A few years ago, I worked on an application that allowed you to see walking- and bike routes in West-Flanders.

Simple enough, right? Just an app showing a route. But then we started expanding the idea. What if you could also plan these routes on a website – and what if you could print them? What about marketing the idea with a promotional website?

We worked on all of that and I thought it was a nice little ecosystem of different parts working together.

A while ago we were working on the UI design for a SaaS (software as a service), and all the ingredients of the previous project were there: promotional website, mobile app and desktop website. But since this was a more complex project, we also encountered a few new things. How will support be handled? How will new users be onboarded?

Drawing this ecosystem got a bit more complicated. Especially when we started mapping all the things that happened in other apps as well. An application doesn’t live in a vacuum. Most of the time, someone is using another app alongside yours. An onboarding process usually consists of confirming something through e-mail or through your phone (2FA ftw).

The next project got even more complicated. In this one, the difference in features between users of type A and users of type B was immense, but their interactions would sometimes meet. I will spare you the details but suffice it to say that things got complex.

In my opinion it’s important to design the full process. In a standard SaaS situation, you need to design how someone goes from a marketing site, to registering an account, to onboarding, to learning about the app, to using it, to becoming an expert.

You can easily tell whether a software project is mature just by looking at their support systems (both direct support and indirect), release logs and how they deal with updates. The quality of the software is important, but the surrounding ecosystem should be designed properly as well.