Just something I was pondering this morning on the train in to work. A long time ago now, user researchers at Intuit realized that small business owners don’t like to think about their money in terms of “debits” and “credits,” which are the terms that bankers and other more heavily trained business people like to use. Instead, pet shop owners, professional babysitters, seasonal apple sellers, and lemonade stand peddlers prefer to think about their expenses in terms of “Money In,” and “Money Out.” This makes a whole lot of sense, right? Simply changing these words was one of the factors that turned Quickbooks into the premier accounting software package available today.
So what would you do if you were doing business analysis in a corporate office and realized that the people who do the work for which you are designing software don’t think about the work in the terms that their managers use. Do we design so that employees can make better sense of the work that they do (and will possibly enjoy more), or do we simply plop the business related jargon that the company’s MBAs have come up with?
In general, I tend to err toward the users, but I’m not as sure in this situation…what would you do?
4 responses to “What do you do when your business’s ideas don’t align with how employees think?”
Fire the MBAs.
I personally also believe that you err toward the side of the users since they are the ones who use the application; however, MBAs are the ones who pay the bills. Mix in the idea in software development that, when creating “enterprise” software, the user does not count because they have to use the app and you are basically screwed.
Although, going back to the idea that it is the MBAs that pay the bills, if you can prove that making the change will save x amount of money each year in increased productivity you can most like make a good case for going with the user instead of the MBAs. This has worked for me in the past with other problems (not software design, though).
I think you could rely on the localisation features of your implementation platform (java.util.Locale in Java, the whole ‘culture’ thing in .NET) to tie localization to an employee’s position in the org chart, rather than the language preference in the browser/desktop.
Of course, the situation you describe has a more urgent problem… a people problem (and as Gerald Weinberg says in Secrets of Consulting, there is always a people problem) in that the managers and employees have a clear disconnect in terminology that really ought to be resolved. If the two groups cannot unify their jargon then perhaps my approach above aligns with the Bolden Rule, ‘if you can’t fix it, feature it’.
This happened when the banks got on-line. In the user research I conducted with a bank, the concept of “transferring money” was that I’ve got some money in one account and I want to transfer it to another. The fact that I might want to transfer it to an account in a different bank didn’t matter. Yet for the banks “transferring funds” is something you do between accounts within that bank. To “transfer funds” to another bank is to “make a payment”. But customers didn’t get this. “If I want to move money from my HSBC account to my mothers Barclays account I’m not making a payment to her… I make payments to my credit card company. Not my mother”.
We suggested that they come up with a new vocabulary that described what the customer wanted to do. “Move money”…
The bank didn’t go with this sadly, they stuck with their terminology that alienated customers…
Interestingly Barclays have recently realigned thier language with that spoken by customers, e.g. “Hole in the wall” rather than ATM (http://www.dancingmango.com/blog/2006/11/08/if-you-were-a-bank-which-bank-would-you-be/)
Which, Josh, is a long way of saying use the language of the users.
Hmmmm, which to which I can add something about creating a ubiquitous (sp?) language. Have a glossary of terms; often different parts of the organisation refer to things in a different way, just getting a dialogue going around the vocabulary can be a good start. And always focus on simplcity and the user…
Hey Josh. Interestingly, very recent (not even published yet) thinking that i’ve been encountering in the world of corporate performance and business strategy is that the culture of a company is the main predictor of a business’s future performance – of how well they’re going to be able to execute on their strategy – and, i would add, in how effectively that strategy can change when necessary. I would say that this is in large part due to the fact that cultural factors will determine the extent to which the organization can communicate with itself, its customers, and learn and operationalize the lessons it learns from these communications.
Culture is, of course, to a large degree reliant upon a shared language. So in your example where you are designing a system for use by one set of stakeholders (as i understand your question), the req’s for which were determined by other stakeholders, one perhaps non-obvious way to ensure a good design is to do some sort of simple linguistic probe to first see how much of a linguistic (terminology, concepts, etc) disconnect there is between the key stakeholders in the project. If this disconnect is large enough, it may prove wise to propose some sort of initiative on your part to help the company – or to suggest that the company make efforts to – create a better shared language.
I am not sure how much your firm offers in this direction, but often times work in one area of a firm reveals other related areas that need work.