This post originated from an RSS feed registered with .NET Buzz by Steve Hebert. Original Post: User interface design - seperating the data view from the user view Feed Title: Steve Hebert's Development Blog Feed URL: /error.htm?aspxerrorpath=/blogs/steve.hebert/rss.aspx Feed Description: .Steve's .Blog - Including .Net, SQL Server, .Math and everything in between Latest .NET Buzz Posts Latest .NET Buzz Posts by Steve Hebert Latest Posts From Steve Hebert's Development Blog

I was reading Ranjan’s post on user-centered-design techniques that provides insight into the user interviewing process.  This got me thinking about how we actually apply those results and some of the biases and assumptions we bring with us into those designs. 

Every application has a data view which encapsulates the rules and operations around how data correctness is maintained.  This is not to be confused with the data model, but rather the living, breathing, operational flow of how data flows into and out of the data store.  One of the recurring failures in user interface design results from exposing the user-view to the data-view.  These two views rarely match and it's a constant battle keeping these two views separate.  It's not a coincidence that user interfaces can sometimes start to look like mini-ORM implementations.

The best example of solid design that matches the targeted user is QuickBooks (not Quicken).  Every other accounting software vendor has tried to go after their market and failed – why?  Is Intuit simply destined to own this market?  I think problem goes deeper than that.

Every accounting package starts with a team of accounting professionals and the notion of debits and credits as we are taught in school.  The double entry accounting system has been engrained in the profession since Pacioli’s first textbook written in 1494 and leads to an unbending view of how these systems should be implemented. I am sure the accounting experts at Intuit cringed at the initial design that not only ignored the credit/debit paradigm, but mercilessly taunted it.  To make matters more difficult for the sake of project management, those accountants are fundamentally right just as practicing accountants offer a common disclaimer that QuickBooks isn't a real accounting system.  Here's the rub - they ignore the targeted user and the fact that data is fundamentally not compromised.

When translated to software, the credit/debit model becomes the “data view”.  The fundamental error that every other software vendor has made in this genre is exposing the data-view to the user-view.  From a requirements standpoint, you’ll notice this in design meetings when people say “well you must understand _____ in order to use our product.”  To some degree that is true, but that can easily become a mantra that leads to serious usability problems.

Quickbooks is not the end-all product in accounting. As a company grows larger and requires more intensive accounting abilities they find that they have outgrown the tool and move on to something else.  But Intuit has managed to question the expert assumptions as related to their user based and derived a product that is extremely popular in a market segment far larger than any other in business accounting. Intuit owns the market because they not only listened to the user, but also challenged the ‘experts’.