Tuesday, April 22, 2008
Lessons Learnt in NM4210
With the module coming to a close (submission of softcopy and report is this friday), I must say that the workload for this module is rather heavy. However, it's one of the most interesting module that I've taken in NUS, period.
I got to know and learn all the techniques taught in the lectures. Although Mr. Reddy said during classes that we have seen these methods before, but I have not, heh. Perhaps it's because I'm from SoC, and perhaps these methods are taught in other modules taken by FASS students.
I only knew, survey/questionaire, interview, VBR & focus group b4 hand. But I've got to learn new stuff like cultual probe, laddering, card sorting, 4 pleasures framework, RMA analysis, heuristic evaluation, UX evaluation and the most used item by us throughout the final project, user persona profiling.
The Execution
Learning is one thing, executing is another! We had to learn along the way, what we did right, what we did wrong and adapt from there. Of all the methods, I thought the UX evaluation, 4 pleasures framework and persona profiling as very insightful.
UX evaluation
For UX evaluation, it is really quite straightforward for the testers to evaluate. Just giving and rating on the adjectives. It's something I'll use in the future. But then, the selecting of words used is quite tricky. Some are really closely related, and thus, there's potential biasness or "double counting", making the results incorrect.
Also, the words used might be unclear to the evaluators. Term such like contempt (which we used for Park.a.lot UX evaluation) is a word that we seldom use, and thus cant directly relate to it. Further clarification was needed.
The results from this evaluation is very tangible, i feel. We can relate to the word and the direct scores to it, making it a very fast and efficient way in getting decent feedbacks (emotion) for the product.
4 pleasures framework
We used this framework in analyzing the pleasureness that the prototype can give. It's a rather difficult framework to use though, esp when for ideological and sociological. Till today, I still cant differiente a statement immediately if it came from either category. The former is about values and the latter is about relationships. They sometimes cross each other's path (at least for myself, heh) Then again, I thought this is a really powerful tool to be used, as it covers all aspects, physical, cognitive, relationships and values.
Personas
This method of identifying users for our products is really useful. It really makes things "easier" per se, as this personas prevent us from going into feature creeping, hoping to add more and more, for more and more people. This in turn compromise the system, and thus, not able to satisfy users, which is bad. Most, if not all of our in depth evaluation used personas of our system as evaluators. It's easier to remember these "fake characters" than recalling characteristics that these people possess.
Needs 1st, solutions later
More often than not, we always come up with the solution, and try to squeeze a need into it. Sometimes, that might work, but potentially dangerous. I have really understood the need to KNOW THE NEED, so that we can better cater to the NEED. That's how Park.a.lot actually came about. We really think thoroughly what is needed for drivers, and that came up. Then slowly, our solution is simply matching the needs, enabling viewing of CP info and booking of lots.
I've learnt much from this module, and will definitely keep them in check. Cheers~!
I got to know and learn all the techniques taught in the lectures. Although Mr. Reddy said during classes that we have seen these methods before, but I have not, heh. Perhaps it's because I'm from SoC, and perhaps these methods are taught in other modules taken by FASS students.
I only knew, survey/questionaire, interview, VBR & focus group b4 hand. But I've got to learn new stuff like cultual probe, laddering, card sorting, 4 pleasures framework, RMA analysis, heuristic evaluation, UX evaluation and the most used item by us throughout the final project, user persona profiling.
The Execution
Learning is one thing, executing is another! We had to learn along the way, what we did right, what we did wrong and adapt from there. Of all the methods, I thought the UX evaluation, 4 pleasures framework and persona profiling as very insightful.
UX evaluation
For UX evaluation, it is really quite straightforward for the testers to evaluate. Just giving and rating on the adjectives. It's something I'll use in the future. But then, the selecting of words used is quite tricky. Some are really closely related, and thus, there's potential biasness or "double counting", making the results incorrect.
Also, the words used might be unclear to the evaluators. Term such like contempt (which we used for Park.a.lot UX evaluation) is a word that we seldom use, and thus cant directly relate to it. Further clarification was needed.
The results from this evaluation is very tangible, i feel. We can relate to the word and the direct scores to it, making it a very fast and efficient way in getting decent feedbacks (emotion) for the product.
4 pleasures framework
We used this framework in analyzing the pleasureness that the prototype can give. It's a rather difficult framework to use though, esp when for ideological and sociological. Till today, I still cant differiente a statement immediately if it came from either category. The former is about values and the latter is about relationships. They sometimes cross each other's path (at least for myself, heh) Then again, I thought this is a really powerful tool to be used, as it covers all aspects, physical, cognitive, relationships and values.
Personas
This method of identifying users for our products is really useful. It really makes things "easier" per se, as this personas prevent us from going into feature creeping, hoping to add more and more, for more and more people. This in turn compromise the system, and thus, not able to satisfy users, which is bad. Most, if not all of our in depth evaluation used personas of our system as evaluators. It's easier to remember these "fake characters" than recalling characteristics that these people possess.
Needs 1st, solutions later
More often than not, we always come up with the solution, and try to squeeze a need into it. Sometimes, that might work, but potentially dangerous. I have really understood the need to KNOW THE NEED, so that we can better cater to the NEED. That's how Park.a.lot actually came about. We really think thoroughly what is needed for drivers, and that came up. Then slowly, our solution is simply matching the needs, enabling viewing of CP info and booking of lots.
I've learnt much from this module, and will definitely keep them in check. Cheers~!
Friday, April 18, 2008
Final Project: Design for UX VIIII
Phase 4: Evaluation (Hifi proto and UX evaluation)
Park.A.Lot just presented the final version of the proto and evaluations on tuesday. It was really work till the end.
As we did not present user testing last week, we decided to combine user testing and UX evaluation together~ via think aloud protocol (tasks scenarios given) and questionaire (based on likert scale) on emotions and pleasures.
We started work on the 2nd version very much after the presentation on phase 3c. As our intention is to come out with the 2nd version asap, and conduct the 2 evaluations, and then do some final coding and tweaking based on the evaluations.
We came out with the main purpose and objectives for our studies.
Main purpose
To evaluate whether our Hifi prototype is able to provide both functionality and user experience
Sub Objectives
Does the UI affect their surfing habits?
Are they able to complete the tasks efficiently?
Are they able to adapt after a while?
...
User evaluation + UX evaluation
The overall plan is to ask 6 testers to go through our user testing. Thru the testings, they are better exposed to the appearance/visceral feel and asethetics of the website. More importantly, the interaction between the system and the testers.
We felt that this is a better way, as compared to simply asking people to test our site aimlessly, and simply based on asethetics. The latter can be achieved with static images or graphics. Our ultimate goal is to test functionality + UX combined.
Evaluators
There's a total of 6 evaluators (3 advance 3 novice). 1 advance and 1 novice is grouped into 1. Therefore, there's 3 groups of 2 evaluators each (1 advance, 1 novice).
Part 1: User testing
There is a total of 3 tasks. Each group will be required to perform 1 task.
Task 1 (for grp 1)
Task 2 (for grp 2)
Task 3 (for grp 3)
Results
In short, NO MAJOR HICCUPS! tat was quite a pleasant surprise for us. There were some minor issues though. Such as for grp 2, the novice wasnt sure of any nearby carparks near Plaza Singapura and struggled to think of 1. We then hinted that there's the "nearby carparks around XXXXX" function. It was then smooth after that.
Part 2: UX evaluation
There's 2 fold to our UX evaluation. Mainly, measuring Emotions (circumplex of emotions) and Pleasures (likert scale questionaire based on the 4 pleasures framework that we studied in the earlier assignment)
a) Emotions
Evalutors are to rate (scale of 1 to 5, from strongly disagree to strongly agree) on 12 main adjectives (6 good 6 bad, mixed together)
6 positives
Park.A.Lot just presented the final version of the proto and evaluations on tuesday. It was really work till the end.
As we did not present user testing last week, we decided to combine user testing and UX evaluation together~ via think aloud protocol (tasks scenarios given) and questionaire (based on likert scale) on emotions and pleasures.
We started work on the 2nd version very much after the presentation on phase 3c. As our intention is to come out with the 2nd version asap, and conduct the 2 evaluations, and then do some final coding and tweaking based on the evaluations.
We came out with the main purpose and objectives for our studies.
Main purpose
To evaluate whether our Hifi prototype is able to provide both functionality and user experience
Sub Objectives
Does the UI affect their surfing habits?
Are they able to complete the tasks efficiently?
Are they able to adapt after a while?
...
User evaluation + UX evaluation
The overall plan is to ask 6 testers to go through our user testing. Thru the testings, they are better exposed to the appearance/visceral feel and asethetics of the website. More importantly, the interaction between the system and the testers.
We felt that this is a better way, as compared to simply asking people to test our site aimlessly, and simply based on asethetics. The latter can be achieved with static images or graphics. Our ultimate goal is to test functionality + UX combined.
Evaluators
There's a total of 6 evaluators (3 advance 3 novice). 1 advance and 1 novice is grouped into 1. Therefore, there's 3 groups of 2 evaluators each (1 advance, 1 novice).
Part 1: User testing
There is a total of 3 tasks. Each group will be required to perform 1 task.
Task 1 (for grp 1)
- To book a lCP ot at plaza singapura the night before movie
- Bought movie tickets (Plaza Sing)
- Scenario:
- Lots will be available for booking at Plaza Sing
Task 2 (for grp 2)
- To book a lot at plaza singapura, 2 hours before show time
- Bought movie tickets (Plaza Singapura)
- Scenario:
- Lots fully booked at Plaza Singapura
- Look for alternative car parks
Task 3 (for grp 3)
- To go to a mall, that has ample lots, for lunch
- Scenario:
- To evaluate normal viewing of car park information
Results
In short, NO MAJOR HICCUPS! tat was quite a pleasant surprise for us. There were some minor issues though. Such as for grp 2, the novice wasnt sure of any nearby carparks near Plaza Singapura and struggled to think of 1. We then hinted that there's the "nearby carparks around XXXXX" function. It was then smooth after that.
Part 2: UX evaluation
There's 2 fold to our UX evaluation. Mainly, measuring Emotions (circumplex of emotions) and Pleasures (likert scale questionaire based on the 4 pleasures framework that we studied in the earlier assignment)
a) Emotions
Evalutors are to rate (scale of 1 to 5, from strongly disagree to strongly agree) on 12 main adjectives (6 good 6 bad, mixed together)
6 positives
- Inspiration
- Desire
- Pleasant surprise
- Fascination
- Amusement
- Satisfaction
6 negatives
- Disgust
- Unpleasant surprise
- Disappointment
- Contempt
- Dis-satifisaction
- Boredom
b) Pleasures
Likert scale questionaire on 15 questions, categorized into physiological, psychological, sociological and ideological
1 e.g. for each:
Physiological
I enjoy navigating the website
Psychological
I feel a sense of achievement on being able to book a lot online
Sociological
I will feel proud when my peers know that I use this novelty service
Ideological
I feel like I have the control of time management
c) Results
Emotions: Inspiration scored the highest, of a perfect score 5! followed by fascination (4.67) and satisfaction (4.33). The lowest were boredom and disgust (1 - strongly disagree)
Pleasures: We scored highest on Psychological and ideological, which we were really happy with.
However, i must admit, a more indepth study, with more evaluators, are needed to really, and truly, determine whether our site is both functional and provides UX.
Demo of proto
We ended the presentation with a short presentation of our demo. Not exactly complete, or not exactly bugfree, but it was a good representation of what we set out to achieve. We were happy with the output and response that we gathered after the presentation. We'll improve on it slightly to complete the high fidelity prototype and give the module a nice closing. :)
Final Project: Design for UX VIII
Phase 3c: Design (Hifi proto, heuristic & user testing)
We had to rush our hifi out by weekend, so that we could be able to do our heuristic and user testing. However, as murphy's law (not really ah, just that we wanted to do a realistic hifi proto), we had to spent much time on doing the asethetics out. We also had to change some of the layout.
We knew then, that we are not able to complete a "complete" hifi flash proto. Thus, we did a static version, but with graphics that are as close as our intended version. Below is what we came out with, the 1st draft of hifi proto. As we only have time for one evaluation (prep and execute), we chose to conduct heuristic evaluation + (4 targetted personas, 2 advance 2 novice) 1st, and snowball user testing to the next week (blessing in disguise will explain in design 4)
Heuristic 2: "Match between system and the real world"
one pointed out that the information button "2nd button on the navi bar" as shown above, is somewhat conflicting the 1st button. Both terms are widely used and understood as the "same meaning". Therefore, we decided to change it to "Carparks", as it was meant for the viewing of carpark information.
Heuristic 8: Asethetics & minimalistic design
Negatives
This heuristic gave us much problems, in my opinion. As we wanted to venture into providing a better UX, and really wanna find out whether a slightly more animated and graphics based website can give that. But based on feedback, it wasnt what we expected.
Positives
However, all is not lost. They are able to spot the consistency of colors used, our corporate colors, black red white. That helped saved us from "failing" of this heuristic, heh.
Heuristic 9 & 10: Help users and help documentation
We knew that our website might potentially need some "adapting to" by some users, and its not exactly the most "user friendly" site, esp for first time users. Even for IPOD, which is a simple design, you do suffer a bit during the initial use, such as browsing us the wheel and thumb, the organising of cateogries etc. Therefore, we placed the HELP button quite prominently (the 4th button). This is to aid users that might potentially stuck while using (that's the extreme case).
The next deliverable (final one) is the 2nd version of hifi proto, user evaluation and UX evaluation)
We had to rush our hifi out by weekend, so that we could be able to do our heuristic and user testing. However, as murphy's law (not really ah, just that we wanted to do a realistic hifi proto), we had to spent much time on doing the asethetics out. We also had to change some of the layout.
We knew then, that we are not able to complete a "complete" hifi flash proto. Thus, we did a static version, but with graphics that are as close as our intended version. Below is what we came out with, the 1st draft of hifi proto. As we only have time for one evaluation (prep and execute), we chose to conduct heuristic evaluation + (4 targetted personas, 2 advance 2 novice) 1st, and snowball user testing to the next week (blessing in disguise will explain in design 4)
We based our evaluation on Jakob Nielson's model - the 10 heuristics
Heuristic 2: "Match between system and the real world"
one pointed out that the information button "2nd button on the navi bar" as shown above, is somewhat conflicting the 1st button. Both terms are widely used and understood as the "same meaning". Therefore, we decided to change it to "Carparks", as it was meant for the viewing of carpark information.
Heuristic 8: Asethetics & minimalistic design
Negatives
This heuristic gave us much problems, in my opinion. As we wanted to venture into providing a better UX, and really wanna find out whether a slightly more animated and graphics based website can give that. But based on feedback, it wasnt what we expected.
It was too graphics intensive, and the usage of different cars on different page, was distracting. I think that we went a bit overboard, and it was a good reality check for us, the designers. This gives us a very good platform to gauge what we will be churning out for our 2nd version (flash based)
Positives
However, all is not lost. They are able to spot the consistency of colors used, our corporate colors, black red white. That helped saved us from "failing" of this heuristic, heh.
Heuristic 9 & 10: Help users and help documentation
We knew that our website might potentially need some "adapting to" by some users, and its not exactly the most "user friendly" site, esp for first time users. Even for IPOD, which is a simple design, you do suffer a bit during the initial use, such as browsing us the wheel and thumb, the organising of cateogries etc. Therefore, we placed the HELP button quite prominently (the 4th button). This is to aid users that might potentially stuck while using (that's the extreme case).
The testers knew where the HELP button was, which was good. But they cant test it, as there wasnt much "errors" to be occured in this draft version. But, it was a good feedback anyway.
The next deliverable (final one) is the 2nd version of hifi proto, user evaluation and UX evaluation)
Final Project: Designing for UX VII
Phase 3b: Design (Analysis of paper proto)
We conducted our paperprototype user walkthru and analysed what our tester said. And they were really accurate in spotting mistakes and to helpful. Perhaps becos they are rather IT savvy. It was great for them to be critical, such that we could develop our hifi prototype easier and faster.
As it was on paper, the proto was not able to give out errors or feedback, thus users cannot test that portion. However, the testers pointed out some stuff. Such as,
- there's no next or back button (we didnt/forget to add that) when booking
- they didnt understand what is "book-a-lot" (which is part of the navi bar link for booking)
- some was confused with the words, "News" and "Announcements" (suppose to be the same thing)
- layout was somewhat weird (we intend to use more graphics then the usual static sites. It's quite difficult to convey our "flash idea" to them, esp on paper. Although this was against what our initial studies have told us. They preferred clean, simple but pleasing site. But we felt that it might not be able to give a good "UX". We decided to do a "out of the box" approach, and do the testings that will either slam or support our intentions. )
Its good to have the small little things ironed out, as they are usually hard to spot as designers. We tend to "assume" a bit (just a bit. heh)
Presenting to Mr. Reddy
We were required to inform our lecturer about our progress, findings and what we have did so far, based on our paper prototype. We summarised some quick pointers of our analysis to him and it ended quite quickly. I guess so long as our team is progressing, it should be ok. Also, its rather hard to present the findings of the paper prototype (not that its not important), or spend time preparing to present the paper, as we are heading to produce the hifi proto within a week (and conduct heuristic and user testing!)
Friday, March 28, 2008
Final Project: Designing for UX VI
Phase 3b: Design (On paper prototyping)
Paper prototyping has been a well known and widely used technique to test navigation and usability. However, I'm still curious as to why it is still so successful, even in today's context.
I chanced upon this website that i feel was quite useful. It answered some of our project's issues (and my doubts). Its called, "Five Paper Prototyping Tips" (http://www.uie.com/articles/prototyping_tips/)
Here's the 5 rules/tips mentioned, which i feel is very relevant, and some key takeaways from the site:
1. I’m proficient with HTML. I can create a working prototype fairly quickly. Why would I want to use paper prototyping?
"changes can be made on the fly during a test"
With just an eraser and pencil, changes can be done quickly. What I liken about paper prototype is that, its PORTABLE. It can be tested on the go, on the bus, mrt and places without internet connections etc.
"users feel more comfortable being critical of a paper prototype"
I think it's very true, esp for myself. I will usually not critise people's work, esp when you see them spent so much time and effort doing it. But when presented on paper, it feels more comfortable for me to voice out something that I feel is somewhat not right.
"With paper, all the team members can gather around one table with their eyes on the same design"
Very good point! I'm sure most of the peers experience this. Whenever there's project meeting, and when each of the individuals' lappy is on, there will usually be no focus on discussion. Everyone will be doing their own thing, and usually, one 'facilitator' needs to step up and get everyone's attention. Thus sometimes, I prefer meetings without lappies, or with lappies off. :)
2. How can I use paper mockups to test new technology? Trying to mimic Macromedia Flash using paper mockups sounds like a nightmare—and how would we create rollovers?
"The goal in testing a prototype is to create a usable site"
As the project requires interactivity, we will most likely turn to flash as part of our designing tool. So we faced a similar question on how to present visual that we intended to do, on a paper. Is it necessary? I guess not so, perhaps just a rough one.
"The inability to prototype a fancy effect on paper may be a warning that the effect is not usable"
I kinda 'disagree' though. It might not be usable per se, but it might have additional effects, such as UX.
"Users often choose a link to click on before seeing the associated content in a rollover"
True and not true. Some sites are really straight forward. But there's some whereby the links are actually 'pictures' embedded into the background. I cant help but just move my mouse around the screen and see is there any animations played (indication of a button).
"Paper mockups don’t need to incorporate all the frills of technology"
We will keep this in mind. :)
3. Our product has been up and running for a while. Why go back and create mockups to test an existing product? When should we start from scratch with paper?
(omitted for the purpose of this project)
4. How do you create a prototype that relies on a database? Do you create fake accounts? It seems like a ton of paperwork.
"it’s often impractical to have lots of data available"
As our team proposes a site that has a huge database of car parking info and booking data, i'm glad i read this statement. heh.
"In cases where users must look up data that is not provided in a prototype, we create tasks in such a way that we can predict the data"
As mentioned in the article, make testers do specific items, for our case, a specific car park.
"When a user enters real data into a field and the data needs to appear somewhere else later, we rely on sticky paper"
This will come in handy for stuff like registration page, or booking page.
5. It’s not easy to make links look like links in a prototype. How do you help users identify a link?
"If we see users click something time and again that isn’t a link, it’s clear what’s needed—make it a link"
Biggest takeaway.
Paper prototyping has been a well known and widely used technique to test navigation and usability. However, I'm still curious as to why it is still so successful, even in today's context.
I chanced upon this website that i feel was quite useful. It answered some of our project's issues (and my doubts). Its called, "Five Paper Prototyping Tips" (http://www.uie.com/articles/prototyping_tips/)
Here's the 5 rules/tips mentioned, which i feel is very relevant, and some key takeaways from the site:
1. I’m proficient with HTML. I can create a working prototype fairly quickly. Why would I want to use paper prototyping?
"changes can be made on the fly during a test"
With just an eraser and pencil, changes can be done quickly. What I liken about paper prototype is that, its PORTABLE. It can be tested on the go, on the bus, mrt and places without internet connections etc.
"users feel more comfortable being critical of a paper prototype"
I think it's very true, esp for myself. I will usually not critise people's work, esp when you see them spent so much time and effort doing it. But when presented on paper, it feels more comfortable for me to voice out something that I feel is somewhat not right.
"With paper, all the team members can gather around one table with their eyes on the same design"
Very good point! I'm sure most of the peers experience this. Whenever there's project meeting, and when each of the individuals' lappy is on, there will usually be no focus on discussion. Everyone will be doing their own thing, and usually, one 'facilitator' needs to step up and get everyone's attention. Thus sometimes, I prefer meetings without lappies, or with lappies off. :)
2. How can I use paper mockups to test new technology? Trying to mimic Macromedia Flash using paper mockups sounds like a nightmare—and how would we create rollovers?
"The goal in testing a prototype is to create a usable site"
As the project requires interactivity, we will most likely turn to flash as part of our designing tool. So we faced a similar question on how to present visual that we intended to do, on a paper. Is it necessary? I guess not so, perhaps just a rough one.
"The inability to prototype a fancy effect on paper may be a warning that the effect is not usable"
I kinda 'disagree' though. It might not be usable per se, but it might have additional effects, such as UX.
"Users often choose a link to click on before seeing the associated content in a rollover"
True and not true. Some sites are really straight forward. But there's some whereby the links are actually 'pictures' embedded into the background. I cant help but just move my mouse around the screen and see is there any animations played (indication of a button).
"Paper mockups don’t need to incorporate all the frills of technology"
We will keep this in mind. :)
3. Our product has been up and running for a while. Why go back and create mockups to test an existing product? When should we start from scratch with paper?
(omitted for the purpose of this project)
4. How do you create a prototype that relies on a database? Do you create fake accounts? It seems like a ton of paperwork.
"it’s often impractical to have lots of data available"
As our team proposes a site that has a huge database of car parking info and booking data, i'm glad i read this statement. heh.
"In cases where users must look up data that is not provided in a prototype, we create tasks in such a way that we can predict the data"
As mentioned in the article, make testers do specific items, for our case, a specific car park.
"When a user enters real data into a field and the data needs to appear somewhere else later, we rely on sticky paper"
This will come in handy for stuff like registration page, or booking page.
5. It’s not easy to make links look like links in a prototype. How do you help users identify a link?
"If we see users click something time and again that isn’t a link, it’s clear what’s needed—make it a link"
Biggest takeaway.
Thursday, March 27, 2008
Final Project: Designing for UX V
PHASE 3b: Design
Just had a discussion with boon and min for next week's 3b deliverables. They are mainly,
Just had a discussion with boon and min for next week's 3b deliverables. They are mainly,
- conceptual design
- paper prototype
- user walkthrough
- analysis
We are all rather excited to see how the website will turn out to be. Anxious is the word. It's ways nice and fun and we reach the 'implementation' stage of the design, where we put our knowledge into practice. Hopefully in 2 to 3 weeks time, the prototype is ok looking and decent to use. :)
Conceptual Design
We're heading back to 'basics' for this part, looking into how we can design our website into one which is both usable and has UX. Not easy. We'll most likely take into consideration Norman's theories in designing. Lots of issue to discuss and design. Visual, navigation, visibility, affordances and others.
Paper Prototype & User walkthru
We chose this as our low fidelity prototype. Although i think that doing a high fidelity prototype of our website might be more suitable, but time is not on our side. High F enables a more complete user research and analysis, and allows users to have a better feel to the final prototype. Paper wise, we cant get as much out of it, but something is better than nothing, heh. At least they can roughly "navigate" through our system while we study them.
Our PAL team is pretty much packed this week with our other modules' submission and quizzes. So not much choice but to stick with paper. We'll be coming out with something like this: (but neater :) )
Analysis
I'll post this part once we conduct our user walk thru this weekend. Till then...
Subscribe to:
Posts (Atom)
