One of my clients died the other day from very tragic circumstances. The problem is, he was a friend as well. I suppose I’ve been lucky in that my family and friends have not come to abrupt ends like that, up until now of course. It’s strange because you here about the different stages of grief shock, sadness, anger etc, but it’s not until you feel each and every emotion that you realise that humans can really be that predictable. The mind knows how to grieve and the body follows like a child being lead across a street by their parents. Of course we all handle the stages of grief in varying degrees, but seem to still follow the set pattern laid out for us in the evolutionary model we in.

What really saddens me though is the thought of being forgotten. I remember my grandparents but my kids do not. They were either born too late to meet them or were too young when my grandparents died to realise who and what purpose they played in our lives. I know there are some cultures that cherish their stories about their ancestors and retell them often so they are not forgotten. In our society it seems only the rich and famous will be remembered even by our kids over and above our own family. Probably because the famous have touched them in some way by music or drama and that has left an impression on them, but more so then their own family?!

When do we forget the departed? Do we build a shrine for them and keep them before us at all times? Do we tell stories about them to try and keep their existence alive in our memories? Or do we just go through the grieving process and then move on trying to forget and forge forward?

But we can never truly forget someone who has touched our lives, affected us in some way either directly or indirectly. I will remember my friend, but I know that as time goes on I will eventually loose memories of him and what seems to be only yesterday that we were discussing things will fade to become very distant memories.

For me, to be apart of someone’s life that is now gone comes with it a certain responsibility of remembrance and even if it is in quiet reflection from some event that has triggered a memory I will hold those moments special knowing that I own them for me and me only. Each life has it’s own special memories.

Lost, but not forgotten.

Well, it’s time to move again. I’ve been here 5 years and now it’s time to move the career up a notch. I’ve had plenty of changes in my life from being a sound engineer to a preacher,TV producer and now a Usability Analyst. I must say that out of all of them I find dealing with usability to be the biggest challenge. OK, I know most of you are still hanging on the Preacher thing aren’t you?

It’s true, I was a fullon Preacher of the Gospel but have now seen the light and would rather be a real help to society, given that most of us in the western world are dealing with computers at some stage of our day.

When I first discovered the benefits of Usability testing and analysis I was amazed that every business wasn’t concerned about it too! Come on people…this is important I could hear myself saying in many a meeting. “Don’t tell me what you think, tell me what you know”, of course no one could answer that. I’m not being a smarty pants but to me if usability is not included in your development process then you have some serious floors in all that you produce. Don’t look at me like that! You know it’s true, you just don’t want to accept it because you think it will blow out your time frame and the whole project will go on budget overload. You know what? It will. If you include usability as an after thought.

So, don’t sit there with your UI design patterns and tell me everything is going to be ok! Plan to involve usability methods from the very beginning, from requirements to installation.

I’ll leave this with you: “Usability is like oxygen, you never notice it until it’s missing”…and then I might add, your project is dead.

Choose life!

I have been thinking…and that’s never a good thing! As Usability Professionals we must be careful of the “I”. When asked by a developer, “What do you think?” we need to be careful the first words out of our mouths aren’t “I”. It’s so easy to say what we think and then backing it up with stats is not best practise. We aren’t about the “I” we about the “Users”. Ever heard some one say “Well, they say…”, who the hell is they?! I think sometimes we tend to use the “I” and the “They” as cop outs to get a point across quickly rather then pointing to facts, which is what usability professionals deal with day to day.

Facts. Cold hard evidence that the desicions we make are based on certainty. Hang on a minute! I hear you say, you can’t be that certain, I mean 100% just isn’t available, near enough is good enough right? Or maybe 99%, just like the packet of chips you buy beacause of the 99% fat free. Why can’t they just get rid of the 1% surely it can’t be that hard. Well, apparently if you take the 1% out and it all of a sudden tastes like shit and becomes health food….YUK!

So, what’s my point. Good question!

As a usability analyst, I need to be careful of making standards I find in usability mine. I would find it much more credible to hear someone say to the developer…”This is what the users are saying.” Not me, not 99% sure, but the users. As far as I’m concerned we aren’t there to set standards, we are there to find them and relay them to a specific situation. Generically saying, “I think it should be this or that..” is not what we are meant to be doing.

So, in summary…don’t say “I” or “they say” just say “the user”. 100% the user. Cold hard facts.

Product Development Planning – Requirements Planning Phase

The UCD Phases for this stage are:

• Build a User Profile
• Setting Usability Goals

Building a User Profile – Task Analysis

Purpose

First and foremost, you must know whom you are designing for. One of the very first steps in creating a usable product is to create user profiles for each unique group of users that will be working with the application. The goal of this step is to learn about any characteristics that could influence how the users interact with the product.

• Users’ goals and needs become a common point of focus for the development team.
• They help avoid the trap of building what users ask for rather than what they will actually use.
• Designs can be constantly evaluated against the user profiles.

It is also important to consider if any of the user groups will have dominant needs that will influence development more than the other groups.

• How many unique user groups will be interacting with the product?
  • Novice / infrequent application (e.g., web, Windows) users
  • Expert / frequent application users
  • Novice / infrequent data users
  • Expert / frequent data users
  • Administrators

The more familiar you are with your target audience and their underlying characteristics and motivations, the easier it will be to design and develop applications that will meet their needs.

• How do they go about learning new tasks?
• Are they motivated to change their work behaviour?
• Are there physical characteristics that will influence your design?
• Is there prior application knowledge that will help (or hinder) using your system?

Benefits

Product usability is achieved or improved by the first understanding users’ needs (i.e. their actual goals, the challenges and limitations they face, the unique or unexpected ways in which they use the product, etc). These needs are determined by collecting data on actual representative users’ interactions with products.
Method / Process Inputs

To build a User Profile, you must first determine who will use the planned product. This is achieved by generating information based on four main areas of user characteristics:

• Psychological Characteristics
  • This will cover finding out the attitude and motivation of the user. These characteristics can show us the reason why users do and function the way they do in their work environment. Their attitude and motivation toward their job will affect the way they do processes.
• User Knowledge and Experience
  • Knowing the level of experience and knowledge of things like: typing skills and task experience etc. Will aid in the complexity of the application currently used or to be built. This information is vitally important in understanding user experience, as it will play a key role in developing the users’ profile.
• Job and Task Analysis
  • Task structure – What types of work did they use the product for?
  • Frequency of use – Are they novice (short periods of use) or expert (frequent use).
• Physical Characteristics
  • This covers any physical limitations that users have e.g. Colour blindness, visual disabilities etc.

Process Outputs

• The information gathered on user characteristics will be used to update URS to reflect user knowledge, user experience, job types and task characteristics which sums up the User Profile. Section 5 of the URS – User Characteristics.
• Scenarios can also be built up using this information for the User profile.
  • Scenarios are most useful when produced early in the development as specific realistic and detailed examples of what a user would do, but without making any reference to what interface features that would be used. Scenarios can also be used later to explore how the interface would be operated.

Setting Usability Goals

Purpose

To establish usability goals which can be tested later in the development process to determine if the implementation of the requirements have met these goals.

Benefits

• Highlights the importance of usability early in development
• Provides concrete objectives for usability
• Provides usability criteria that can be tested.

Method / Process Inputs

Establish requirements for effectiveness, efficiency and satisfaction for the user groups and tasks identified in the context of use analysis and in the scenarios.

• Current System Analysis
  • If there is an existing system, the usability practitioner with the help of an expert user would set a list of usability goals to be used as a minimum standard which would be used to refine the usability requirements. The minimum acceptable usability would normally be equal to the current usability level, and the target usability could be derived as an improvement that is a higher level to the current system.
• Note: If a current system is not a viable option then usability goals may be based on the Project User Requirements and the User Profile.

Usability Goals Examples

• The design must support users working in a high-interrupt environment, with lots of context information on screen to remind users where they are when they get distracted.
• The design must support very infrequent users of a very complex task. Thus, it must be self-explanatory and easy to learn and remember, incorporating as many business rules as possible and leading users by the hand through the task so they need not remember details of proper procedure between users.

I will continue to follow-up with the Design stage next week.

I have been working on the UCD process to fit into the development lifecycle used at a major software company I was working for that were not involving any type of usability testing into their development stages. (Shock Horror!)

Over the next few weeks I’m going to refine it and out it up here for anyone who want s to comment or cut and paste it to use in your own company or development lifecycle.

here is the first installment – A UCD Overview.

Purpose

The purpose of this process is to provide a basis for Project Managers to integrate Usability engineering to a particular project, and to also provide guidance in the planning of the associated sequencing of stages, phases, iterations and activities.
Scope

The UCD described in here can be applied to any software development project, however the content is targeted towards providing guidance to Project Managers who are planning and managing software development projects.

UCD overview

This process model emphasizes that one should not rush straight into design. The least expensive way for usability activities to influence a product is to do as much in the early stages of the design, since it will then not be necessary to change the design to comply with the usability recommendations and may make it possible to avoid developing unnecessary features.

The UCD model consists of:

Product Development Planning Stage – Requirements Planning Stage

• Building a User Profile (Task analysis) – Building User Profile is the first task in the Usability Engineering Lifecycle. It is important to separate and identify each user in there own category (eg. Managers, Data entry, Warehouse worker etc). This information can be supplied from the Product manager. Once each user category has been identified we then can obtain the user characteristics of each user group :

1. Psychological Characteristics

• This will cover finding out the attitude and motivation of the user.

2. User Knowledge and Experience

• Knowing the level of experience and knowledge of things like: typing skills and task experience etc.

3. Job and Task Analysis

• Task structure and frequency of use.

4. Physical Characteristics

• This covers any physical limitations that users have e.g. colour blindness, visual disabilities.

• Setting Usability Goals – Setting a minimum level which would be acceptable

The minimum acceptable usability would normally be equal to the current usability level, and the target usability could be derived as an improved level to the current system.

Design Stage
Maintaining General Design Principles
Style / Design Guides

• The Style Guide is meant to provide design guidance and “look and feel” standards that will be applied across all products developed within Mincom.

Prototype Design Evaluation

• Building and testing prototypes are vitally important to the usability engineering process to obtain rapid feedback on structure of screens and navigation etc.

Implementation Stage
Usability Testing and Analysis
Final product Usability analysis. This should be mandatory prior to any release to the customer.

• User Feedback and Follow up Studies

• Interviews – Can be conducted by a usability consultant or marketing. Users are asked a series of questions relating to their experience with the system.

• Questionnaires – Similar outcome to the interview method.

• User Feedback – Documented feedback that can be feed back into support or future product development.

Below is a diagram of the UCD process and it’s stages in the development lifecycle.