I was in a status meeting with a senior leader a few years ago. He pointed at a screen displaying the Google search box and said “Indrani I want you to make our software look like that.” At the time, I was writing requirements for software that was far from that – in fact, the design was moving in the reverse direction towards increased complexity. Unfortunately, there wasn’t much that could be done to change direction without significant investment and advocacy.
The comment, however, has stayed with me for the last couple years. We strive to design good products – simple, usable products that improve our customer’s lives – but why is it so hard? Software teams include experts trained in understanding the user experience (us). They follow disciplined engineering processes; apply multiple tools and techniques to capture analysis and design, all of which should lead to a great product being developed. Yet, most software is overly complex and bloated with features rarely used by customers.
There are many reasons that could explain why teams develop feature-rich, complex systems at the expense of simple, usable products. Many contracts and processes measure the value of a system based on the number of requirements that are met and test cases that are passed, as opposed to whether a customer can complete a narrow, crucial job task in less time with better output. The Google search tool is incredibly feature limited – it allows the user to complete one task (key word search) but is powerful, quick, and reliable.
Another reason could be rogue developers who tack on “improvements” that look cool but don’t make a customer’s job task easier. Or even analysts who ask the customer “what do you want” and diligently record the information, but don’t take the next leap to investigate why the customer needs that feature:
· What job task can be completed with it?
· How often will they use it (is this a common job task or a rare one)?
· Who will be using it (everyone or a smaller group)?
A trickier reason may be our experiences limit us from seeing new, potentially simpler solutions. For example, if a customer mentions “intense data entry” I automatically visualize an Excel worksheet with a bunch of built-in math formulas. But, maybe there’s a different way to look at it.
The Zen master Shunryu Suzuki says “in the beginner’s mind there are many possibilities, in the expert’s mind there are few.” The first time I wrote a piece of C++ code, probably “hello world,” it seemed like a foreign alphabet with strange syntax. I had no idea of what I was doing. I came up with a few cool code snippets but mostly ended up with code that didn’t compile. I did not know where to start when fixing errors. However, over time I could better interpret obscure compiler messages and fix the problem faster. I discovered I had tendencies to make certain errors and started to watch out for them. I developed a body of knowledge through experience. I figured out some things that worked and some things that didn’t work.
As experienced IT professionals, we all have libraries of knowledge, and patterns for looking at a set of information and determining appropriate solutions. Patterns are not necessarily a bad thing – heck a tendency to drive defensively can save your life on the Beltway. But patterns can become automatic and limiting, and prevent us from seeing new possibilities. For example, when I start a project I automatically have a list in my head of must-haves – e.g., log-in screen, help features – and this list keeps growing and becoming more detailed with every experience. It’s rarely questioned. In fact, it almost seems wrong to question if a help feature is necessary…but maybe continuously questioning these assumptions can lead us to drive to down to the bare elements – what’s essential – so everything else can be thrown out and a system is designed simpler.
A beginner’s mind is uncluttered, and perceives what is essential. Given this insight, how do we return to a beginner’s mind to build uncluttered software? I am practicing listing all of my automatic must-haves and crossing items off…one by one…till a small set is left. Another thing I am doing is attempting the unthinkable like not including help features and continuing to look for other opportunities to “simplify.”
