GA’s User Experience Design Immersive Retrospective: Week One
I recently started General Assembly’s User Experience Design Immersive course in Singapore, run by luke ↬ miller. It runs for 10 weeks, and we’re tasked to write a retrospective each week. Here’s how week one went down.
The “I” stands for Immersive.
Week one was all about an introduction to both UX design and rapid prototyping. We learned about methods of design research and development, and the major tools we’d be using for the week that culminated in the first personal project was the Double Diamond model and the 4 lists method.
We were each assigned a problem to research at the end of day one, and I received the topic of “To-do Lists”. By day two, most of us assigned to the topic come to the conclusion that “To-do Lists” was more of a solution or a product than a problem, and the problem lay more in the realms of memory and remembering things, so I decided to begin my research and interviews based on that instead.
“Tell me more…”
We started doing user research first on each other, using the Four Lists method (developed by Jennifer Brook and our instructor Luke Miller) as a guideline to categorise our user responses into initial groupings based on their pains, pleasures, contexts and behaviours relating to the research task (in this case, remembering).
This became the basis for the questions I’d start asking in my user interviews, from which I’d branch out and start asking about specific points they made within their answers.
One of the useful things I learned was allowing my interviewees to expand on their points without guiding or leading them towards any specific end-point that I had in mind, since that would bias the data significantly. Using neutral prompts to tease information out is helpful (e.g. “tell me more”, “why is that”, “when would that happen”), but sometimes the urge to contextualise questions to elicit more response is tempting, and is a habit I foresee taking a while to correct.
Another thing I found interesting was observing the various interview methods that my classmates were using. I personally used an open-ended questionnaire to get initial answers and then used that as a base for further inquiry, while others used a running dialogue to source their data.
As a mental note, something I might do in the future is record the audio from the interviews so that I can review it later, since pausing to record data can be cumbersome and disrupt the flow of the interview if I’m the only one doing it.
See what sticks
The next step was to take the responses from the interviews and organise that into an affinity map and elicit a problem statement from grouping the data. I’ll admit that among the things we did this week, this part was the most difficult for me, because the patterns weren’t immediately evident to me, and even after reviewing it there are still multiple outcomes I could gain from reorganising the affinity map.
In the end, the affinity map I settled with revealed the following problem statement:
During my day, I need something to quickly and constantly help me recall the plans I’ve made so that I can complete them on time.
The conclusions I came up with were that if users had a way to quickly and constantly remind themselves of a task, they could complete them. From my interviews I couldn’t truly find a pattern with regards to time; people need to remember things at all times of the day.
Day three during Task Analysis and Sketching, I combined several of my findings into my paper sketch, namely:
- Images jog visual memory and help people remember things. Most to-do apps wouldn’t allow you to create an image-only to-do item, or not in an elegant fashion.
- An option to “nag” busy users throughout the day might help them remember what they’re supposed to. The de facto Reminders app for iOS doesn’t have a multiple reminder alarm function, and you can’t duplicate items. (Of note, the default iOS UI doesn’t allow for selection of multiple alarms for reminders, or repeat items under 24 hours.)
Breaking a few eggs
At this point I had a rough prototype sketched out on paper and tested it.
It failed spectacularly.
The issues I had in my first iterations were based on my sketching of the UI and not being observant to interface design. My initial subject was confused about input of dates and times, where I didn’t think to follow and depict the default iOS input method. Subsequent subjects pointed out to me that there was no button to proceed, and that UI elements were unclear or confusing.
Another challenge I faced was that my prototype UI, perhaps, made things too open-ended for the user. I made a conscious decision in the first few tests to not describe that the app that they’d be testing in full, and that it could accommodate image-only to-do entries. Most of them didn’t get it initially (perhaps from the fidelity of my prototype or sketch, I’m undecided).
In the future, I’ll have to reconsider my experimental design and testing methods during this usability testing phase, especially with regards to being more meticulous with flow design.
The designer as the rapid prototype
“The burned hand teaches best. After that, advice about fire goes to the heart.”
― Gandalf, The Two Towers by J.R.R. Tolkien
By the end of class on Thursday, I’d made so many mistakes, actual and perceived, that I think I hit a wall in my iteration phase. I was thinking about my research phase and my design phase and reflecting on what I should have done differently. It was exhausting.
Exhausting, and enlightening.
Looking back at this week of learning about rapid prototypes, I’ve had to become one myself: constantly iterating my perceptions, methods, ideas and directions in trying to understand and match the pace of learning. I’ll be honest and say that I was fairly unprepared for the amount and intensity of learning and practical work that greeted me from day one, but it’s been thoroughly satisfying.
The first problem for all of us, men and women, is not to learn, but to unlearn.
― Gloria Steinem
On a personal note, I’ve always found making and recovering from mistakes the hardest things I’ve had to do. It’s no surprise then, that having to make mistakes as a matter of course would seem so foreign and exhausting to me. The two quotes I’ve put in this section sum up the issues I’ve had with learning: the first from Tolkien, which has stuck with me forever, and the second which Luke shared during class this week. This week, in the second quote, the fire of the first finds new and different meaning, and I look forward to making more mistakes in time to come.
To end off, my classmates and I had this consensus that the five days of class we attended (and I’m tempted to say endured) has felt like far longer. Planning the material for this retrospective has made me realise just how much we’ve done and covered, and even more so when, over drinks on Friday, Luke congratulated us on becoming UX designers and researchers. It felt strange to suddenly bear that title.
Now I have nine weeks to see if I can live up to it.