This post originated from an RSS feed registered with .NET Buzz
by Ranjan Sakalley.
Original Post: Requirments collection for User Interfaces
Feed Title: Ranjan Sakalley
Feed URL: /error.htm?aspxerrorpath=/blogs/ranjan.sakalley/rss.aspx
Feed Description: (the life and times of a mock object)
End users interact with your software only through the User Interface, and therefore, you must understand that for them the User Interface is the software.
Architects, and developers in general forget this, and are
predominently concentrating on design patterns, antipatterns, language
nuances, tiering and layering, data communication between machines etc.
throughout the software development life cycle. Whilst the above
mentioned entities are essential towards a good product, User Interface
is the most important of all the aspects of a software; this, if you
are in the business of selling the software, or providing an end user a
convenient solution. Many a time, I forget the actual motive behind
writing a software, which invariably is improvement in productivity of
the users of the software. User interface forms a very important part
of what we are writing the software for. This is the reason why people
took Windows over Unix a long time back.
Essentials for an effective user interface
An effective user interface helps a user perform a task with the
minimum possible effort. To create one, you must understand the user,
just like a motion picture director understands the audience, and
manipulates their feelings. Following are some aspects of the audience
that you must know, before starting to design an effective user
interface -
Individual Technical ability
Gather information on the computer literacy of the users. Instead of
letting them tell you about it, start with a set of questions first,
get these questions answered by all possible end users, or if you are
developing a product, a trusted sample target audience. I would
normally ask atleast the following -
General questions - questions that would give us some metrics on what is the technical ability of the users
Do you like working with machines? Computers?
What is your current position in the company, does it involve working with computers?
Have you undergone a formal computer training program?
Do you think a computer can add/has added to your productivity?
Do you have a computer back home?
How often do you use a computer? How much time do you spend every day?
Please rate yourself from 1-10 on your typing speed/skills?
How would you like to classify yourself, as a mouse-user or a keyboard-user?
Are you left handed? If yes, do you use a left-handed mouse?
What are the the problems you have faced, and currently face when you are working with a computer?
Do you like a colourful interface to the software, or a simple classy one?
Do you like reading articles on the computer? Do you increase the font sizes when you are reading?
Do you feel comfortable with simple
menu items with small images, of you would prefer an interface with big
image buttons on the screen?
Do you get bored of the user interfaces that you use currently? Tell us what actually do you feel is the reason behind it.
How often do you use software help manuals, per day?
How would you react to a new software given to you?
How much time would you prefer to spend on getting trained? Do you think the training time has its worths?
Once you get the answers to such questions, get some metrics out of them, form small groups of people who you can classify as
a. People who got bored answering because they know too much.
b. People who answered the questions positively.
c. People who answered the questions correctly, and gave you a good picture of what they are looking for.
d. People who got bored answering because they did not know what you were asking about.
and many others. If you cannot talk to all
of these, find atleast two median users of each such class, and talk to
them regarding how they feel about Computer software in general, and
what are their basic needs and problems with computer interaction.
With these questions, you would have a definitive picture about the
knowledge, enthusiasm levels and a little information on technical
capability of the users, the stress you need to put on keyboard
shortcuts and tab-orders etc., the problems that you need to solve for
them, specifically in terms of their past experience with user
interfaces, and some other questions like would you need to support
skins etc. These questions would sometimes give you a picture of what
the users expect in terms of Help manuals and training too. A set of
20-30 such questions would really help you getting this knowledge.
Group technical capabilities - User classifications in the Enterprise scenario
With a result set of the questions above, you would actually be able to
classify users with their job functions in the target organization. I
mention this, because most enterprise automation software involve a lot
of roles, each separated by the other based on education, aptitude and
talent etc. of the employee. And for each such role, their is a
separate user interface that you need to design. With the metrics from
the last questionnaire, and after the meetings, you might be able to
define the traits of each role. Following is a set of roles that you
might get, with a healthcare provider organization -
System Administrators - highly efficient computer users, very enthusiastic in controlling all aspects of your software.
Nurses - least efficient but highly enthusiastic. Might not know what they want, and hence you have to pitch in extra effort.
Doctors - normal efficiency, but would like the software to do and be everything, "no clicks" requirements
Clerks - very efficient, understand computers and have specific requirements. Reporting needs.
Data entry personnel - good typing skills, keyboard freaks, require perfect data flow.
Marketing managers - not good with computers as such, but
want to use them, requirements run around communications and almost
everything you can write reports on.
Human resource managers - undertand the importance of keeping records, generally require reporting and file storage capabilities.
Receptionists - efficient typists, prefer a POS like user interface.
Lab managers - record keeping, communication and integration requirements.
and so on.
Divding the audience, into small identifiable groups is one of the best
ways to go ahead with user intefraces. It helps in putting concentrated
efforts on each module of the UI, right from the time when you start
writing proof of concepts. Once you can group the users as a set, and
have clear boundaries of each role, you have to start preparing
questions for each such role, asking questions designed specifically on
their tasks, and how they want the user interface for each task to look
like. I am currently reading a book on Paper Prototyping, and its
definitely a way to go.
As a conclusion, I would mention that each end user is unique, and to
strive to satisfy every one of the end users is a noble task. One needs
to understand the limits to which such customizability can be provided,
and these limits cannot be drawn without gathering a comprehensive set
of metrics. Whether you go ahead with satisfying each user, or by
grouping end users into roles, and then satisying the median of such
roles, you must first understand the importance of the User Interface,
and then their requirements.
Previous Topic
