- Update December 2019
- I recently gave a talk on this at the RICS Commercial Property Conference, applying the principals covered here to designing and procuring software and mobile apps in the built world. You can find a copy of my slides here.
When did you last use a piece of business software that drove you mad? Last week? Yesterday? This morning? But did you soldier on because you had no choice?
Let’s start off by acknowledging that no one designs technology or software with the intention that people will be forced to use it. It would be nonsensical, and fairly poor business sense. However quite a few software developers fall into the trap - and we’ve all done it - of building something before they’ve really considered how and by whom it is going to be used.
So let’s start at the very beginning
For many of us, our relationship with software started with the desktop computer: a thing in a room in your house that you had to go to, switch on, boot up, and frequently refer to the manual for.
That was where software lived. And that was where it stopped. You couldn’t carry it to another room; you couldn’t fit it in your pocket. Software was a thing that you installed and used, one application at a time, and you would definitely need training for it from a professional.
You had to decide to use it.
And then came the internet
The internet changed all that. All of a sudden, you had access to software on websites which you didn’t need to install, and didn’t come with a manual either. You just had to learn and adapt. If you couldn’t learn how to use a website, you couldn’t use it. More importantly, you wouldn’t use it. Almost overnight, software had to become more accessible and more intuitive to ensure that as many people as possible could use it.
Mobile is the latest progression of that. It’s software that is not only available to everyone, but everywhere. You aren’t tied to a location or even a specific device, as software now travels with you on your phone, watch or tablet.
This brings the people vs technology challenge
How do you design software that works in these multiple environments? Can you truly design a single piece of software that works on a variety of devices, that is accessible wherever and whenever people want it, and is so intuitive that anyone can use it without needing a manual?
After all, who sits for half an hour to understand how to use an app? We’re a low-attention span generation. If we can’t understand how to use it immediately, we move on.
The B2C ecosystem understands this better than B2B
This is a crucial distinction that I've noticed. Generally speaking, when you think about B2C software, the person who buys the app is the same person who will use it. Developers building software for consumers worked out the importance of user-centred design years ago, because if they didn't recognise that their software needed to be designed around their users, to be obviously and immediately useful, people just wouldn't buy it.
I like to think of it as natural selection for apps.
But we haven't really had the same process of 'evolution' with business-focused software, and we frequently see B2B mobile apps which are bloated, clunky or even borderline unusable; being rooted in the thinking of decades-old corporate hierarchies. The mentality is often the same as the development processes of the 80's and 90's, even though we're now looking at radically different technologies, form factors and use cases.
Of course, there are different market challenges when developing for B2B users. The purchasing and development life cycles are longer, and as a result businesses have often created (or inherited) a vast landscape of software - much of which doesn’t fit modern technologies.
But fundamentally, software specified and procured by the boardroom will frequently reflect the needs and priorities of the boardroom -- which might have minimal overlap with the needs and priorities of the actual users within the business. It is our challenge as developers working in the B2B space to bring these needs and priorities together.
Testing, testing, testing
This is why testing is critical to the NIMBLE methodology. You need to force yourself to consider what someone is going to do with their mobile device. What do they actually need to do? So much corporate software has inadequate testing, or the wrong type of testing, or not enough time/budget to respond to testing before it is launched.
You've got to consider your audience before your app. When you understand your audience and the tasks they are trying to perform, the challenges that they face on a daily basis, then you can start to solve those problems or add value to their day.
Of course, it’s a chicken and egg situation. You want to put your audience before your app, but until you put your app in front of an audience, it's hard to tell if you’ve really hit the mark. It’s why we follow the repeating pattern of prototyping, testing, feedback and improvement; engaging our audience at every stage. It’s important to be flexible and respond quickly so you can optimise through this iterative approach. (Sound a whole lot like ‘Agile’? Well, kind of! But we’ve taken it a step further - read more here.)
Objectivity doesn’t need to be the opposite of creativity
No one sits in their own office and questions everything that they do. We’re too busy doing it! It’s so easy to get stuck into a routine, and we don’t consider that there might be a better way.
We’ve seen this in action when working with architects and surveyors to develop our Visual Survey Pro app. We shadowed them for a day and although they weren’t actively looking for a solution, we quickly spotted an opportunity to improve. We were confident that technology could help.
But that’s easier to do when you are objective. When it’s not your sector, you start to notice the strange habits, and you ask the questions that no one thinks to ask.
So when we started creating Visual Survey Pro, we were focused on the task that the individual was already performing, and considered how we could complement that task. Where the software stops, human interactions continue: whether it be producing a bespoke report, or getting up on a ladder and actually taking a look at something. We don’t want our software to dictate the way that a person works. Instead, we want to empower a person to do their job with excellence and without fuss.
The flexible/inflexible paradox
I’ll end with this. There is an inherent disconnect between software, which by its nature is rigid and well defined, and people who are definitely not! People are constantly changing, and what they need is constantly changing. We work hard to build software that does what it is good at, providing consistency and structure, but with enough built-in flexibility to serve the people we intend to use it. The last thing we want is for people to feel forced into using our software. For us, people come first.
If you'd like to make sure your web apps work for real people, get in touch.