Software to Help Users Think

What does software do for us?  Roughly speaking, it fits into two categories:

1. Automates doing something (editing a document, doing the math on a spreadsheet, sending pictures to your friends, talking on the telephone, obtaining a customer’s payment for a product on a web site)
2. Helps us to think about something (deciding whether you’re looking at a man or a street sign, creating a Net Zero policy for your organization, deciding when to plant a crop, choosing the right price for your product)

The software industry is pretty good at #1: to build good “doing” software, it’s helpful to think about how people do the task today, and how the software will change how they’ll do the task.  Today, lots of software is so easy that even school children and grandfathers can use it.

We’re not so good at #2: creating useful “thinking” software systems. 

I’ve seen time and again people who are experts in data, decisions, machine learning, and similar technology ignoring the mental models of their users.  Like the “waterfall” software systems of the past, they throw data, “insights” and “answers” “over the wall”, hoping that they’ll be useful, but without a way to be sure. And the non-technologists are saying “no thank you, please bring me something I can use.”

To build good “thinking” software, it’s essential to understand how people think about the task today, and how the software will help.  If you’re not doing this, you’re missing the mark. 

So here’s a question for you: does the software system you’re building help people to “do”, or to think, or both? 

And if it helps them to think, then do you understand how they think today? Do you know what’s natural to them?  Are you asking them to learn to think in an entirely different way, just to use your system?  Or have you learned – like the great “doing” software designers of the last century – that it’s your job to start with the user, to meet them where they’re at?

The good news is that, if your users are using your system to make decisions, then this isn’t hard.  Start by understanding their outcomes, then their actions, then draw a causal decision diagram (CDD).  It will act as a “blueprint”, keeping your technology project in sync with your users, and showing them where your tech fits into how they think. Learn more >>