Simple Elegant UI Livens Up Forgotten Street-Game

The Zurb Crew did it again! During christmas holidays, I received a cute little package from them. Not knowing what to expect, I opened it with anticipation. The package contained two items; an elegant simple Zurb Christmas card, called ‘Rock-Paper-Scissors: Best Two out of Three’ and stack of cards.

The Christmas card suggested me having friendly matches of Rock Paper Scissors with friends or on ZURBword.com! More peculiarly, the stack of cards, drew my full attention. Each card had a colorful beautiful image of a hand, painted in delightful colors, showing hand-gestures of the good-old game of Rock Paper Scissors. As a UX researcher, what was interesting to me was the fact there were no rules or guidelines following the stack of cards. It was as if the users were supposed to figure things out by themselves.

Naturally, and as a user-oriented individual, immediately I started thinking of ways in which users would think and go about playing the cards. I thought of rules, such as ways to distribute the cards among players, the order of players, the number of sets, incentives, and rewards. So, you can imagine how my thoughts started whirling around the idea…

And then it darned me; the beauty of this idea was due to several other reasons:

  • This game was a mirror of an already-existing ‘good-old-street-game’ that simply contained no rules and was already familiar to the users. The user mental model was already established!
  • The innovative colorful presentation of the game made it refreshing, adding additional elements of enthusiasm and fun to an old forgotten game
  • Simple beautiful UIs, can liven up old and forgotten elements in our lives

Here, the Zurb Crew, elegantly, brought one of my favorite (but forgotten) childhood street-games back into my everyday living. And they achieved this by presenting an old idea with simple, yet compelling, beautiful UI. This, I call art!


Two-Way Repeated-Measures in UX

In addition to the one-way Repeated-Measures, ‘Two-Way Repeated-Measures ANOVA’ can also be conducted in UX studies. To show a real example, here is how I did it for my MS thesis…

For the purpose of this study, I conducted a 2 x 3 Two-Way Repeated-Measures ANOVA in order to examine the effects of two levels of search engine,  Traditional Search Engine (TSE) and Social Search Engine (SSE) and three levels of task type, objective, combo, and subjective search queries. The measured variables (or Dependent variables) were time on task, task completion, satisfaction, and emotion for each search query experience.

Abstract
20 participants performed six tasks, each at three levels; objective, combination, and subjective task-levels. Participants used Traditional Search Engine (TSE) and Social Search Engine (SSE) in order to perform the tasks. The purpose of this study was to examine whether SSE improved efficiency, effectiveness, satisfaction, and emotional experiences of users during web information retrieval. The hypothesis was that SSE, as opposed to TSE, would enhance user’s search experience. The results suggested that, while it took longer to find specific subjective information, task completion, satisfaction, and positive emotion was significantly higher using SSE for subjective tasks. In other words, using SSE for subjective queries enhanced effectiveness, satisfaction, and positive emotions of the participants.

Methodology
There were three levels of tasks: objective, subjective, and combination tasks. At each task level two tasks were assigned. Each task were to be performed using both SSE and TSE. The types of tasks were different types of information retrieval tasks at these three different levels. In other words, each participant completed a total of six tasks, presented as six different search queries.

The data sets were coded by time on task, task completion, satisfaction rate, and emotional state. To illustrate how the coding would look like for one case, let us say that a participant, using Traditional Search Engine (Google), took 60 seconds to find the targeted web resource, ended up completing the task, was satisfied with the search results, and felt happy while searching.

If so, the code would look like this:  P1 – TSE 60 1 4 5 

P1 = Participant number one
TSE = Traditional Search Engine (Google)
60 = Time on Task; It took 60 second for the participant to find the targeted web resource
1 =  Task Completion; The participant did find the targeted web resource
4 = Satisfaction Rate; The participant indicated that he/she was satisfied after the search results and their search experience
5 = Emotional State; The participant indicated that he/she felt happy while searching

Having numerical data, it gets pretty straight forward to enter the data into SPSS and to run ANOVA tests. More specifically, it gets pretty accurate to run multivariate tests and paired-sample t-tests in order to examine any statistically significant results. Moreover, one can quite easily determine any Main Effect and/or Interactions that may exist. This, of course, assumes that the data is accurate.

Disclaimer: I am not a Statistician…. just a UX researcher with (college) background in SPSS. My only attempt here is to bring statistical tools closer to UX studies.


Repeated-Measures Design in UX

Reviewing my SPSS notes, I recalled the many aspects where this powerful tool comes in handy in UX studies. Not everyone ends up using it on a regular basis, simply because many of our studies end up being more qualitative and observational. In addition, sometimes it is just hard to wrap your head around it when time/budget pressure keep coming at you left and right. But if we knew simple quick ways of running our analysis this way, perhaps we’d find the results more assuring and useful.

So, here I thought of gathering all my notes and try to come up with simple examples that may help me remember all the useful statistical analysis applications. Let us start with Repeated-Measures Design and go from there. Hope you find this as useful as I did!

What is  Repeated-measures?
Repeated-measures, or Paired-Samples t-test, assesses if the mean differences between paired observations are significantly different from zero. If the difference is zero, then the before and after effects are the same, i.e. there is NO difference between the observations.

How can it be used in UX research?
There are many applications for using repeated-measures, of course, but for the sake of simplicity, I am proposing the following (very) simple example:

Say we have two different products displayed somewhere on our site and we want to measure Findability. We ask the participants to perform the same task of finding product X and then product Y on the site. Assuming all other variables are the same, we have the participants perform the task one after the other. Note: In order to counter balance, we need to change the order tasks, i.e. every other participant first finds product X and then product Y.

After the tasks, we ask the participants to rate their experience on a 7-scale Likert scale, ranging from the product being real easy to find to real hard to find. At the end of the study, we should have two numbers (from 1-7) for each participant; one for findability of product X and one for findability of product Y. This is the reason this test is called repeated-measure… it is because we measure/observe the same participant several times.

How to run the test in SPSS
If the menus in SPSS have not changed drastically, the following steps should do the trick:

  1. Analyze –> Compare Means –> Paired-Samples T-Test
  2. Click on the two variables that you have collected, product X and product Y, and then click the little ‘arrow’
  3. The two variables should appear on the Paired Variables box
  4. Hit OK
Now you should see two tables as a result of this analysis. To keep things simple, the most important part of this table is where it says ‘Sig.(2-tailed)’, which is known as the P-value. If this number is less than 0.05, you have a significant result, which means that the there is a difference between the two observations. In our case, let us say that our P-value is 0.02. In this case, we have a significant result, which means that there is a difference between the two. In other words, one of the products is way easier to find than the other. Now the question is: Which one?

For us to figure out which product was easier to find, we’d need to look at the Mean value. In our case, let us say that low numbers indicated that the participants found it easy to find the product. Therefore, the product with the lowest Mean would be the easier one to find.

And there you have it! A simple case where one can easily use SPSS to run valid statistical analysis.

Disclaimer: I am not a Statistician…. just a UX researcher with (college) background in SPSS. My only attempt here is to bring statistical tools closer to UX studies.

Stupid Questions

In the field of UX Research we work with complex sophisticated emotional human beings who are trying to make sense of what they see on the emotionless screen in front of them. What questions we ask, how and what data we collect, and how we deal with the results is our responsibilities. If we keep asking and listening with focus we may have a better shot at helping evolve the web. If not, why do research in the first place if the goal is not to contribute, enhance, and evolve the body of knowledge?

When I was a kid, as part of my child-job-description, I used to ask a lot of (stupid) questions! By the time I started to grow in size, it was sort of expected of me to stop but I didn’t. Originally, this was not a conscious choice but a natural course into adulthood. Despite teasing of others, I kept asking (some but not all stupid) questions, for the sole purpose of understanding and knowing. With time, gradually, these questions started to solidify, mature, and gear towards one of my passions: the way humans cognitively interact with the web, more specifically information retrieval and the affective search behavior.

Not knowing what I was getting myself into, or why asking questions had become an essential part of me, I kept moving forward and watched how things unfold one after the other. The person who asks (hopefully the right) questions is the one who also hears. Asking and listening are like an inseparable couple. When you ask you must listen. And when you listen you must learn.There is no way around it. You cannot ask and then talk or daydream.

To me, great researchers have specific characteristics. They ask the right questions AND are great listeners. All my hero researchers and scientists appear to have these attributes. Great masters of any field seem to have kept their childish curious minds, while asking questions.

I, for one, have ways to go but for now I am happy to have kept my curious mind who keeps asking stupid questions. This, I believe is a must in our field.


Mental|Conceptual|System Models in UX

On my last ‘IxD for Developers’ talk at Hacker Dojo, I mainly emphasized on the importance of understanding  and differentiating  these models. Essentially, human beings are very different from one another. For this reason, we simply should not design for one type of user and should also not deny the fact that we all think/interact differently. To illustrate, engineers should not think like engineers when developing web or mobile apps. For the most part, in this talk, I tried to raise awareness in terms of designing interfaces that corresponded to user mental models, through better design of conceptual model.

A Summary of Definitions

  • Mental Model – think USER – the model that users have of themselves and of the outside world, formed through interactions, experiences, and instructions, and formed by user’s interpretation of a devise perceived action and its visible parts and structure
  • Conceptual Model – think INTERFACE – the actual model given to the user through the system interface, gives user the ability to mentally stimulate the operation of a system
  • System Model – think APP/DEVISE – how the system works inside, this part is like a Black Box to the user

In order to figure out an app or a devise, users gather several cues from the interface (the conceptual model):

  1. Affordances
  2. Constraints
  3. Mappings

In addition, users first try to mentally stimulate the object operation in their mind! So, imagine if your interface does not give all the clues needed for the user to (mentally) figure out how the device works. Your user is already confused, if not intimidated.

The Convergence Bicycle

This famous bicycle, mentioned by Donald Norman and drawn by Jacques Carelman, illustrates this point excellently. Although this devise is not ‘real’, you are most probably able to mentally stimulate its operation in your mind PLUS you are able to determine that this devise would probably not work. You did ALL that in your head without even touching or trying out the devise.

This illustrates a perfect conceptual model, as it communicates affordances, constraints, and mappings of the devise just through a drawing. And, for this reason, the outcome is a perfect conceptual model where the user is able to immediately tell how this machine is supposed to operate.

Some Fundamental Design Principles

  1. Provide obvious conceptual models
  2. Make things visible (and on the surface)
  3. Make users ‘see’ how things work
To Sum Up
  • Users are NOT interested in System models – they don’t want to know how things work INSIDE
  • System models have too much irrelevant information for the user
  • Users are only interested in Conceptual models because that is what they see and that is what will give them clues as to how the app works
  • Engineers do have control over the design and over the Conceptual model.  So USE IT!
  • Use affordances, constraints, and mappings to give clues to the users
  • If you think of these when designing your work, you will have happy users, which will increase the likelihood of them coming back to your app
Happy Coding and Designing!

Follow

Get every new post delivered to your Inbox.