Was working today on a decision tool to help sales people sort out a complicated series of customer and technical requirements and limitations in order to determine an appropriate sales recommendation along with potential risks/costs for pricing and potential future “upsell” opportunities. There is a granular batch of information and, depending on the customer’s current situation, certain things would be factors influencing the decisions but none led you directly to a solution. Rather, it is more like each piece of information added a little weight to the balance and you probably wouldn’t know which way the balance will finally swing until the end of the decision process. And, even when you know the decision, there would be a bunch of  “qualifiers” to be addressed. “You could do ‘A,’ but then you would also have to do ‘B.’ Or, you could do ‘C’ but then you would be limited later…If you still do ‘A’ include extra costs for…”

I was reminded of how difficult but important it is to produce a clean, straightforward result. For one thing, salespeople are notoriously impatient. They don’t like complex “if-then” strings that go on forever. So, if you want people to use the tool, it has to be intuitive and pretty quick to generate an answer. The other issue is context. When will they use this tool? Sitting with the customer? Taking a tour of the customers’ facilities? At their desk after the visit? Or even just as part of their preparation? These factors all influence the tool structure, format, and platform (that is, how it is delivered).

One thing that affects ease of use is a clear structure. Can someone tell where the information they are looking for would be? Format matters here too — on each screen, you really need to know where to look, you need to be able to anticipate what you will find on the next screen when you click a link. And, with all the details, we needed to make it clear what information was important and what only might be useful in some situations.

Building the initial version, the team found ourselves jumping back and forth from the overview level (to make sure it works in the performance setting) to very specific details (to make sure it is correct). Essentially, we were zooming back and forth between concept definition and partial prototyping until we found a structure that would work. Fun and frustrating to facilitate (and probably frustrating to participate!). This type of work is really better done individually but that wasn’t an option in this case.

Ultimately, the key is to find the important factors driving a given decision. Often, your first impression is that there are a large number of things to think about but usually, after a closer look, you can find one or two things that merit the lion’s share of the attention.

If you start feeling resistance from technical experts implying that “it’s not that easy” but nobody can find an error, you are getting pretty close. Experts tend to prefer focusing on the “non-standard” while practitioners prefer getting the rules that work reasonably well in most situations. Effective design of tools and information for end users has to find the balance in that tension.

Leave a Reply