- air
- ajax
- algorithm
- apple
- bitbucket
- braintapper_exchange
- charts
- chumby
- codeigniter
- cognos
- complexity
- crosstab
- dash
- dashboard
- date
- dbvisualizer
- decisions
- dimension
- dogfood
- dona_wong
- edward_tufte
- feature_checklists
- feature_excellence
- filemaker
- firefox
- firewall
- flot
- flowing_data
- fogbugz
- football
- free
- freenas
- freshbooks
- gm
- google_charts
- iPad
- javascript
- jdbc
- jedox
- mac
- macbook
- maps
- marsedit
- mercurial
- metaweblog
- metrics
- microstrategy
- monowall
- moo
- nathan_yau
- open_source
- palo
- pentaho
- pfsense
- printing
- programmers_interfaces
- rapidweaver
- regex
- regexr
- rest
- smoothwall
- sony
- sqlpower
- stackoverflow
- statistics
- stephen_few
- svg
- tablet
- ticket_agent
- tip
- tm1
- transformer
- trick
- typographic grid
- usability
- visualization
- w3c
- web
- wiki
- wikkawiki
- work_management
- wsj
Tag: usability
January 22, 2010
When I'm disparaging a piece of software's user interface (in the past few years, that would be Cognos products), I often describe the product as having a "programmer's interface".
The rationale behind my pejorative use of the phrase roots back to my experience in "enterprise development" shops where the software was designed by the developers, not by someone with field experience or familiarity with the needs of the target users. Most enterprise software developers just like to code, and that means building cool algorithms. The user experience is often just an afterthought.
Granted, not all programmers are inconsiderate of their users. After all, one of my favorite programmer personas, Joel Spolsky, wrote a wonderful book just for programmers to teach them how to design user interfaces.
Programmer's interfaces are usually the resolution of a technical issue in an environment where expedience is valued over careful thought.
Bigwigs like to talk about ease of use (here's my snarky response to that), but usually senior managers in enterprise software companies don't really spend a lot of time eating their own dog food.
In the development scenarios that I've been a part of, the teams that build the software are more often populated with architecture astronauts at the top of the food chain and pure coders at the bottom. The real problem lies in the fact that there are often no team members with actual field experience. That is to say, nobody who actually uses the tool that is being developed, in the real world, to provide some insight into what real users want. The result is software that succeeds in a technical capacity, but fails in a human context.
Now note that I've been careful to use the phrase "enterprise software", and not "consumer software". They are two completely different beasts, targeting two completely different types of markets. Consumer software tends to be better at avoiding the programmer's interface than enterprise software, mainly because they're trying to please Joe Sixpack. Enterprise software targets IT managers and other stakeholders who are buying based on Feature Checklists, and not Feature Excellence (two terms that I'll outline in a subsequent post).
The sad news for buyers of enterprise software is that they accept programmer's interfaces as a fact of life. My hope is that you'll see startups and open source projects shake up the industry and make usability a competitive advantage.
Sadly, I'm not holding my breath.
The rationale behind my pejorative use of the phrase roots back to my experience in "enterprise development" shops where the software was designed by the developers, not by someone with field experience or familiarity with the needs of the target users. Most enterprise software developers just like to code, and that means building cool algorithms. The user experience is often just an afterthought.
Granted, not all programmers are inconsiderate of their users. After all, one of my favorite programmer personas, Joel Spolsky, wrote a wonderful book just for programmers to teach them how to design user interfaces.
Programmer's interfaces are usually the resolution of a technical issue in an environment where expedience is valued over careful thought.
Bigwigs like to talk about ease of use (here's my snarky response to that), but usually senior managers in enterprise software companies don't really spend a lot of time eating their own dog food.
In the development scenarios that I've been a part of, the teams that build the software are more often populated with architecture astronauts at the top of the food chain and pure coders at the bottom. The real problem lies in the fact that there are often no team members with actual field experience. That is to say, nobody who actually uses the tool that is being developed, in the real world, to provide some insight into what real users want. The result is software that succeeds in a technical capacity, but fails in a human context.
Now note that I've been careful to use the phrase "enterprise software", and not "consumer software". They are two completely different beasts, targeting two completely different types of markets. Consumer software tends to be better at avoiding the programmer's interface than enterprise software, mainly because they're trying to please Joe Sixpack. Enterprise software targets IT managers and other stakeholders who are buying based on Feature Checklists, and not Feature Excellence (two terms that I'll outline in a subsequent post).
The sad news for buyers of enterprise software is that they accept programmer's interfaces as a fact of life. My hope is that you'll see startups and open source projects shake up the industry and make usability a competitive advantage.
Sadly, I'm not holding my breath.
Comments: 0
