• Seilevel Team

    Here’s the Team

    Welcome to our Seilevel Photo Op.

Interface Design vs Requirements

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.

2 Responses to Interface Design vs Requirements

  1. David Locke June 18, 2010 at 11:11 am #

    At a user conceptual level, your whats have strayed into hows, and all these art considerations are about mood, conceptual fitness gets lost. UX does its thing. Requirements elicitation does its thing. And, in the end, because of the conceptual distance from the user and the personified average user, the user and the organization they work for pays implicit, hidden costs.

    Maybe one day when software is seen as a media, the work carried by the software carrier will be the focus, and the prior user conceptualizations, the user’s functional cultures will not be ignored.

    Get this, many usability problems originate in the model, not the view.

    In the meantime, thee UX fad will continue, and programmers will continue to be taught to focus on the carrier, rather than the carried. And requirements elicitors will stay focused on the 1960’s issues of developer efficiencies, rather than user efficiencies. Economics should be forcing the change, but methodologies working the wrong problems are getting in the way.

    You are like your peers; UX folks are like their peers, as well. Both your discipline and theirs were never intended to meet in the middle. They are functional cultures, artifacts of specialization, learned in school. We have a long way to go. Enjoy the journey.

  2. Haig Sakouyan June 18, 2010 at 6:42 pm #

    Now more then ever my PRD’s always include wire frames using apps like Balsamiq or paint. In my experience designer do not understand what is needed as well the Product Manager. By providing the “what” visually it makes the process immensely smoother.

    When it’s something outside (i.e. paying) customer facing and the project is a decent size I will run it by UX people. Their feedback is always so valuable. No matter how small the project is though if it is for outside customers I always request final mock-ups from the designers. Using my wire frames as a solid starting point with which they can play around with.

    However not all projects need to go through UX people. Sometimes time is a factor and sometimes budget is. Throughout all the interactions with UX people we need to be picking up on best practices and applying them to our wire frames whenever we cannot go through UX.

    When a project involves a closed app used only by internal customers then very often there is no time or budget for UX or Design folks. This is where paying attention to what the UX & designers have suggested/done in the past can be very valuable.

    So in summary while I do not think Product Managers should be doing the final design for mock-ups. I do believe it is essential for us to understand how to put together good wire frames which can convey our “what” properly.

Leave a Reply

Your email address will not be published. Required fields are marked *