Implementing SaaS is the Opposite of Human-Centred Design

I think of the world of our internal technologies in two buckets. In one bucket, we have core systems, including the SaaS products we implement, like HR, payroll, accounting, client management, and so on. In the second bucket are the automations we build between these systems and the joined-up user experiences we create around them. I call this second bucket "digital."

I find it confusing when my IT colleagues use the phrases "human-centred design" and "user-first" when they talk about package selection and implementation processes around SaaS packages. After all, if we are focused on selecting a software product and implementing it, our focus is on the product, not on the users. There is a difference between consulting users and following a user-first process.

The normal process of capturing requirements by talking to users is just consultation. Listing out the top ten must-have capabilities of a product starts by asking, "What do you need in the product?" Even though you are asking the users, the question is product-focused. A user-first process starts by sitting with users and understanding their problems in line with their current work practices. In this scenario, it's not up to the users to come up with the solution—it's up to the project team. This is genuinely user-first because we start by understanding their problems, not assuming they can translate those problems into requirements.

The only way to validate a potential solution is to put it in front of the users. There is no point in trying to achieve this with a document because humans react differently to a document than they do to a computer system. Spending time mapping a user-centric solution to existing systems or those we are considering in package selection gets in the way of the process. The same is true if we try to solve users' problems with products like low-code. It's still product-first. We spend more time thinking about the technology, which gets in the way of building the simplest thing.

In the long term, some of the digital solutions we build might end up integrating into back-end systems, but inserting those into the design process slows us down—and, in my opinion, cannot be considered, at least not cleanly, user-centric. I always separate these two into sequential phases. If there is a big capability hole in the organisation because there is no client management system, then we need to do package selection in the traditional way (well, there are some efficiency tips we can offer here). My goal in these situations is to get the package in, in its out-of-the-box form, as quickly as possible and train up the people who are going to use it. This means accepting that there are some workarounds initially. My goal here is zero customisations, for reasons I've explained in Vendor Visits and Earplugs.

Getting the package installed quickly helps us avoid the customisation trap. Once the package has settled in, I always follow up with a user-centred approach to remove those workarounds if they affect a large number of users. This process can be (must be) user-centric because it is about creating a joined-up experience—and it's the users who are having the experience, not the system. This joined-up experience is built with low-cost (open source, cloud V2, unlicensed) technologies that make use of the SaaS product's APIs, hence the importance of having rock-solid APIs.

Even when we are building these thin digital solutions around our core systems, I would first build the solution standalone, and only after this is working would I look for opportunities to hook parts of the experience into the various packages we have as core systems. This is at the heart of the Flintstones approach I use everywhere. Put another way: package selection is systems-first—buy, don't build. Everything else should be user-first—build, don't buy. That's true digital.

Delineating between these two things saves a huge amount of money in terms of package implementation and solution build because we don't mix up the two modes of project (systems-first, user-first). Our ongoing maintenance costs are also much lower because we've avoided the package customisation trap, and all of our organisation-specific intellectual property is kept away from SaaS, where it is super expensive to operate due to licensing. Whenever these two modes are combined into one initiative, they end up being a candidate for project rescue, and someone gives me a call.

Andrew Walker
Technology consulting for charities
https://www.linkedin.com/in/andrew-walker-the-impatient-futurist/

Did someone forward this email to you? Want your own subscription? Head over here and sign yourself right up!

Back issues available here.