This post was written to share a story that got me thinking about the tone or character of a web application.
It’s stuff that can feel nebulous – like talking about a web application’s vibe – but I wanted to try and hint at why we try our best to think at that level while developing software for our clients.
Computer says… no
A few years ago we worked with a training provider looking for a web application to support their sales team, help management report on their sales, and tie sales activity together with their CRM.
The directors felt they needed tighter control over how sales agents were discounting courses to customers. And more than a few times I heard the phrase “computer says no” – indicating that they wanted to impose automatic limits on agents’ behaviour. The plan was to achieve fine control over a limited set of options, within which the agents would work.
We designed and prototyped the system, and from a technical point of view, it worked well: management could tune discount parameters for each course, with rules about shopping basket value, whether specific dates were full, and so on.
Humans say no… to computer?
But when we trialled the system, agents felt that the constraints, imposed from outside their team, interfered with their process of building a relationship with their customers.
Constraints weren’t always easy to predict, because they weren’t very involved in setting them; and agents felt there was a danger of moving discussions away from customers’ career aspirations and the agent-customer relationship, towards something less personal, like booking train tickets.
Computer says… humans decide
So we simplified the discount system and modelled it differently:
Each sales agent had their own maximum discount level, which could be modified or overridden by team leaders; and agents could improve their commission rates by booking customers onto existing, nearly-full courses.
Now, agents found the discount rules predictable, and were rewarded for getting customers into the next available course; management still had a way to rein in agents who discounted too much; and the sales process was modelled more closely on the human conversation between the customer, agent and manager.
The directors still got to streamline their processes; reports showed sales went up – doubling in the year after the application was launched.
The tone of the system
The tone of the system had flipped. Rather than feeling like an opaque set of limits imposed from above, the application felt lighter, almost transparent: the limits it imposed were soft, mapping onto and influenced by discussions and relationships between people; and the blend of constraints and rewards made it feel much more positive.
…And not only for the sales team: because the application was now modelling something relatable (conversations between people), it felt friendlier to work on as a developer.
Of course, every application we build imposes some constraints on its users – if nothing else, businesses need user input that isn’t garbage. Moreover, your team structure or the nature of your business might dictate firm limits baked into the UX (user experience) of your web application: you might need the computer to say no.
But looking back on that experience, I realise we’ve made many happy design decisions by exploring whether a client really needs application-imposed limits on some aspect of user behaviour, and asking how firm and structured those limits need to be.
I’m struggling to come up with an example of a web application that isn’t, at heart, a way to help people converse – meaning that an application’s design influences how a conversation feels.
For that reason, I think it’s important to do our best to keep the underlying conversation in mind when designing an application that mediates it. We need to make sure the computer says the right thing… and knows when it should butt out.