Today I’m working with a founder who is struggling with a common problem. Their application (still running dark, please don’t ask) provides automation for data capture and evaluation for mission critical repetitive tasks.

It’s hard to get time with the people who do the work (my client understands not to ask their boss!) but time was arranged with one of the many people who do the job and will run the application. The client knew not to ask “What are your processes and workflows?” because that question makes no sense to most people. Instead, the question was “What do you do to carry out the task?”

Now, it gets interesting, because other experts must take the same set of inputs and produce the same result … but from less formal earlier sessions it’s clear that each of the experts do things differently.

Now what?

Not More Meetings Please!

An initial thought might be to gather the experts together and hold a meeting.

I’ve encountered this before, often. A U-shaped layout with 40 people who are all experts. It’s cacophony. Sure, we can do sets of smaller meetings, share results, etc., but … there is a much cheaper and faster way. And one that doesn’t cause as much grief for all involved.

Just accept the single expert’s view as “perfect” and move on.

But what if they are wrong?

Wrong in what way?

If the expert’s steps result in the proper outcome, they can’t be wrong. That’s what “proper outcome” means after all!

However, what if some other expert disagrees with something?

There’s only three possibilities:

• One of the experts is wrong — on some specific point or fact. That point can then be resolved between the experts (I’m not an expert in their domain, and my client isn’t the expert in that domain either!)
• Both are wrong — they will have to resolve it (and it’s easier for the two of them than a room full!)
• Both are right — and there are simply different ways to get the results

The case where both are right is the very case that makes holding large joint meetings so painful. But it’s also the easiest case to address and normally with low cost.

Accounting for Differences with Grace

The vast amount of time when two experts do things differently they do the same things but in different order.

This is also one of the most painful things to realize for a highly technical person. This is also one of the things most easily missed if an existing computer program is used as a requirement (hence, “don’t solve solutions”).

The world’s simplest example: teaching a toddler to put on their shoes. As they get older, “put on your shoes” is enough. When they are young, you have to help them…and because people are often on autopilot, they will first put on a shoe (say, the left) and then the right. They do a sequence.

Now, imagine a baby sitter who is there for the day. It’s time to help the kid put on their shoes, but the baby sitter is opposite-handed than the parent who normally helps, and puts on the wrong shoe first. The kid will very likely be confused or object. Because that’s not right.

Mr. Rodgers in his PBS program made it a point to carefully change from his outside clothes to his inside clothes as part of his introduction. He provided a simple routine, a part of a larger message. He enforced an ordering for the purpose of enforcing it. It wasn’t accidental. But most of the time, for professionals, that’s not what we need. We’re not his age group.

As adults, we shouldn’t care which shoe is put on first, but if we had to write directions precisely, we’d likely specify it something like this:

1. put on left shoe
2. put on right shoe

If a different expert wrote it, they might write:

1. put on right shoe
2. put on left shoe

Which is right? Both, of course!

Now, what do we do for a professional user who prefers to (an example) gather data on the family’s children in order of age descending, and another who prefers to gather data on the family’s children in order of age ascending?

Neither is inherently right or wrong. But we need to pick one, so …

And we just made the mistake. We, the developers, absolutely do not need to pick. We need to empower the experts running our software, not encumber them. Allow them to enter the children in any order they want. Allow them to see the children sorted by age ascending or descending as they choose.

This simple example is obvious, but in the real world, we normally have dependency issues that are more complex.

For instance, we need to populate an insurance application. That steps us through pages gathering data on the insured, family, cars, houses, etc. Of course, the system has to present the pages, so there’s … wait, that’s the exact same mistake.

Allow the person to see what sections are done and which aren’t, but let them choose what section to fill in next. If we don’t have to force an ordering, don’t.

Dependencies Actually Provide Mandatory Orderings

Going with the insurance example, once all the details are gathered, it goes to underwriting. That’s a dependency. Underwriting follows the earlier steps, regardless of the order of the earlier steps.

That’s the key: accidental orderings occur when the sequence doesn’t matter. Technical people tend to mandate some order which is wrong.

Intentional orderings occur because of dependencies in the problem domain itself. There must be a name and password before logging in. However, if a person (for some obscure reason) prefers to put a password in first, and then put in the name, they can always click the fields, right? And yet, I’ve hit websites where it demands a name. And then it depends a password, which is only possible after the name is entered.

Why enforce such a thing? Style? Fiat? Abuse of power?

I’ve encountered people who do UX that believe their job is to empower their customers. They impress me greatly. It’s hard to empower other people.

I’ve also dealt with UX who are constrained because someone, almost always management who will not run the software but who manages the people who will, demands absolute control in this way. This is why requirements should come from the practitioner, not the management.

Sometimes, the UX people themselves (out of I hope ignorance and not malice) make the choice to force people through the tons of screens in order. If that’s you, please quietly apologize and stop doing that!

Oddly, programming tools generally let the developer invoke things in any order. Almost like developers want to control their own view.

Graceful and Supportive

That’s why we must be graceful. Our software should be a pleasure to use. Because of what we let people do, they benefit and like it. We support them, not command them.

It’s our job to allow the freedom to succeed and to use a light touch when a mandatory dependency enters the scene. There are some — handle with care.

Notice that these decisions must be captured as part of the requirement. A programmer who is coding something won’t know that order is optional without being told. Tell a dev “You need to gather this data” and provide it in order and it’s likely a good developer will obey. A great developer might ask “Does it need to be sequential?”

Perhaps bad requirements are more the cause than bad programming for the systems that brutally treat us like cattle. Whoever is at fault…

Don’t be that person.

Keep the Light!