The guessing game

Building software is a massive guessing game. You hope that what you're building will help somebody solve a problem.

You don't know, though.

Until your code hits the real world, gets used by people with real needs, it's all just theoretical. Time and again I've seen this happen in my own career. I think through every possible challenge, work through the logic trees, and make something that is hopefully robust and useful.

Thankfully, from a mountain of experience and failed attempts, my gut hunch and research methods are decent, so some of what I build occasionally turns out how I hoped. But often it just doesn't.

I've run user testing sessions where we asked the participant to proceed toward a goal, then watched as they moved their cursor around for agonizing seconds, failing to find the affordance that would accomplish what we hoped. That's not on them, though. That's not the participants fault. Yes, maybe the button was blue and flashing and said "click me". But there's a million reasons why they didn't see it (maybe it looked like an ad, and we're all trained to avoid those), and it's on us to figure out how to help move them toward a solution that benefits them.

When your software finally launches, hits the real world, and gets out in public, a funny thing happens. It's not longer yours, it belongs to the crowd (if you're lucky; most things never get picked up and used to the extent we'd hope).

If you've ever walked on a school campus, you've probably run across desire paths. These are little paths in the (usually) grass that have been trodden by students over time. They're shortcuts; or just better user experiences for the kids rushing from class to class. Students need to get from one point to another, and walking across an unplanned path is the best way to get there.

Now, the people building these campus were smart. They architected everything, knew how it should be laid out, and did their best. But they couldn't know that a student rushing from one building to another might have to take a detour a specific way, and that the current paved sidewalks wouldn't support their use case. That's impossible to know.

Software is like that.

You can plan, hope for the best, and then you just have to see what happens. And it's amazing to watch products against reality. People will figure out ways to move forward, making their own desire paths; often in the most confusing (to us as the designers) way possible.

One school took a different approach to this. They planted grass across the campus, and waited to lay down the paved sidewalks. I can't remember all the details, but over time they were able to watch where the students walked, as the grass got trodden, and see what paths were actually needed. Only then did they pave over those new desire paths and match the infrastructure to the realty on the literal ground.

In my own work I'm trying to get closer to that. Put out a canvas, make sure it's stable, then see how people use it, and how it can morph and change before things start getting set into stone. Of course software is infinitely malleable, but it also tends toward rickety. It's helpful to hold to a strong foundation loosely, then be willing to change pieces on the top as feedback comes in from your users.

I love a good discussion. Often I'll debate with team members about the merits of specific directions, which user experience is best, and what affordances should go where. But at the end of the day what matters is whether the software we build is useful to the person who needs it. Sometimes those multi-hour discussion are needed to try and predict the best outcomes. But other times it's helpful to pause, ship something quick and small, and learn from the real world.

There are few mistakes you can't come back from—provided you're working on architecting a secure foundation to begin with—and quicker releases, learning in realtime, helps a product move much faster than trying to perfect it behind closed doors.

All that planning time isn't necessarily wasted. But consider if you could move some of it to later, after you've gotten tiny trials out into the field.

I'll never be a perfect guesser for what users will want, so why not just do your best and then see what happens next.