Interface Design vs Requirements

ArgonDigital - enterprise automation experts

Share This Post

Design has never been one of my strong points.  When I was picking out paint for my new home I assumed that if I liked the color, then it would work on the wall.  Didn’t turn out to be true.  Same goes for my requirements.  Just because my mock-up screen had a cornflower blue tint doesn’t mean that was a functional requirement.

I know that these fields must be included during registration.  I know the impact to the business if they are not there.  I know what they allow for length, as options, and as valid data input.  I know the errors that must occur when they aren’t used properly.  I know the actions that occur when a user selects one option over another.   I know what the maximum acceptable response time is and how many results should be presented at any given time.  I know what information should be contained in a report.  I know what information should be summarized in graphical forms.  These are my realm.  These are my expertise.

I do not know the difference between Calibri, Arial, or Helvetica let alone how it will influence a user’s experience with a tool.  I have limited knowledge on where the user focuses their attention fist when they see a screen.  I do not know the best way to present information gathering forms.  I simply can’t fathom the correct way to space and arrange information to make it a great example of form and function.  I don’t know how the error should be presented to the user.  I do not know the best way to create a graph to quickly and accurately convey the needed information to the consumer.  These are at best my hobby.  These are a mystery.

Discussing the proper way to create infographics or design pages for ease of use sound like a great way to spend some time.  While I find these things interesting, these certainly are not my specialty and I don’t keep up to date on the new best practices.  I listed a small fraction of things that show up on my radar for requirements that a designer wouldn’t think about and I also listed a fraction of things that I am aware of for designing tools.  My knowledge comes from some brief ventures into reporting and an interesting person named Edward Tufte. This is his site.

I fear each time I present my documentation that a mock up or screen shot will be used in development as the model of record.  Alternatively I fear when development is free to implement the design as each individual sees fit.  I fear these things because it creates Frankenstein user interfaces.  They may be ‘alive’, but the users tend not to accept them very well.

I advocate the use of designers (web, UI, or otherwise) as it does make a huge impact.  It can influence user adoption, user dropout, user community, learning curve, understanding of business data, and a slew of other items.  Keeping the tools with the same feel creates branding and familiarity.

The MSN User Experience Team developed new user-centered methods to provide structured user input on the visual design of the newly-released MSN Explorer, an integrated software package. In the final product, users rated “appearance” above all of the product’s features. ”  Many organizations and people devote enormous effort into getting design right and when the budget and timeline allows, it should be kept separate from the requirements.

 

This is Don Norman and a link to his site is here.

More To Explore