Empathy Bridges the Gap Between UsWare and ThemWare

Jeff Atwood writes of UsWare and ThemWare:

1. MeWare
   The developer creates software. The developer uses it. Nobody else does.
2. ThemWare
   The developer creates software. Other people use it. The developer does not.
3. UsWare
   The developer creates software. Other people use it. The developer uses it too.

These ideas originated with Eric Sink, but the discussion is based on Jakob Nielsen’s First Rule of Usability: Don’t Listen to Users.

The question is not whether to ignore your users, but how to listen to them.  Users are often too literal in what they want.  They want to tell you about the feature or change that you must make to your software, rather than the real problem they need to solve.  This is treating the symptoms and not the disease. 

Often they don’t know the real problem they want to solve.  This is where empathy can bridge the gap.  With UsWare, we don’t need empathy so much, because we developers are the users.  With ThemWare, we run the risk of following the wrong suggestions, or following the right suggestions too literally because we have no compass to guide our decisionmaking about features.  Anyone who has seen software built by the classic Product Management triage and prioritization approach knows it is a recipe doomed to create mediocre software:

– Canvas the user groups for what they want.

– Prioritize according to some metric.  All too often the metric is whatever the Product Manager thinks is cool.  Ideally the metric has some relationship to the business results the Software company hopes to achieve.  It’s very easy to get bogged down in these metrics with Balanced Scorecards and a host of other contrivances that stand in for true understanding and empathy.

– Put it all down on stone tablets called “Product Requirement Documents” and hand those to Engineering with the proviso to implement them precisely as they are written and don’t ask too many questions.

By contrast, Empathy means we have some sort of true understanding of why users want what they do.  This helps us to know things like:

– Which things can and should be safely ignored.

– Which things will really change the user experience for the broadest market.

– Which things will be interesting “almost good enough” features that are demoed often but seldom used.

Empathy is a bit different than Vision.  It’s deeper because it’s rooted in the Domain.  Find someone with Empathy in your Domain and that someone will be completely comfortable conversing with your users about their problems.  They’ll be able to persuade those users they are right, albeit perhaps requiring a prototype or two to get there.  The reason?  They speak the user’s language.  They get it.

Make sure someone on your team has this Empathy for your market or you’ll have a very difficult time.