Weekly notes — part 2
So far I have managed to keep to my proposed weekly schedule for exactly zero weeks, which sucks. I have now set a calendar reminder so that at least I don’t forget.
The quote of today comes from an episode of UX Podcast, I don’t remember which episode or who was speaking but this is what I wrote down:
Task accomplishment =/= goal fulfillment
When designing, user testing and analysing data, the focus usually lies on task completion. How many people managed to book tickets for a show, to checkout their shopping cart, to sign up for something. If users are indeed able to do thse things the conclusion usually is that the interface is good because they were able to reach their goal. But is their goal really to complete a task? No it isn’t. The user’s goal is to see a show, buying tickets on a website to be allowed in is just something they need to do to fulfill their actual goal.
Being able to easily checkout your shopping cart is nice, but if the products don’t arrive on time for when you need them, which is the reason you were buying the products in the first place, is an unfulfilled goal. When that happens it’s a bad experience, no matter how easy your interface was to use or how little friction there was.
Why this stood out to me
At work we have always valued the user’s goals and doing the best we can to help fulfill them, but the problem is we usually don’t know if a goal is fulfilled since we measure task completion. Say the goal of a teacher is to build a good course on our platform, we consider that goal fulfilled once he created a course, structure, filled it with material and there are students moving through it. Task completed. But is it a good course? We don’t know.
At that point we don’t know what the teacher considers a good course, what the students consider a good course, if they are happy with the material and the level of the course, et cetera. The quality of the course was important to the teacher and we don’t help measure that.
How to find the goals
To make sure we’re measuring the right things we have to know the goals, the only problem is that our users’ goals vary a lot. They are different people, their didactic models are very different and their course subjects are different. What I want to try out is asking users during research what their goals are for a certain feature. That goal might not have anything to do with the feature other than being a possible means to an end, which is fine. I hope having those goals clear we don’t easily lose track of why we are creating something the way we do, and if certain things are in there because people need it or if it’s in there to help fulfill a goal that we already fulfilled somewhere else. The goals are the bigger picture, what is the feature and why, and the task completion is somewhat smaller, more in the realm of how to operate the feature and usability testing.
A while ago I created a template for myself and the product owner to fill in for each feature, which contained the basic information about the idea and the design. The use of this was that when we would revise a design from a year ago, we could easily see what information we had back then en why it’s designed like thise. Those things are easy to forget after a while so I wanted to write them down. A section in there is ‘key goals and actions’ for each user group, which is exactly what we would need for this.
My course of action for this is making sure to always properly fill out that template and make sure to keep an eye on it throughout the project, especially towards the end, so that we don’t forget the goals through all the small interactions and features.
