As to point #1: Principal goals trump end user goals.

First – I’ll say “not always” – a few companies that I’ve worked with have user-centric-design as a driver of how they deliver software. In those cases, circling back with principals to highlight the conflict can lead to adaptation of the principal’s goals (or priorities for the goals).

Second – I’ll say that you’re almost always right. Most of the companies I’ve worked with treat users as “little people” – I’m reminded of Mel Brooks’ History of the World, Part 1, where the King of France demonstrates his lack of interest in the peasants. However, I see this as a great opportunity. We’ve shown conflicting goals – that are only in conflict, given an obvious or default solution.

In the example in this article, a user goal of “increase level of knowledge” is only contrasting with the principal goal of “reduce training costs” when increasing the user’s knowledge requires additional spending on training. I see this as an opportunity to encourage the solution designers to come up with an innovative way to kill two birds with one stone – thereby re-aligning the goals. Or at least reducing or removing their incompatibilities.

Imagine a call center rep working his way through a scripted “debug flowchart” as part of handling a service call. Now imagine that instead of just showing the branches at each decision point, you show live statistics of “how many people took each branch?” and “what % of users / callers have this problem?” information. A couple queries and some UI treatment, and suddenly, the monotonous flow-chart becomes an interactive learning tool. The rep gains knowledge just by doing their job.

Another possibility – debugging steps are sometimes in a sequence because they have to be, and sometimes because they simply can’t be done simultaneously. If the flow chart (for the rep) were to show when steps are in an arbitrary sequence – and the flow chart also provided statistical data, the rep could possibly “jump ahead” in the script, leveraging her knowledge to reduce the time spent on the call.

Regardless of the situation, I think the “big mismatches” are great tools for pointing out where we should reinvent solutions, or rethink problems. It ends up being a tool that helps with alignment.

When we don’t have the opportunity to reinvent the solutions, and are forced to deliver something users won’t like but principals will, we have a head’s up. And we can use that information when developing a roll-out strategy, training materials, and any messaging.

Thanks again for commenting – you hit it spot on!

1. In many cases, the principal’s interests will utterly trump that of the end users: the software will never be purchased for the end users if the principals are unsatisfied. The matrix you depict shows where there is alignment, which is good, but I’m wondering how to handle this dynamic.

2. Similarly, how might I correlate other data points? Specifically, I’m thinking about the “partner” category. If the partners are excited, they will drive substantial principal and end user enthusiasm (potentially). Three and four-dimensional matrices are probably too hard for most mortals to effectively correlate easily. :-)

Of these two, the first item concerns me more, but I mention the second because partners drive so much of the success of many software solutions, and are grossly underrepresented in many such discussions….