Kimler Sidebar Menu
Kimler Adventure Pages: Journal Entries
This article was a long time in coming. Over 25 years, to be exact. However, it contains much more than observations on why software fails the users for which it's supposed to be designed. It also demonstrates a method of designing blog posts. Is it "just another post" or a "completely new website"? You decide.
Programmers Cut Off Their Noses
Are users ever truly satisfied with the software they use? The answer is typically "no". We need the software. We use the software. But we often don't like it. Among the reasons: it's buggy, hard to figure out, doesn't do what we want, is overly complex, the navigation sucks, it's got a steep learning curve or it's poorly documented. Take your pick. Why does software fail the very users for whom it's supposed to be designed?
Why Software Fails
25 Years of Data
It pains me to say that I’ve been in the software industry for over 25 years, but there you go. I've worked both sides of the fence: for software companies (technical sales rep, software designer and tester) and for companies (big and small) that used the software (user support, sys admin and as a geophysicist). I’ve worked for software companies charging $100k for a license (1-seat, 1-module), as well as for open-source applications, which are free.
Although the business plans, companies, management and software were different, the divide between what users want and what software does, remains constant. Why?
Damn the Programmers
You can’t live with them and you can’t shoot them.
The archetypical programmer is a “geek” that speaks in code. They author the applications users often curse.
The problem isn’t programmers per se, but rather that users can’t program and therefore must rely on programmers to make the software. Therein lies the rub. By design, software does what programmers think it should do, rather than what users want it to do.
This creates two chasms. First, because programmers aren’t necessarily users, they often don’t know what users want, or how they use the software. Secondly, programmers code. It’s rare that they understand concepts like ‘work-flow’, ‘user experience’ and ‘user-friendly interfaces’.
A WebDesigner Depot article shows the way forward:
Never, ever, ever allow an IT guy to choose your CMS. It is a rare breed that understands both code and a friendly user interface. Whether you are a big company or a small group of freelancers, it is imperative that whoever the Mac guy is among you, sign off on anything the IT guy presents. It may be a headache, but making sure that the CMS you use has a good user interface is essential and will save you a lot of pain in the long run.
Unfortunately, it gets worse.
Where for Art Thou PM?
Software companies are often started by programmers. After initial successes, the entire management team of this growing Software Company is typically filled with – you got it - programmers.
While coding is definitely a great skill, it doesn’t translate directly to any of the other skills necessary to run a software organization (e.g., project management, leadership, marketing, communication, sales). Time and again I've seen programmers trying to fill some - or all - of these roles, usually to the detriment of the organization.
Joel Spolsky talks about Painless Functional Specifications and why program managers, whose role is to write the software specifications, are indispensable.
Don’t promote a coder to be a program manager. The skills for being a good program manager (writing clear English, diplomacy, market awareness, user empathy and good UI design) are very rarely the skills for being a good coder.
The Kitchen Sink
With every release, software tries to accomplish more. For many apps, this means adding features outside of core functionality. There are a few good programs that have been ruined by trying to do too much.
Intuit’s Quicken and many word processors are examples. After nailing down the essentials, each application tried to layer on successive improvements with each release. Sadly, these “improvements” (required for sales) often degraded original core functionality, complicated usage, introduced new bugs and diminished overall brand integrity. Quicken even began crippling features and euphemistically called it “sunsetting”, but it’s as black a marketing technique as I’ve ever seen.
Trying to accomplish tasks beyond core functionality is also done for “convenience”, but the results are usually less desirable than what can be accomplished by using a separate application – one specifically written to do that task. Feature-creep bloats an application and muddles long-established workflows. It’s not resistance to change; it’s resistance to the wrong kind of change.
Of all places where software fails, user feedback is king.
To software organizations, bug reports are annoying and time-consuming. When a user takes the time to fill out a bug report (if they can) it often disappears into a black hole. The same thing happens with enhancement requests. Instead of tapping into this resource, software organizations typically discourage feedback. This isn't the kind of relationship that should exist between the user and software organization. Instead, it fosters an “us” and “them” mentality.
Users use the software. They know what they want, what they like & what they don’t like. When they ask questions about the software, they also provide useful data regarding workflows, documentation, the user interface and/or enhancements. Repeated questions should be a red flag; something needs fixing. Instead, they are often met with desultory remarks on forums (where forums exist), "Use the search function, moron." Not the best way to value user input.
Every time a user takes the time to write a bug report, enhancement request or ask a question, the software organization has an opportunity to collect valuable data and build customer loyalty. The difficulty is funneling and collating these disparate bits of data into a useful form and responding in a personalized manner. It’s no small task and requires staff, commitment and resources. Unfortunately, like documentation, responding to customer feedback is often left as an afterthought, if it's thought of at all.
- Software is designed to do what programmers think it should do, not what users want it to do.
- Software fails in part because programmers try to do too much.
- Software also fails because valuable user feedback is often discarded or not fully utilized.
- Programmers that encourage & act on user feedback are rare. Hang onto them.
This article desmonstrates a different way to design blog articles and I also believe it's the first time anyone has inserted a whole new website design, into a standard blog template.
- Dustin separates his regular blog from his blogazine. Here, it's all comingled.
- Fancy title text is real text (4KB font file)
- Web Standards (Valid XHTML/CSS)
- Fixed positioning for header & footer
- Some fun CSS:hover elements
- Cross-browser opacity (this text box)
- I don't care if you follow me on Twitter
Since before May 2005, we've authored uniquely-styled blog posts. This post however, is the first that utilizes a entirely new page design and layout.
It is hugely fun, satisfying and is a partial answer to the question, "Why haven't you redesigned Randsco in over six years?" (Each post is potentially a new design, eh?)
Will we do more? You bet! Unfortunately, it's a non-trivial task and requires time, energy and planning. Our blogging software doesn't allow for this "out-of-the box" and requires add-ons, hacks and custom coding to make it happen.
Such integrated designs will limit article quantity, but hopefully, we'll be able to provide a balanced mix and ... a way to quickly tell them apart!
In the meantime ... Happy Holidays!