Continuing with usability in software systems, the current post will cover the iterative process which must be follow to deal with this topic. This iterative process was quoted in the previous entry as User-centred design process, it can also be called as Human-centred, whose definition and graphical representation are:
"Human-centred design is an approach to interactive system development that focuses specifically on making systems usable." [1]
After planning a human-centred design process (step1), the next step in the process is to understand and specify the context of use.
Remember we talked something about the context of use in the previous post, did you remember?
The context of use is the actual conditions under the software product is used, or will be used in a normal day to day working situation. This context must be studied in order to know their characteristics insofar as they are likely to influence the usability of the final software product. The context of use is composed by three elements (users, tasks and environment).
We have to analyze:
- Characteristics of users.
- Tasks that users are going to perform.
- Environment where the system is going to be used.
This type of design requires active involvement of users throughout the development process, plus an appropriate allocation of function between users and technology. At this point, it is going to reflect on some available methods for the observation of the context of use:
[USERS]
Questionnaries: After preparing a questionnaire about relevant issues, you can choose to conduct a series of personal interviews or distribute it to a sample of users. In my opinion the second option is better because the user will feel more free and you probably will receive more feedback.
User representation: This can be done with Personas technique, defines fictitious personas based on information gathered from many real users and focuses on these personas throughout the software development process (advantage: it helps to think on the real end user); or User profiles, collects and organizes information about users viewing them as roles.
[TASKS]
Observation: Made by the observer himself following the technique of Ethnographic observation, in which the viewer is immersed in the "culture" to study, understanding the motivations and needs of the user and their use of technology (aka fieldwork); or Contextual Inquiry, technique based on elicitation requirements in the user workplace, in this case the observer occasionally interrupts the user to ask why a particular action has been performed in order to find the logic behind. This technique could be seen a little bit intrusive/aggressive ( :-o I prefer not to use it!).
Self-observation: The observer does not have to act, at least initially, is the user who performs his tasks and we can study him, bothering him, writing a diary, or using a tool such as Google Analytics (automatically, undisturbed).
[ENVIRONMENT]
Competitor analysis: This method is an important part of the strategic taken, it is a strategic technique used to identify weakness and strengths that a company's competitor may have, and then use that information to improve our own product. Some might wonder Why bother to analyse competitors? On the one hand some companies think it is best to get on with their own plans and ignore the competition, but on the other hand there are others who become obsessed with tracking the actions of competitors (even using illegal methods). In summary the best goal we can achieve with this method is to generate understanding of competitors strategies to react to changes, templates on how to write can be seen here.
Besides specifying the context of use, it is necessary to produce design solutions that meet user requirements. And...what is design? Design is create something from scratch, in software market, this something is abstract, complicating the job. Therefore, designers should have in mind a product concept (design model), that's a high-level description of how a system is organized and works.
Another question arises at this point How designers can generate and discuss design ideas? let's answering this question explaining different techniques:
Brainstorming: That is useful to generate a diversity of ideas, however it is not good if there is tension in the group or there are fights over the ownership of ideas.
Parallel design: To explore different alternatives several different designers work out preliminary designs before settling on a single approach.
Scenarios: Specific case of the use of the product, they are fictional stories written as a narrative.
Storyboards: Also an specific case of the use, but this time the story is a comic-strip-like set of drawings.
Scenarios and storyboards are a good way to increase the fidelity of the project without overly focusing the functionality of the UI. They concern themselves with situated conditions, user motivations and environments without addressing functional details of the UI. Both design artifacts can offer visual ideas of users’ interaction with the product and can force design decisions, if you are not good at drawing, your choice are the scenarios, but as "a picture is worth a thousand words" I recommend using storyboards. To do storyboards check out Guide to storyboarding [2], a very good guide that considers three main points (setting, sequence, satisfaction) when making them.
Questionnaries: After preparing a questionnaire about relevant issues, you can choose to conduct a series of personal interviews or distribute it to a sample of users. In my opinion the second option is better because the user will feel more free and you probably will receive more feedback.
User representation: This can be done with Personas technique, defines fictitious personas based on information gathered from many real users and focuses on these personas throughout the software development process (advantage: it helps to think on the real end user); or User profiles, collects and organizes information about users viewing them as roles.
[TASKS]
Observation: Made by the observer himself following the technique of Ethnographic observation, in which the viewer is immersed in the "culture" to study, understanding the motivations and needs of the user and their use of technology (aka fieldwork); or Contextual Inquiry, technique based on elicitation requirements in the user workplace, in this case the observer occasionally interrupts the user to ask why a particular action has been performed in order to find the logic behind. This technique could be seen a little bit intrusive/aggressive ( :-o I prefer not to use it!).
Self-observation: The observer does not have to act, at least initially, is the user who performs his tasks and we can study him, bothering him, writing a diary, or using a tool such as Google Analytics (automatically, undisturbed).
[ENVIRONMENT]
Competitor analysis: This method is an important part of the strategic taken, it is a strategic technique used to identify weakness and strengths that a company's competitor may have, and then use that information to improve our own product. Some might wonder Why bother to analyse competitors? On the one hand some companies think it is best to get on with their own plans and ignore the competition, but on the other hand there are others who become obsessed with tracking the actions of competitors (even using illegal methods). In summary the best goal we can achieve with this method is to generate understanding of competitors strategies to react to changes, templates on how to write can be seen here.
Besides specifying the context of use, it is necessary to produce design solutions that meet user requirements. And...what is design? Design is create something from scratch, in software market, this something is abstract, complicating the job. Therefore, designers should have in mind a product concept (design model), that's a high-level description of how a system is organized and works.
Another question arises at this point How designers can generate and discuss design ideas? let's answering this question explaining different techniques:
Brainstorming: That is useful to generate a diversity of ideas, however it is not good if there is tension in the group or there are fights over the ownership of ideas.
Parallel design: To explore different alternatives several different designers work out preliminary designs before settling on a single approach.
Scenarios: Specific case of the use of the product, they are fictional stories written as a narrative.
Storyboards: Also an specific case of the use, but this time the story is a comic-strip-like set of drawings.
Scenarios and storyboards are a good way to increase the fidelity of the project without overly focusing the functionality of the UI. They concern themselves with situated conditions, user motivations and environments without addressing functional details of the UI. Both design artifacts can offer visual ideas of users’ interaction with the product and can force design decisions, if you are not good at drawing, your choice are the scenarios, but as "a picture is worth a thousand words" I recommend using storyboards. To do storyboards check out Guide to storyboarding [2], a very good guide that considers three main points (setting, sequence, satisfaction) when making them.
Setting: People involved? Environment? Task being accomplished?
Sequence: What steps are involved? What heads someone to use the app? What task is being illustrated?
Satisfaction: What's the motivation for the user? What's the end result? What need are you satisfying?
The big problem that exists nowadays is that enough iterations are not performed in the development process of a software system, perhaps caused by budget problems, time, etc. Often, only the first user requirements are taken in account and without continuous iterations it is hard to keep the project updated and at the end you have a different product than the user wanted. The reaction of users to the system can not know in advance 100%, no matter how has been studied the problem and potential users (humans are unpredictable by nature), so you need to refine or redefine the design. Consequently the iterative approach is required because the better understanding of the problem is only reached when the solution is finished.
[1] ISO 9241-210
[2] Dar Aziz, Amal. Amal's Guide to Storyboarding. Stanford University.
Sequence: What steps are involved? What heads someone to use the app? What task is being illustrated?
Satisfaction: What's the motivation for the user? What's the end result? What need are you satisfying?
 |
| Applying these three points, this is part of the storyboard of our project |
The big problem that exists nowadays is that enough iterations are not performed in the development process of a software system, perhaps caused by budget problems, time, etc. Often, only the first user requirements are taken in account and without continuous iterations it is hard to keep the project updated and at the end you have a different product than the user wanted. The reaction of users to the system can not know in advance 100%, no matter how has been studied the problem and potential users (humans are unpredictable by nature), so you need to refine or redefine the design. Consequently the iterative approach is required because the better understanding of the problem is only reached when the solution is finished.
[1] ISO 9241-210
[2] Dar Aziz, Amal. Amal's Guide to Storyboarding. Stanford University.
No hay comentarios:
Publicar un comentario