samuellevy.com

There is a problem with user interfaces. It's a user experience (UX) problem that has been largely ignored for a long, long time. The problem is that we, as software developers, designers, and general techs don't understand how to be users. It's crazy, I know. In almost every bug, issue, and time tracker that I've ever seen, the user is asked to fill in information in a way which doesn't natively make any sense to them. This is because the information we want has no actual meaning to them.

I will fall back to an old favourite - a car analogy. If you don't know how a car works, how can you tell a mechanic how serious a problem is? If a mechanic was to ask you to rate your problem from "unimportant" to "critical", you will probably get the answer wrong most of the time. This is because when you are asked that question, you aren't thinking about the importance of the problem in relation to the car, you are thinking about the importance of the problem to you.

This is the same problem that our users encounter when we ask them about how important a task is. To the user, the task is almost always important because it is what is on their mind right now. They don't generally know about the state of the project as a whole; they only know that something they need isn't working, and it's stopping them from doing their job.

This can be a hard pill to swallow because software designers (especially for these 'management' types of application) have spent a long time trying to figure out clever ways of abstracting severity, criticality and priority into simple, one-word options. They do this thinking that the world is peachy, and that if given the right tools, the users will play ball. They design nice reports which show the most vital tasks first, and give progressive weighting to everything else. And they're all beaten out in the end by having some manager manually re-assess each item, and re-assigning them.

The answer to this is often "user training", or "stricter policies", or "auto-magic management". These are all broken solutions to avoid having to face the fact that users don't share our ideals, motivations, and most importantly, perspective. This is not a problem with the users - this is a problem with us, and one we really need to fix.

So what should we do about it? First off, we should drop the ideals. No matter how elegant a solution may seem, the real world just doesn't fit neatly into a list of priorities. I'm not saying that they don't have use, but we have to understand that we're asking the wrong questions, and that's why we're getting bad data. If we change the questions even slightly, then we will start getting the data we really need rather than the data we kinda want. Take a look at how the team behind libpqxx have started to combat this exact issue.

As software developers, we have a responsibility to build software which meets the needs of the users, and which asks questions which they can actually answer. We have to stop designing systems that try to dictate how a user should work, and start building systems that accept how a user does work. This means that we have to be prepared for things to get messy, because that's how the real world is.

When I was designing MICO, I considered setting up a system where a manager could organise all of their clients - could add everyone who they expect to call, add their contact details, and set them up all nice and neat. Then I thought about what happened when I actually received calls at work. 70-80% of the clients never called; organising their contact details would be wasted effort. Of the clients who did call, most of them never actually called from the same phone number each time; they used whatever phone was conveniently close to them. Some of the clients called so infrequently that every time we did receive a call, it was from a new member of staff. Then finally, at least 30% of the calls I answered were once-off calls from people who weren't clients. They might have been contractors, or prospective new clients, or even just my bosses mother looking to pass on a message.

I abandoned the idea of having a central list of clients because it was infeasible, hard to manage, and didn't actually solve the problem. I abandoned my sense that every data point should have a unique ID, and realised that the real world is messy. I embraced that, and solve the problem in a way that's (in my opinion) better, more flexible, and more intuitive for the users. Sure, we lose some potential for optimization, some easy statistics, and there's redundant data being stored, but you know what? It works, and it works well enough that I've never received a single question about caller management. I have, on the other hand, received praise, thanks, and job offers from users who appreciate how simple it is to use the system effectively with absolutely zero training.

As developers we need to learn to let go of ideals, and start designing for the world that everyone else lives in. The solutions may be messy, but they're more effective. Accept that the users aren't the ones who need to learn our systems - our systems need to learn the users.

To clarify, this issue isn't unique to project management - it's pretty relevant all over the software world. Project management tools just tend to be among the worst offenders, and as a result tend to be one of the biggest pain-points in my role as a developer.