When I worked at GDS, I worked with a lot of people who got very specific about their language. We talked about users, not customers; user needs not requirements and clear plain english where possible.
I was never very good at this, I have a tendency to use 20 words where one will do, and I’ve never been terribly concise or consistent about my language.
But the language that we use on a daily basis really matters. Why?Because language forms the habitual furrows into which our thoughts get organised.
If I am asked to write a resource utilisation plan for my development team, I’m likely to think of my staff as fungible resources that can be re-allocated at will. If I talk about the requirements for a system, then I get focused on producing the best requirements of the system rather than asking what the users actually need from the system.
This isn’t always true, there are many gifted and talented people that I’ve met, who are perfectly capable of talking about a resource plan, meaning their staff, and keeping in mind that Karen is a member of their team with opinions, hopes and dreams and not simply a Java programmer. But the reality is that when faced with a problem, many of us try to solve it, and if the problem is phrased in a certain way, we’ll tend to solve it with a certain mental headspace.
Even worse, this becomes habit over time, so this language forms habits for us. Asking “what is the user need?” becomes a knee jerk response to someone who says the word requirements, regardless of their intention or meaning.
If you want to break yourself of this habit, then the first approach to many problems has to be to rephrase the problem. Instead of solving the problem set in front of you, ask yourself how to rephrase the question and see if that helps shift your thinking
[This blogpost is part of an attempt to blog once a day for the entirety of November (#NaBloPoMo), inspired by Terence Eden. This series of blogposts are therefore unedited and written on the day. Errors and Omissions Excepted]