Identifying Stakeholders and Requirements

Who will be using the website?

• Designer/design company
• The supermarket owners
  
• Public
• Business partners
• Media
  

I now need to identify some common tasks that people would do on a supermarket website. Here's a list of what I found from looking around some existing sites:

• Online shopping
• Non-core products - financial/insurance services/mobile/broadband
• Contact
  
• Complaints
• Store locator
  
• Opening times
• Pre-ordering
• Price checks
  
• Career
  

These are the needs and requirements of the users.

Next I will be looking at task analysis - what will be expected from the user, create a model scenario and then prepare for testing.

What Is Usability?

Here is a list of some of the things that determine usability:

• Easy to learn
• Efficiency
• Effective to use
• Safe to use
• Allows users to do what they want to do (good utility)
• Easy to remember how to use

If these usability goals are met, they can lead to achieving the user experience goals. Here's a list of things we'd like our products to be:

• Fun
• Emotionally fulfilling
• Rewarding
• Supportive of creativity
• Aesthetically pleasing
• Motivating
• Helpful
• Entertaining
• Enjoyable
• Satisfying

If any of these goals are achieved, it will increase the chances of the user using your product again and perhaps encouraging other people to do the same.


Principles For Usable Design

From looking at 'The Design of Everyday Things' by Don Norman, I've summarised his chapter on 'User-Centered Design', which includes some very important principles which will help greatly when designing.

Principles to follow when going about a task:

1. Use both knowledge that you already have in your head and form the world around you
2. Simplify the tasks which the user will need to do - don't make them think too much about it!
3. Make things visible: Make the outcome of an intended action obvious. ( e.g. If you want a home button, you put it somewhere that the user can see it and make it look the way a user would expect it to look, so they know that if they wanted to get back to the home page, that's the button they need to click! They will be expecting that button to perform that action - so make it obvious that it does what they want.)
4. Response compatibility. Similar to No.3 - Make sure the user knows what the effects of an action will be. Such as, what would happen if they clicked a certain button? And that they can determine what's there for their benefit and what's there as a necessity.
5. Use constraints to help you! They can make the user do what you want them to do and what they want to do, by constraining their options, leaving them no choice but to do what's there. This can save them a lot of time by getting straight to the point, which they'd appreciate.
6. Design for error. Always plan for a way of recovering from an unwanted outcome. So if the user goes somewhere they didn't intent on going, give them a way of getting out of there and to the place they wanted to go. Even better, make it hard for the user to get in a situation like that in the first place!
7. When all else fails, standardise! If you can't avoid creating something that's different, then standardise is, so the user only has to learn how to use it once and won't have a problem when using it the next time!

Ten Usability Heuristics

I've also found this list of useful rules, by Jakob Nielsen, some of which cover what Norman was saying:

Visibility of system status

The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.

Match between system and the real world

The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.

User control and freedom

Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.

Consistency and standards

Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.

Error prevention

Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.

Recognition rather than recall

Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.

Flexibility and efficiency of use

Accelerators -- unseen by the novice user -- may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.

Aesthetic and minimalist design

Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.

Help users recognize, diagnose, and recover from errors

Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.

Help and documentation

Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large.

The Waterfall Model Vs. User-Centered System Design

The Waterfall Model



This model is quite a traditional one that focuses on more of the technical side of what's being done. It labels the design process, but in a very simplified way, which is practically common sense. This model shows very little consideration to the user. It shows mostly what the designer thinks and because the designer is the one creating the product, they get to know their work very well, so what might seem very simple to use and look nice to them, can be completely different for the user, who has never used this product before. If however, the processes could be done in a way where they can interact with not just one other process, then it would be less restricting and if the processes could involve steps that involve what should be done for the users, then that would make this model much more beneficial.

User-Centered System Design

Here, you can see that the UCSD model does include the user, which is obvious from its title. This is why I think this is the better model for me to use. I am creating a website and the way the users feel when they use it, is extremely important. This is a very iterative process, which allows me to keep fine-tuning my developments so I end up with a good website with lots of results and research to back up all the reasons on the way the site looks and functions.

The Design Process

Here I will be looking at the design process:

• Identifying basic function of site from clients
• Identify stake holders
• Estimate of delivery date and overall cost
• Needs analysis/requirements

- With any particular group, you need to:
Identify all tasks
Identify most common tasks
Develop a set of use-case senarios
e.g. a potential online shopper have a senario of shopping for certain items and buying them
How can create a use-case senario? - Case study
- Look at other supermarket websites (competitive analysis)
- Feedback on the existing website I'm redesigning
- Userbility testing

• Specification - exact functions of site and technologies to make it
• Sign off document

-Interaction Design

1. Establish requirements and identify needs
2. Develop alternative designs
   
3. Build interactive versions }Iterative
   
4. Evaluation

There are three characteristics of this process:

1. Focus on users
2. Specific usability and user experience goals
3. Iterative design

• Come up with some designs (having finalised architecture info)
• Usability testing on prototypes
• Re-design
• Initial build
• Testing
• Final Build
• Implementation
• Evaluation (and modifications if necessary)
• Maintenance
  

This is quite a detailed process, the next post will be on the waterfall model.

The Task

My task is to simply go through a user-centered design process to redesign a supermarket website. This blog will be maintained in order to help me form my report at the end of this task. I will be adding new posts showing how I'm getting on with this task and to keep record of all my research from:

• Case Studies
• Task Analysis
• Requirements Gathering
• Stages From Usability Testing

To start with I will be looking at the design process and comparing two design models to see which one has the most benefits.

Hi

This is just a test for me to see the layout of this blog. Hopefully I'll get some work up on here soon!