This project was completely new experience for me. I worked as a developer for over one year and I was involved a bit in designing process. But never in that way as during this project. I have never taken part in interview with client, also I never went through the whole design process like in case of this project. Also the user-centered design is new approach for me, now it seems to be so familiar to me, but few months ago it was not. Even when first time during the lecture that has been mentioned about user-centered approach I thought “It is so obvious. Why I have not heard of anyone using user-centered design”. I think the fact that I understand this approach is the most important and useful benefit from this course.
During the whole design process we used many methods which refer to user-centerd approach. It was great occasion for me to learn all this methods. Before this course I did not know that their even exist. Now I know that there are tools(design methods) which support the design process. I am sure that we did not discussed all user-centered methods, but it is not important. Much more important is that we started to create our design tool kit and put some tools(methods) to it. Now if I get know some new design methods I also add them to my tool kit. Now during the designing next system we can use one of the tools we already have. Important issue is to know when each tool best suit to which situation. During one lecture(Before our final evaluation with client we told during our presentation that we were going to conduct a pictive session with client. Roman than said that in this particular situation it is better to conduct walkthorugh with client instead pictive session. Because pictive session would move us back in design.) I realized that design process is not constant thing and designer should be able to react depending on situation. I think that now I am not able to decide properly which situation is best for which method, but I hope that I will get this knowledge with time and other projects.
About evaluation myself I think I have done everything as good as I was able to do. But of course now I can see something that can be done better. It was problem with interview with client, we were going to conduct a contextual interview but there were some problems with being "nosy" enough as it should be in contextual inquiry. Because the client was not interested in our work. She did us a favour so it was hard to be nosy all the time. Also I think we did not enough encourage customer to form his opinion, she was too passive. We of course get some feedback from the customer, but I think it is better if client is more critical and formulat more opinions and has more ideas. Besides that I suggest 5, because I did what I could.
Thursday, February 26, 2009
Self evaluation
In our project we have used CI and PD methods. The interview was conducted using Contextual Inquiry methods. During the interview we conducted the contextual observation and tried our best to pay attention to all the details and ask many “why” questions. We allowed our clients to guide us and teach us her work. We took into consideration all the opinions and suggestions of our customer. I think that the recording of the interview was very effective. It allowed us to easily remember what the customer said. I think some things could have slipped away if we hadn’t recorded the interview. Also while doing the transcription I’ve noticed that there were more questions that we could have asked. The interview really required all our attention and focus. During the analysis of the data we used affinity diagram, work models and personas. Personally, I really liked the experience with affinity diagram. Designing a prototype was quite easy as the requirements were clear after the analysis.
It would have been nice if we had more contact with the customer and if the customer had a need for our application. I also think that our customer was a bit nervous because of the fact that she had to speak English. We could have included the user in the design of the prototype but we ended up designing a prototype that was fully accepted and liked by the customer.
I believe I did the best I could for this project. I have followed the directions and did everything on time. I had the motivation and I have eagerly engaged in all the tasks. I really enjoyed team work with Monika and Pawel. Both of them were initiative and eager to work. We worked on most of the tasks together. The division included mostly putting our work from paper into electronic format. Based on the above, I would suggest myself 5 and for my team mates 5’s as well.
MZL
It would have been nice if we had more contact with the customer and if the customer had a need for our application. I also think that our customer was a bit nervous because of the fact that she had to speak English. We could have included the user in the design of the prototype but we ended up designing a prototype that was fully accepted and liked by the customer.
I believe I did the best I could for this project. I have followed the directions and did everything on time. I had the motivation and I have eagerly engaged in all the tasks. I really enjoyed team work with Monika and Pawel. Both of them were initiative and eager to work. We worked on most of the tasks together. The division included mostly putting our work from paper into electronic format. Based on the above, I would suggest myself 5 and for my team mates 5’s as well.
MZL
Wednesday, February 25, 2009
Self evaluation
What methods we did use:
At the beginning we created project plan, which included the initial data we had about the client, as well as our assumption and plans for the next stages. After that we used contextual inquiry methods to conduct the interview with our client. This way we got the necessary data to start the analyzing phase. For the analysis we used affinity diagrams. We created personas and work models. Finally we made out prototype, and in the process of pluralistic walkthrough we evaluated it with the client. Apart from that, in the end we did heuristic evaluation, to reveal possible, yet undiscovered faults. All the steps were done together, during meetings or over the Internet, so the workload was divided equally.
What was good:
I was really pleased when the client said she liked our prototype very much. She was emphasizing its simplicity, so it means we achieved our main goal - to keep it simple and intuitive. Our client was having no trouble with performing the actions.
What we could have done better:
I have the feeling that our end user did not have much influence on the final outlook of our prototype. Although the reason why we designed the prototype on our own was that it was said it should be as similar to the paper based one as possible, we actually made that assumption on our own and didn't discuss it with the client beforehand. Apart from that, there were also some things not present in the paper version, which we designed without consultation with the client. She also wasn't sure about many things, so in the end many of choices were made by us. We didn't encourage the user enough to share her ideas with us, to give more feedback and suggestions.
I think the reason was also that there were not many opportunities to meet with the client; it was also hard to conduct a real contextual inquiry, as we were not real company members, and the client was not really interested in buying the product - it was us who were interested in their help; so we were ofter discouraged to disturb too much in their work.
What I have learned:
First of all I got to know that there are many methods available for designing applications in user-centered way; some of them would even look silly for me (e.g. PICTIVE), and I was surprised first by the fact that they are actually used, and secondly that they are effective. It just seems that the most obvious solutions are the hardest to notice and consider. I am also glad to have learnt the idea of contextual interview, which again being so simple, gives such a good tool for understanding what are the user's needs. In case of complicated systems I think often it's the only way to understand the requirements well, otherwise our clients would have to be specialists themselves, able to write a detailed specification of what they need. But this is almost never the case.
Self-evaluation:
As all three of us did our best, and the work was divided equally, I think we all deserve 5's.
At the beginning we created project plan, which included the initial data we had about the client, as well as our assumption and plans for the next stages. After that we used contextual inquiry methods to conduct the interview with our client. This way we got the necessary data to start the analyzing phase. For the analysis we used affinity diagrams. We created personas and work models. Finally we made out prototype, and in the process of pluralistic walkthrough we evaluated it with the client. Apart from that, in the end we did heuristic evaluation, to reveal possible, yet undiscovered faults. All the steps were done together, during meetings or over the Internet, so the workload was divided equally.
What was good:
I was really pleased when the client said she liked our prototype very much. She was emphasizing its simplicity, so it means we achieved our main goal - to keep it simple and intuitive. Our client was having no trouble with performing the actions.
What we could have done better:
I have the feeling that our end user did not have much influence on the final outlook of our prototype. Although the reason why we designed the prototype on our own was that it was said it should be as similar to the paper based one as possible, we actually made that assumption on our own and didn't discuss it with the client beforehand. Apart from that, there were also some things not present in the paper version, which we designed without consultation with the client. She also wasn't sure about many things, so in the end many of choices were made by us. We didn't encourage the user enough to share her ideas with us, to give more feedback and suggestions.
I think the reason was also that there were not many opportunities to meet with the client; it was also hard to conduct a real contextual inquiry, as we were not real company members, and the client was not really interested in buying the product - it was us who were interested in their help; so we were ofter discouraged to disturb too much in their work.
What I have learned:
First of all I got to know that there are many methods available for designing applications in user-centered way; some of them would even look silly for me (e.g. PICTIVE), and I was surprised first by the fact that they are actually used, and secondly that they are effective. It just seems that the most obvious solutions are the hardest to notice and consider. I am also glad to have learnt the idea of contextual interview, which again being so simple, gives such a good tool for understanding what are the user's needs. In case of complicated systems I think often it's the only way to understand the requirements well, otherwise our clients would have to be specialists themselves, able to write a detailed specification of what they need. But this is almost never the case.
Self-evaluation:
As all three of us did our best, and the work was divided equally, I think we all deserve 5's.
Sunday, February 22, 2009
Exam questions
I would suggest the following tasks:
Task 1
An owner of Art museum has decided to offer a pervasive educational mobile game that would enrich the visitors experience in the museum. He hired a design team that was supposed to design the game. In the game the players will be given basic information on the art pieces in the museum and then they will have to answer intriguing questions. The game can be played by juniors and seniors. The design team visited the museum owner’s office and performed contextual inquiry interview. After analyzing (affinity model, work models, personas) the data, the design team sketched a few low fidelity prototypes. Together with the owner, the design team discussed the pros and cons of each of the prototype and decided to go with one of them. After implementation of the game, the design team met with owner and tested the game in the museum.
What are two things that design team did very well from a user-centered design perspective and two things that they did wrong.
Good:
The team used different methods to gather and analyze the data;
The game was tested in the real environment;
Wrong:
They omitted the pervasiveness of the game;
The owner of the museum is not the real end user of the game.
Task 2
Answer if the following statements are true or false. Explain shortly your answer.
1.Contextual design’s encourages workers to make changes and suggestions and therefore become designers themselves.
Answer: False. In CD workers are encourage to make minor changes and suggestions but explicitly not to become designers themselves. It is workers job to do their job, not to design system.
2.The main idea behind low-fidelity prototype is usually to capture and assess the interface’s appearance.
Answer: False. Low-fidelity prototype is usually created to test broad concepts. It does not reflect the exact appearance or functionality of the system. Low-fidelity prototypes are meant to for capturing the ideas or directions need to be tested and discussed.
3.The typical master/apprentice relationship model gives too much power to the master
Answer: True. The designer may be discouraged to ask too many “why” questions. Therefore, the interviewer should create a partnership, not just apprenticeship.
4.Pluralistic walkthrough are the most informal method and involves usability specialists to go through each dialogue element and check if it follows established usability principles.
Answer: False. PW are meeting where users, developers and human factors people step through scenario, discussing each dialogue element.
5.PICTIVE is the best method for presenting the prototype to the user as it does not use computer technology which can be confusing to the non-technical users.
Answer: False. In some cases when rapid prototyping has been already done, PICTIVE can put the design team backwards instead of going forward.
Task 3
“The users don’t know what they want”
“The users knows what they want”
Which statement do you agree? Explain your choice.
In my opinion both statements are somehow true. The users know the environment and work and therefore they know what would suit to their environment. On the other hand, very often the users do not know how to express their needs and wishes and therefore it may seems to others that they do not know what they want.
Task 4.
What principles are violated in the following designs link
In the first design perceptual abilities of human cognition are violated. The layout of the compose mail is different than the in the standard programs and therefore the user may get confused. In the second design human visual attention and abilities of human memory are challenged. The user attention is distracted by too many elements. The elements are scattered all around which makes it more difficult to remember their position.
MZL
Task 1
An owner of Art museum has decided to offer a pervasive educational mobile game that would enrich the visitors experience in the museum. He hired a design team that was supposed to design the game. In the game the players will be given basic information on the art pieces in the museum and then they will have to answer intriguing questions. The game can be played by juniors and seniors. The design team visited the museum owner’s office and performed contextual inquiry interview. After analyzing (affinity model, work models, personas) the data, the design team sketched a few low fidelity prototypes. Together with the owner, the design team discussed the pros and cons of each of the prototype and decided to go with one of them. After implementation of the game, the design team met with owner and tested the game in the museum.
What are two things that design team did very well from a user-centered design perspective and two things that they did wrong.
Good:
The team used different methods to gather and analyze the data;
The game was tested in the real environment;
Wrong:
They omitted the pervasiveness of the game;
The owner of the museum is not the real end user of the game.
Task 2
Answer if the following statements are true or false. Explain shortly your answer.
1.Contextual design’s encourages workers to make changes and suggestions and therefore become designers themselves.
Answer: False. In CD workers are encourage to make minor changes and suggestions but explicitly not to become designers themselves. It is workers job to do their job, not to design system.
2.The main idea behind low-fidelity prototype is usually to capture and assess the interface’s appearance.
Answer: False. Low-fidelity prototype is usually created to test broad concepts. It does not reflect the exact appearance or functionality of the system. Low-fidelity prototypes are meant to for capturing the ideas or directions need to be tested and discussed.
3.The typical master/apprentice relationship model gives too much power to the master
Answer: True. The designer may be discouraged to ask too many “why” questions. Therefore, the interviewer should create a partnership, not just apprenticeship.
4.Pluralistic walkthrough are the most informal method and involves usability specialists to go through each dialogue element and check if it follows established usability principles.
Answer: False. PW are meeting where users, developers and human factors people step through scenario, discussing each dialogue element.
5.PICTIVE is the best method for presenting the prototype to the user as it does not use computer technology which can be confusing to the non-technical users.
Answer: False. In some cases when rapid prototyping has been already done, PICTIVE can put the design team backwards instead of going forward.
Task 3
“The users don’t know what they want”
“The users knows what they want”
Which statement do you agree? Explain your choice.
In my opinion both statements are somehow true. The users know the environment and work and therefore they know what would suit to their environment. On the other hand, very often the users do not know how to express their needs and wishes and therefore it may seems to others that they do not know what they want.
Task 4.
What principles are violated in the following designs link
In the first design perceptual abilities of human cognition are violated. The layout of the compose mail is different than the in the standard programs and therefore the user may get confused. In the second design human visual attention and abilities of human memory are challenged. The user attention is distracted by too many elements. The elements are scattered all around which makes it more difficult to remember their position.
MZL
Heuristic evaluation
The heuristic evaluation of our latest prototype
Tasks and components to be carried out by evaluators:
- Create a new booking
- Change a booking
- Cancel a booking
- Marked attendance (when giving pass)
- Move a person from waiting list to attendance list
- Change settings (delete old and add new class)
- List outlook
Heuristics to be evaluated:
1. Visibility of system status;
* if the main list is long, there should be some notification that the person had been added to the list; it could be done e.g. by scrolling the list to the point where new client had been added or by pop up window
* the title with day and time in the main window is too small;
* no title for the main window and for the settings window - the user may not know what is going on;
* user may not know what the arrow on the left edge means
2. Match between system and the real world;
* on the "back" button on the settings window there should be an information that no changes will be saved;
* the user may not know what the blue arrows in main window are for - they should be placed together with only the date;
* hints may be useful after placing mouse cursor above the buttons;
* "Done!" button perhaps should be called "Save" and "Back" should be called "Exit" or "Back to control panel"
3. User control and freedom;
* no undo function (especially after deleting a person from the list)
* in the setting page, user may want to save the changes but still stay on the setting page and currently it is not possible
* there is no option to leave the program
* there is no way of editing already added bookings.
* if the wrong booking has been removed from the waiting list, in some case it takes a lot of effort to fix it (For example when list is full and user removes the first booking by mistake).
4. Consistency and standards;
* Print button may mean that the user can print the whole page, not only the list
5. Error prevention;
* before changing the schedule by clicking "Done!" button maybe it is good to prompt for confirmation;
* confirmation before canceling the booking and moving the person from waiting list to the main list;
* confirmation when deleting a user
6. Recognition rather than recall;
* changing a booking may be problematic, as the user has to switch between two lists; a supporting function may be useful - e.g. a clipboard which stores last deleted name;
7. Flexibility and efficiency of use;
* there are no options to customize the view
8. Aesthetic and minimalist design;
* the clock may turn out to be unnecessary and unpractical (there is always a clock on task bar)
9. Help users recognize, diagnose, and recover from errors;
* there is no error messages
10. Help and documentation .
* there is no help; a short introduction function may be useful;
* Q&A could also be introduced
Tasks and components to be carried out by evaluators:
- Create a new booking
- Change a booking
- Cancel a booking
- Marked attendance (when giving pass)
- Move a person from waiting list to attendance list
- Change settings (delete old and add new class)
- List outlook
Heuristics to be evaluated:
1. Visibility of system status;
* if the main list is long, there should be some notification that the person had been added to the list; it could be done e.g. by scrolling the list to the point where new client had been added or by pop up window
* the title with day and time in the main window is too small;
* no title for the main window and for the settings window - the user may not know what is going on;
* user may not know what the arrow on the left edge means
2. Match between system and the real world;
* on the "back" button on the settings window there should be an information that no changes will be saved;
* the user may not know what the blue arrows in main window are for - they should be placed together with only the date;
* hints may be useful after placing mouse cursor above the buttons;
* "Done!" button perhaps should be called "Save" and "Back" should be called "Exit" or "Back to control panel"
3. User control and freedom;
* no undo function (especially after deleting a person from the list)
* in the setting page, user may want to save the changes but still stay on the setting page and currently it is not possible
* there is no option to leave the program
* there is no way of editing already added bookings.
* if the wrong booking has been removed from the waiting list, in some case it takes a lot of effort to fix it (For example when list is full and user removes the first booking by mistake).
4. Consistency and standards;
* Print button may mean that the user can print the whole page, not only the list
5. Error prevention;
* before changing the schedule by clicking "Done!" button maybe it is good to prompt for confirmation;
* confirmation before canceling the booking and moving the person from waiting list to the main list;
* confirmation when deleting a user
6. Recognition rather than recall;
* changing a booking may be problematic, as the user has to switch between two lists; a supporting function may be useful - e.g. a clipboard which stores last deleted name;
7. Flexibility and efficiency of use;
* there are no options to customize the view
8. Aesthetic and minimalist design;
* the clock may turn out to be unnecessary and unpractical (there is always a clock on task bar)
9. Help users recognize, diagnose, and recover from errors;
* there is no error messages
10. Help and documentation .
* there is no help; a short introduction function may be useful;
* Q&A could also be introduced
Exam questions (tasks 19-23)
NOTE: The answers are not based on any reliable source (just my head:p), so if someone is using this blog for studying, don't rely on them too much ;) and feel free to correct them of course.
- What is participatory design? What methods does it use? Give an example of a real situation in application development when you would use these methods and another situation when PD approach would not be adquate. In both cases explain why.
Participatory design is an approach to design, where the end users are involved actively in this process. This involvement is being achieved by bringing them to the designer's workplace and make them committed into the design process. The main reason of such approach is the aim to make the product suitable for these users, to make sure it will meet their needs and be usable for them. This is can shorten the time needed for production process, as less changes will have to be made to the product in the future (as long as the product is changeable, but in case of software engineering, it usually is). Another advantage is that the users will have the feeling that the product is partially their effort, and they are more likely to accept it and like it.
Participatory design uses several methods for revealing the user needs and designing. The main method is participatory workshop. During a workshop the users communicate and commit to shared goals, strategies and outcomes. This should be held in a neutral place. Brainstorming can help in generating new ideas during such session. A technique used during such session might be scenarios, that are descriptions about system's functions. The user can read them and refine if needed. This can be a trigger for conversation. Also interesting thing is games based on the scenarios, which play the same function of engaging the participants into conversation and exchanging ideas.
I think participatory design can be used in many applications, but as long as the end users are available and willing to participate in the design. Developing web social networks may be a good example where the participatory design can be effective method; however everywhere where we cannot reach the real end-users this method may turn out to be completely useless. - a) Describe what is interaction design and how it is related to used-centered design.
b) What is the difference between participatory design and contextual design approaches?
a) Interaction design is a wide term standing for the process of designing products that interact with the user; it focuses on how the interaction should look like to be the most effective. It tries to answer the question of how to design a product that is usable for the users.
User-centered design is one of ways of designing interactive products. It puts the user into the center of development process and rely on his opinion and knowledge about how the system should be like.
b) Both participatory design and contextual design are methods of user-centered design. But the difference between in the way of user's engagement into the process. In participatory design the users come to the designer's workplace and work with them. In contextual design the user is still important, but it is rather the designer coming to the user's workplace and just observing his work, discussing the things that are unclear to him. - What is contextual inquiry? Describe your own experiences you had while conducting the contextual interview. Did you notice something important? What have you learned during the interview about the design process?
Contextual design is a method of user-centered design for designing user interfaces. It includes observing and analyzing the user's work at his workplace. The process of observation and currently ongoing analysis is called contextual inquiry. It includes conventional interview with the user, observation phase during which we ask the user to do their job as usual, and wrap up which is to sum up the information the designer received and make sure he understood things properly. The recommended way of conducting the inquiry is staying in partnership relation with the client during the observation, keeping in mind to treat the user more like master who is teaching us his job than the one who we are teaching. The designer is allowed to interrupt (he should have informed the client about it in advance) and ask questions.
My experience with contextual inquiry was nothing special, as everything went well. I think it is good way of understanding the user's work, because then we can see it exactly being done. - What ways of evaluation of a prototype connected to user centered design do you know? Describe them, give examples.
During the course we have been talking about two ways of prototype evaluation: these were pluralistic walkthroughs and heuristic evaluation. The first method requires the users, and the second is done just among the designers' team.
In the pluralistic walkthrough we create scenarios beforehand, that describe basic functionalities of the system. After this we meet with the users, show them our prototype and ask them to go through the actions mentioned in the scenarios explaining what they are doing. This helps to check whether the user interface is well designed, if the users know what to do at a time, and so on.
The second method is more informal. First it requires defining tasks - basic system functionalities. After this each developer judges each funcion according to some criteria; there are 10 criterias given by Nielsen, e.g. visibility of system status, consistency and standards, error prevention, etc. Each team member writes down the errors they have found in each function and category. Then all the results are merged and the outcome encloses all the possible faults of the prototype.
Saturday, February 21, 2009
Role of culture in Interaction design and UCD (task 17)
Culture plays significant role in human's cognition and perception, and therefore affects all fields of his activity. What implies from that, also it plays big role in design. The cultural aspects influence the end-users of our products. But it also has effect on the staff working in the company.
By term 'culture' we should not understand just nationality or region of origin. We can talk about culture meaning specific types of behaviour, ways of thinking and experiencing the world around us. People having common interests, doing similar jobs, can be regarded as a group having certain culture. Personally, being an exchange student and meeting people from different countries, I think I can say from my own experience, that the country of origin is not necessarily the most cruicial factor based on which we can say that particular group of people behaves and thinks different from some other group. I think that more important factor is what these people do in their lives, what are their goals, attitudes, interests, and so on..
Because UCD and IxD focus on the user, it is particularly important to take into account the cultural context. We should be aware of this factor while conducting for example a contextual interview, not to miss out something relevant, what may seem irrelevant to us. I think being conscious of existence of cultural constraints would help us a lot in designing a product that will be really usable for the user, which includes the product being intuitive and unambigious. Also this is especially significant in designing websites that should attract as many people as possible (within some certain target group).
By term 'culture' we should not understand just nationality or region of origin. We can talk about culture meaning specific types of behaviour, ways of thinking and experiencing the world around us. People having common interests, doing similar jobs, can be regarded as a group having certain culture. Personally, being an exchange student and meeting people from different countries, I think I can say from my own experience, that the country of origin is not necessarily the most cruicial factor based on which we can say that particular group of people behaves and thinks different from some other group. I think that more important factor is what these people do in their lives, what are their goals, attitudes, interests, and so on..
Because UCD and IxD focus on the user, it is particularly important to take into account the cultural context. We should be aware of this factor while conducting for example a contextual interview, not to miss out something relevant, what may seem irrelevant to us. I think being conscious of existence of cultural constraints would help us a lot in designing a product that will be really usable for the user, which includes the product being intuitive and unambigious. Also this is especially significant in designing websites that should attract as many people as possible (within some certain target group).
Evaluation with user: walkthrough
On Thursday at 11 o'clock we visited our client to present our prototype and make final evaluation with the user. We chose pluralistic walkthrough method for this.
We created three scenarios and prepared printouts of our prototype at each stage. Then, after short introduction of our application, we asked the user to go through these scenarios. During this session we tested the basic functionality of the system. Client seemed to have not any problems with the interface. I think it happened so because the interface of our system is very similar to the current one (Our customer uses a paper notebook for making notes. We decided to design an interface which would be similar, so that the client can easily understand how the system works).
We created three scenarios and prepared printouts of our prototype at each stage. Then, after short introduction of our application, we asked the user to go through these scenarios. During this session we tested the basic functionality of the system. Client seemed to have not any problems with the interface. I think it happened so because the interface of our system is very similar to the current one (Our customer uses a paper notebook for making notes. We decided to design an interface which would be similar, so that the client can easily understand how the system works).
- ISLO client comes to the office and wants to get his pass (Office worker has to mark in the system that the pass has been given out). The client wants to make a booking for the next weekend as well (the worker has to find in the system page with the class and make the booking).
- The attendance list is full and there are some people on the waiting list. An ISLO client from the main list calls and wants to remove his booking. (The office worker removes the client's name from the main list and calls the first customer from the waiting list. If the person called wants to be put on attendance list, the worker puts him. If not, the worker is calling next person form the waiting list and asks her about the same.)
- The instructor is coming to the office and asks about attendance list for his class (The office worker print out list).
The prototype
After the analysis phase we moved to prototyping. Here I present the prototype of our application.
Information about the application:
After clicking the bar on the left, the short week's schedule will fold out, the same as the one placed on the cover of paper file.
Adding new clients is being done by entering their names into the upper text input and clicking "Add", instead of putting them directly into the list. We thought this solution will be easier, as if there is no places on the main list, the person will be automatically put into the waiting list and the application will prompt for the client's phone number. The user can see if there are free places, because of the green "tick" next to the input. If there's no places the "tick" will disappear.
It is possible to delete a person from the lists by clicking the small red cross next to their name. The application will ask for confirmation in this case.
It is also possible to mark the people on the list who come and ask for the pass. Then it is enough to click the circle next to the person's name, and it will turn green.
Switching between the classes is done by clicking on the above tabs. Also the user can go to the previous/next week by clicking the blue arrows next to the class information (the first line of text). There is always a possibility to go just one week forward and then go back - as there is no need for archiving the data, and there's possibility to sign up only for the upcoming classes.
On the right, there are two buttons: "Schedule settings", which will be described later, and "Print", which allows to print the current list. There's also panel with current date and time, which we thought will be useful to the user.
After clicking the button "Schedule settings", a new window will appear for adjusting the classes information. The user is given a possibility to edit the classes' time, day of week, instructor's name, level, room, ... All the changes made in this window, after clicking "Done!" button, will affect both thetabs and the short fold-out schedule. Below is the picture of this window:
Each class is represented as a row in the table. To add a new row, the user needs to press the "New class" button, to delete existing one, there's a cross in each row for deleting. To edit the information in each cell it is enough to double click on the cell and edit the information. To move the class up/down, the user can use the little arrows in each row.
The user can navigate away from this window by clicking "back", then no changes will be made to the schedule.
This prototype we were going to show the user, and in process of pluralistic walkthrough evaluate our prototype.
Information about the application:
- it will be run on a single computer (PC)
- it should be in Finnish
- the layout should be similar to the paper based calendar
- it should be easy to understand, intuitive
After clicking the bar on the left, the short week's schedule will fold out, the same as the one placed on the cover of paper file.Adding new clients is being done by entering their names into the upper text input and clicking "Add", instead of putting them directly into the list. We thought this solution will be easier, as if there is no places on the main list, the person will be automatically put into the waiting list and the application will prompt for the client's phone number. The user can see if there are free places, because of the green "tick" next to the input. If there's no places the "tick" will disappear.
It is possible to delete a person from the lists by clicking the small red cross next to their name. The application will ask for confirmation in this case.
It is also possible to mark the people on the list who come and ask for the pass. Then it is enough to click the circle next to the person's name, and it will turn green.
Switching between the classes is done by clicking on the above tabs. Also the user can go to the previous/next week by clicking the blue arrows next to the class information (the first line of text). There is always a possibility to go just one week forward and then go back - as there is no need for archiving the data, and there's possibility to sign up only for the upcoming classes.
On the right, there are two buttons: "Schedule settings", which will be described later, and "Print", which allows to print the current list. There's also panel with current date and time, which we thought will be useful to the user.
After clicking the button "Schedule settings", a new window will appear for adjusting the classes information. The user is given a possibility to edit the classes' time, day of week, instructor's name, level, room, ... All the changes made in this window, after clicking "Done!" button, will affect both thetabs and the short fold-out schedule. Below is the picture of this window:
Each class is represented as a row in the table. To add a new row, the user needs to press the "New class" button, to delete existing one, there's a cross in each row for deleting. To edit the information in each cell it is enough to double click on the cell and edit the information. To move the class up/down, the user can use the little arrows in each row.The user can navigate away from this window by clicking "back", then no changes will be made to the schedule.
This prototype we were going to show the user, and in process of pluralistic walkthrough evaluate our prototype.
Friday, February 20, 2009
The role of culture in Interaction design and UCD
Culture affects how things are seen and perceived. To some extent it is also a determinant of what is considered good or bad. Each institution, organization or group creates its own culture by sharing the same habits, goals and attitudes. Without a doubt culture should be considered when designing interactive application, software or system(1). The product should be designed in way that it does not violate any of the values of target customers. Therefore, it can be claimed that culture is equally important than customer’s needs when designing new product. What’s more, culture influences the needs of a customer. If a product is designed according to customer’s needs but it does not fit to the culture and environment in which customer exists, it will not be fully successful. This way customer can be forced to abandon old habits and change attitudes, therefore, create new culture.
With the rapid growth of technology, it is also observable that some cultures are created because of interaction and user centered design. Excellent examples are social networking services. In the past, the websites were technical and did not allow much interaction. Right now, almost anyone can create an account within a few minutes on portals such Facebook or Myspace. These two services have significantly influenced the social networking on the Internet. They also influence the behavior of people in real life. For instance, at any of the student party people snap photos just to upload them later on to their Facebook accounts. All these people created a new culture (or subculture) that previously could not be observed.
To sum up, it is safe to claim that the role of culture in Interaction design and UCD is significant. Culture influences the design and design influences culture. Furthermore, Interaction and user center design can create new cultures.
References:
1. http://en.wikipedia.org/wiki/Culture
MZL
With the rapid growth of technology, it is also observable that some cultures are created because of interaction and user centered design. Excellent examples are social networking services. In the past, the websites were technical and did not allow much interaction. Right now, almost anyone can create an account within a few minutes on portals such Facebook or Myspace. These two services have significantly influenced the social networking on the Internet. They also influence the behavior of people in real life. For instance, at any of the student party people snap photos just to upload them later on to their Facebook accounts. All these people created a new culture (or subculture) that previously could not be observed.
To sum up, it is safe to claim that the role of culture in Interaction design and UCD is significant. Culture influences the design and design influences culture. Furthermore, Interaction and user center design can create new cultures.
References:
1. http://en.wikipedia.org/wiki/Culture
MZL
Sunday, February 15, 2009
Tree Inventory System - prototype
During the last demo we tried to conduct a PICTIVE session. Together with our client we created low-fidelity prototype of Tree Inventory System. It contained action of adding new trees to database. Based on the results we later developed higher-fidelity prototype of the system. Here is the link: click.
Interview transcript (task 13-14)
The interview at ISLO took place on Thursday, February 5th. We have interviewed the office worker who is mainly responsible for managing the bookings.
The part of our interview transcript can be found here.
Here is a mp3 recorded while a new booking was being made:
The video file recorded while cancelling the booking:
The part of our interview transcript can be found here.
Here is a mp3 recorded while a new booking was being made:
The video file recorded while cancelling the booking:
Saturday, February 14, 2009
Friday, February 13, 2009
Affinity diagram
Yesterday we have also created the affinity diagram for our project. We began with identifing the main problem:
How to create an easy-to-use electronic booking management system for ISLO?
We came up with several questions that should help us to generate ideas during the brainstorming. These questions are:
1. How to provide an easy access to various lists?
2. Network system or stand-alone?
3. How to create an easy interface for managing booking lists?
4. How the list should look like?
5. How to modify the bookings?
6. How to mark who has come to aerobic session?
7. What to do with obsolete list?
8. How to make attendance list available for the teacher?
9. How to manage waiting list?
10. How to see multiple lists at the same time?
11. What electronic platform should we use?
12. How to design user-friendly interface?
13. How to make the calendar available if there is no electricity?
14. How to input hew schedule? What to do with old one?
15. How to get the new list for the next week?
Then we proceeded with brainstorming. Each of us individually wrote down our ideas on post-it notes. Then we placed the notes on the wall in the random order:
After that we rearranged them in the groups based on similarities:
We named the groups as follow: Managing lists, List's outlook, Functionality of the system, Interface design, System design.
We discussed our division and made small adjustments:
And the affinity diagram was ready:
The next steps will include creating the personas and first draft of the prototype.
How to create an easy-to-use electronic booking management system for ISLO?
We came up with several questions that should help us to generate ideas during the brainstorming. These questions are:
1. How to provide an easy access to various lists?
2. Network system or stand-alone?
3. How to create an easy interface for managing booking lists?
4. How the list should look like?
5. How to modify the bookings?
6. How to mark who has come to aerobic session?
7. What to do with obsolete list?
8. How to make attendance list available for the teacher?
9. How to manage waiting list?
10. How to see multiple lists at the same time?
11. What electronic platform should we use?
12. How to design user-friendly interface?
13. How to make the calendar available if there is no electricity?
14. How to input hew schedule? What to do with old one?
15. How to get the new list for the next week?
Then we proceeded with brainstorming. Each of us individually wrote down our ideas on post-it notes. Then we placed the notes on the wall in the random order:
After that we rearranged them in the groups based on similarities:
We named the groups as follow: Managing lists, List's outlook, Functionality of the system, Interface design, System design.
We discussed our division and made small adjustments:
And the affinity diagram was ready:
The next steps will include creating the personas and first draft of the prototype.
Work flow models
Yesterday our group spent productive evening on creating work models and affinity diagram. After analysing the interview transcript and videos we decided to go with three kinds of work models: flow model, sequence model and artifact model.
We began with the flow model.
The flow model describes the actions and tasks performed by the office worker concerning bookings. The office worker is the main person who is responsible for managing booking. She has to interact with customers and aerobic instructors.
Then we created 4 sequence models that represent the following actions:
New booking
Cancel booking
Change booking
Give out the pass
After creating the sequence models, we created the artifact model as well. The picture is shown below:
The original paper file:
All the models are first drafts and they may require some changes.
We began with the flow model.
The flow model describes the actions and tasks performed by the office worker concerning bookings. The office worker is the main person who is responsible for managing booking. She has to interact with customers and aerobic instructors.
Then we created 4 sequence models that represent the following actions:
New booking
Cancel booking
Change booking
Give out the pass
After creating the sequence models, we created the artifact model as well. The picture is shown below:
The original paper file:
All the models are first drafts and they may require some changes.
Monday, February 9, 2009
PICTIVE
We are designing an interface of Tree Inventory System.
Today we have had our PICTIVE session. During it we have collected some important information about the shape of GUI. I have noticed that resultant interface differs a lot from that one I was expected. Some wishes of the customer seemed very strange for me(for example the wish to put button "delete" onto the pictures instead putting it under it).
Here are pictures of the final interface.
Today we have had our PICTIVE session. During it we have collected some important information about the shape of GUI. I have noticed that resultant interface differs a lot from that one I was expected. Some wishes of the customer seemed very strange for me(for example the wish to put button "delete" onto the pictures instead putting it under it).
Here are pictures of the final interface.
Sunday, February 1, 2009
On design, culture and needs
At the beginning of the course we had an interesting lecture given by Dr. Mirja Kälviäinen from the Design Resource Center at the North Karelia University of Applied Sciences. Mirja presented different methods about facilitating design suggestions based on the mental models, habits, or perceptions of users. One of the techniques used in innovation camps was to show to participants sets of pictures and ask them to choose those that described how they feel about certain product. It made me think a lot about how people perceive different things. Having the experience of living in 4 different countries, made me realize that the culture and habits influence a lot about how we see things. I’m pretty sure that having the same innovation workshop somewhere in Asia may have totally different results when conducted in Europe. I think that cultural differences apply also in designing software and applications and should not be disregarded during planning. Just like Mirja said it is very important for the designers to go to the field and research the environment in which the product will be used.
There was also one thing I did not agree with Mirja. She said that very often the customers do not know what they want. I think that customers often do know what they want but they not necessary know how to put it in words. I guess it is the design team job to discover those needs. If a customer doesn’t know what she/he needs then perhaps the customer doesn’t really need it.
MZL
There was also one thing I did not agree with Mirja. She said that very often the customers do not know what they want. I think that customers often do know what they want but they not necessary know how to put it in words. I guess it is the design team job to discover those needs. If a customer doesn’t know what she/he needs then perhaps the customer doesn’t really need it.
MZL
Project plan and Project focus
Here we present our project plan and project focus:
Project Plan
1. Client information
ISLO is an Eastern Finland Sports Institute based in Joensuu. The institute promotes participation in sporting and fitness activities for all ages in the region of eastern Finland. It offers educational programs and services in a variety of sports and fitness areas as well as training courses in fitness. ISLO is part of the Finnish sports and fitness networks. It is one of three regional sports institutes in Finland and it is maintained by the Eastern Finland Sports Institute Incorporated, which belongs to City of Joensuu.
Apart from sport and fitness trainings ISLO offers additional services such as: aerobic, accommodation, dining and solarium. Aerobic is offered every day in the late afternoons and evenings. Anyone can participate in the classes. There are 16 different classes to choose from. A customer can buy a single entry ticket, monthly ticket or season ticket. Three classes Body Pump (Pumppi), Step Pump (Pumppi Step) and GymCircut (Kuntosalicircuit) require pre registration due to limited amount of equipment (free weights-plates, barbells and an aerobic steps). The booking can be done one week before the class by phone or by visiting ISLO office. The list of registered participants is kept on paper in a file. We will investigate the possibility of designing an electronic system for booking the aerobic class at ISLO.
In this document "user" refers to ISLO and more particularly the term "users" refers to the people working in the club.The term "customer" describes a person willing to participate in a aerobic session at the club.
Apart from sport and fitness trainings ISLO offers additional services such as: aerobic, accommodation, dining and solarium. Aerobic is offered every day in the late afternoons and evenings. Anyone can participate in the classes. There are 16 different classes to choose from. A customer can buy a single entry ticket, monthly ticket or season ticket. Three classes Body Pump (Pumppi), Step Pump (Pumppi Step) and GymCircut (Kuntosalicircuit) require pre registration due to limited amount of equipment (free weights-plates, barbells and an aerobic steps). The booking can be done one week before the class by phone or by visiting ISLO office. The list of registered participants is kept on paper in a file. We will investigate the possibility of designing an electronic system for booking the aerobic class at ISLO.
In this document "user" refers to ISLO and more particularly the term "users" refers to the people working in the club.The term "customer" describes a person willing to participate in a aerobic session at the club.
2. Purpose of the observation
The purpose of the observation is to conduct contextual inquiry. By observing and interviewing the users we will collect the data that will help us to understand the current paper based system and design equally good or better electronic system. We hope to gain an understanding of how the users solve problems encountered while using the current system and what needs they have.
3. Workforce and tasks
Moderator: Monika Zych-LaineInterviewer: Monika Machunik
Observer/recorder: Paweł Niechoda
The Contextual inquiry script
The first step is the conventional interview. We introduce ourselves and explain in detail the purpose of our inquiry. We promise confidentiality and start to record. We explain to the user that her work is the priority and we want her to guide/teach us through her work and correct our mistakes. Then the interviewer begins with a couple of general questions about the user's work. The interviewer also asks about the opinions on the tools that the user uses. We will try to create a partnership relationship between us and the user. This phase should last for not more than 10-15 minutes.
The second part is explaining to the user the main principles of the contextual interview we want to conduct. We ask the user to do her job as usual, and describe what she is doing. We notify the user we want to ask questions during her job and we point out that she should tell us if the moment is not good for explanation and make us wait. This part should take only about 30 seconds.
After this is the main part of the inquiry - the user does her job and we observe it and try to interpret it. In case of any doubts we ask in order to clarify the problem. If there is not enough customers willing to book an aerobic session, we ask the user to make some fictional booking (or change/remove a booking). The length of this phase depends on our needs, but it should not exceed 30-35 minutes.
The last part is the interpretation of our observations. We describe to the user how we understood her work, and user gives feedback. If there are any misunderstandings, user should explain and clarify them. This phase should last up to 15 minutes.
4. Times and datesThe observation will take place on Thursday, February 5th 2009 at 10 am.
5. Tools needed
Notepad, pen, digital camera, voice recorder
6. Focus questions
The questions will focus on the users' activities connected with bookings and managing the bookings of aerobic classes. We will also try to discover the strengths and weaknesses of the existing system. The planned set of questions we intend to ask is as follow (in no particular order):
- How often do you use computer? Are you familiar with web browsing, using email box, word processor?
- How many bookings (changes/removal) do you do approximately per day/week? How long does it take you to deal with one customer?
- What do you find the most annoying while making new (removing/changing) bookings?
- Do you keep the old data? What are the reasons for doing so?
- What do you like about the current system?
- What kind of data concerning the client do you need while making (changing/removing) a booking?
- Who is allowed to make/change the booking?
- How many people usually do the bookings at the same time? Do you have any other departments where it is possible to book the classes?
- During what hours it is possible to book/change/cancel bookings?
- What kind of needs do you have for the new system?
- Describe what have you been doing today since you entered the work
In addition to contextual inquiry methods we may consider using other methods that will help us to find the real roots of actions. For example, PD methods, the why-why-why method.
7. Areas and tasks to observe
We will focus on the current system, users, their current environment as well as their attitudes towards computerized systems.We will focus on the ways the work is currently being done:
- Booking
- Changing of bookings
- Removing of bookings
- Communication between customers and interested parties (e.g. aerobic instructors, aerobic participants, etc.)
- Customer information
- Maintaing and managing the current data
- Weaknesses and strengths of the current tools
- Visual appeal of the current system
- The layout of existing paper schedule
- The type of customers' data stored in the file (e.g. names, telephone numbers, if this is the first visit, etc.)
- The order of filling in columns, as well as possible dependencies between the data in columns
- Possible exceptions in handling particular customers
- The environment in which the users' work is being done (the amount of noise, if the users work in a rush, etc.)
- The way of communication between the user and the client (e.g. if the customers come to the club in person too book a visit or maybe they phone or write an email)
- The level of computer skills of the users
- Possible restrictions resulting from possible disabilities of the users (e.g. color-blindness, poor eyesight, ...)
- Possible need for concurrent access to the data
- Any other issues regarding the existing system introduced by the users during the interview
Project Focus
1. Current System
Currently ISLO is using paper based system for booking aerobic classes. There are three classes that require booking: BodyPump (Pumppi in Finnish), StepPump (StepPumppi in Finnish) and GymCircuit (Kuntosalicircuit in Finnish). BodyPump takes place on Wednesdays 7-8pm and Saturdays 4-5pm, StepPump takes place on Mondays 7-8pm and GymCircuit takes place on Tuesdays 5:30-6:45pm. Each class on each day has a separate registration form. A registration form is an A4 paper sheet with information about classes (name, day, time) and two tables. The first table is meant for the bookings and consists of 45 cells (as there are 45 places) where customer information (first and last name) is stored. In case the first table is full and there are still more customers willing to participate in the classes they can put their name and phone number to the second table which is meant as a 'waiting list'. All the registration forms are kept in one folder. The forms in the folder are separated with interleaves. When a person willing to make a booking, opens the folder, he/she is required to choose an interleaf that corresponds to the class that he/she wants to make the booking for. The bookings can be made by a person working in an ISLO office or by a customer visiting the office. The customer can ask for the registration folder and put by herself her name on the list. If the customer is not able to visit ISLO office, she can call and make the reservation by phone. In the same matter changes and cancellations are being done. If the list is full (i.e. all the places are booked) a customer can put their name on the waiting list. In such case, if there is a cancellation from the original list, one of the users will call to the person on the waiting list and inform that there is place available. If the person is still willing to take part in the class, her name is moved to main list and erased from the waiting list. The cancellations can be done the latest three hours before the class starts. Before the class, a registered customer has to come to the office and obtain a pass for the class. The pass for the class is given by the user who also marks on the list (by using colorful highlighter) that the person has picked up the pass on the list. The passes are then collected at the beginning of the class by the aerobic instructor.
2. Presumed Solution
Our goal is to design an electronic system that would replace the existing, paper based one. The solution introduced to the users should be equally good or better than the existing one. By equally good we mean that it should not be more time consuming that the current. In addition, it should be at least as easy to use as the current one. Currently, both the user and customer can make the booking so the new system should also take this into consideration.
The main functionality of the system will be: booking the class, removing the bookings, and changing current bookings. If needed, we will extend the functionality, by adding features supporting users' work. We will also explore new needs for any additional functions that might be needed.
The main functionality of the system will be: booking the class, removing the bookings, and changing current bookings. If needed, we will extend the functionality, by adding features supporting users' work. We will also explore new needs for any additional functions that might be needed.
3. Supported Tasks
The new electronic based system should have the same main features that the paper based systems. Users should be allowed to do the same tasks as in the paper based system. The features can be categorized as:
- The main features:
- managing bookings for aerobic classes
- The necessary features:
- booking time for aerobic classes
- editing existing entries:
- changing the time
- changing the place
- canceling the classes
- browsing existing entries
- removing the entries
- searching/filtering the entries by
- class
- date
- customer data
- The desirable features:
- editing existing entries:
- changing the aerobic instructor
- changing the client data
- searching/filtering the entries by
- place
- viewing the entries by day/week/month
- support for concurrent access to the data
- automatic notification for the clients (e.g. by email) in case of cancellation or changes of the classes
4. Opportunities and risks
The electronic system can provide a quicker and more convenient way of managing the booking. Furthermore, the storing and archiving the data will be more comfortable and secure. We hope to design the system that will allow concurrent access to the registration.The system may also decrese the amount of work required in managing the bookings. Moreover, if the system will be online, it would allow the users the remote managing of the bookings.
The main risks of the new system is that it will be too difficult to use and the user will not be willing to learn the system. What's more, the user may be too used to the old system and even though the new system will be easier and more efficient to use, he/she will not want to switch. Another risk lays in the fact that due to too many available functions, the GUI might become too complicated and not intuitive. The users may also fear the data breach and loss in the new system. In addition, the new system may be too expensive for the users.
As for the risks of the project there is a great danger of falling into fixed way of thinking about the design of an electronic schedule, as there is a lot of existing solutions for similar purposes (e.g. google calendar). Additionally, we may overlook important aspects of the users' work by regarding it as being predictable. An example of another risk is that the user will not be willing to cooperate as we won't implement the solution and they may not be interested in the results. Furthermore, there might be not enough communication between the client and the interviewer or we may run out of time.
The main risks of the new system is that it will be too difficult to use and the user will not be willing to learn the system. What's more, the user may be too used to the old system and even though the new system will be easier and more efficient to use, he/she will not want to switch. Another risk lays in the fact that due to too many available functions, the GUI might become too complicated and not intuitive. The users may also fear the data breach and loss in the new system. In addition, the new system may be too expensive for the users.
As for the risks of the project there is a great danger of falling into fixed way of thinking about the design of an electronic schedule, as there is a lot of existing solutions for similar purposes (e.g. google calendar). Additionally, we may overlook important aspects of the users' work by regarding it as being predictable. An example of another risk is that the user will not be willing to cooperate as we won't implement the solution and they may not be interested in the results. Furthermore, there might be not enough communication between the client and the interviewer or we may run out of time.
Subscribe to:
Comments (Atom)