I often come across users who tell me they just have to have something in the software I am designing for them: some data or a report or an export. When I ask them how they use this requested item, or why they need it, they usually answer that they just have to have it. Sometimes, they even try to justify the request using the excuse that they have always had it, so they should continue to have it.
I’m sorry, but that is not a good enough reason to spend time and money.
The thing is, if you have to have it, whatever it is, then it must be useful to you, serve a purpose and be used in another process or decision. So if it is useful, then it should be also be easy to explain it’s uses and purposes. But if a user has to have it just to have it, well, that implies it’s not useful, and there is no explanation why it is needed.
It often takes an outsider’s mind like mine asking odd questions about why users need something that they obviously need or how users use something they have always used before folks start to think about what they do, why they do it and how they use it. When I get unsatisfactory answers to these questions, often an “I don’t know” or more commonly “Because we always have”, I usually decline to create the requested data, report or export. And, of course, I say why. I don’t know how it is used or where else it is needed, so I cannot design or execute it properly.
The first few times I say no to a have to have because they have to have it feature, people get frustrated and angry. Who is this outsider, this tech nerd, to question the need and the process that has worked just fine for ages?
But eventually, folks get over it and start to think. Why did the consultant say no? What reason did he give? And they start to think about how do they really use the thing they asked for, and why did they request it, and what they did with it in the past.
In some cases. we, the developer and the user together, eventually do identify a why or a how, and the feature gets implemented. But in an equal number of cases, we realize that it was unnecessary and unused and that request can be safely omitted.
This makes for happier users and workers as they can spend more time on the productive things they should be doing to benefit the team or company. Versus just pack-ratting data they had to have for no reason. And therefore not having the time to spend on the real work.
On the other side of the coin, clients do not pay us consultants to create data, reports and exports just because they are nice to have. They are paying us to create data, reports and outputs that they can and need to use to achieve their own goals. Any hours we consultants spend working on data, reports and outputs that our clients do not need or have to have just to have is time and money wasted.
It does seem wonderful to have software that does everything you want and provides you with everything you ask for. But it is far more practical, cost effective, efficient and beneficial to have software that does and provides for everything you need. Software that eschews the production of data, reports and exports that are unnecessary, and software that discourages processes that hinder the team or overload users without any real useful business benefits.
It’s really hard, though, to identify that which you need versus that which you just have to have just to have it. Especially if the business, task or process has been in place for a long time. Using a consultant, like me, with a fresh mind and different outlook to help you think through these questions while designing your next product will result in a simpler, more focussed product. And in a more flexible, nimble, happier and productive team.
Follow the author as @hiltmon on Twitter and @hiltmon on App.Net. Mute #xpost on one.