Redesigning a Kiosk and Learning from my Own Mistakes

I recently started a campus job at the front desk for our tutoring center to earn some extra $$$ while in school. The everyday observation of students struggling with our appointment booking kiosk slowly drove me crazy. The good news is that I happen to be a UX designer, so I’m redesigning it (LOL).

Here are the two major pain points observed:

1. users have to swipe their student ID cards/sign in to view a tutor’s schedule; if they want to see multiple tutors’ schedules, they will need to back out and swipe for each of them.
2. users will get jumped back to the homepage without warning, if they click “go back” on certain pages during booking; when this happens, users have to re-enter all data they have entered before.

//What does this mean:

The above pain points together basically mean that, if I want to book an appointment, I will click through everything and swipe my card to view if tutor A can help me today. If A’s schedule does not work for me, I will have to start all over again from the beginning even though the button I clicked on says “go back”. And, I would have to swipe my card again to see B’s schedule. Of course, if B’s time does not work, I start from the beginning again.

This is quite annoying, since when I click on “go back”, I would expect the previous screen show up, not the homepage. Also, having a user swipe/sign in every time they want to see ONE tutor’s availability is not efficient (NN/g heuristics: user expectation & efficiency).

I. SCOPING

Plan A: Card Sort

I interpreted the above as a user flow issue. To come up with a solution, I first started a content inventory and tried to do card sort.

This strategy turned out to be a total FAIL, mainly because there’s no secondary navigation for the kiosk. So…I ditched the formal “class-taught” information architecture (IA) methods quickly and took a more robust approach — analyze the user flow.

Plan B: Flow Analysis

So I laid out the existing user flow — which is problematic— on the current design, and two conceptual user flows that can possibly solve the problem.

Here is the current user flow…

Image one: current user flow.

And, here are two conceptual mental models that would make more sense for the user…

Image Two: Conceptual mental model one.

Image Three: conceptual mental model two.

The only two differences between these two models are that:

1. in Mental Model One, the student has to look for the next availability manually; while in Mental Model Two, the system will automatically display the next available tutors.
2. in Mental Model One, there is no exit warning if students are exiting the booking cycle during booking. In Mental Model Two, if students already pick the time slot, click “back to home” will trigger a warning popup before jumping them to the homepage.

Initially, I was going to create two wires for the mental models, then A/B Test to see if features in mental model two should be kept. However, during prototyping, I realized A/B Testing would be unnecessary (YES, ANOTHER FAIL🤦‍♀️. Rather than A/B Testing, using a cognitive walkthrough is good enough to tell that Mental Model Two is more user-friendly.

II. DESIGN

I planned to use the existing design system already. That means all I need to do was rearranging a couple of buttons and pages so we can get closer to Mental Model Two. Given this impression, I jumped directly to Sketch and thought this would be a “quick job”. Soon enough, I failed the third time🤦‍♀️ — I found myself constantly thinking about the layout and the digital design at the same time. This was not quick at all, my cognitive load was heavy and could not design at my max.

So I reverted to the sketchpad.

Image Four: sample sketches.

Then, I turned sketches to digital mid-fi wires in Sketch.

Image Five: AFTER — students can directly see who’s available next after indicating subjects for tutoring.

Image Six: BEFORE—tutors list shows even “off-duty” tutors which would ask the student to manually figure out who’s available.

III. TESTING

Then the next step would be testing with users. Testing at this stage would allow me to verify existing assumptions and designs before putting more effort into the high-fidelity prototype.

I used Maze for testing and asked the users to:

1. book an appointment with the new design;
2. then book another appointment using the old design.

I also collected subjective ratings on the east-of-use on both tasks. At the end of the test, I asked testers to compare both designs and share any comments they have per their experience.

I found that among all 8 valid inputs:

1. all users can finish booking with both the new and old design;
2. the new design is easier to use than the old design (ease-of-use rating median=4 vs. 2);
3. when talking about the design, 4 participants said that the new design is more intuitive and 2 users indirectly supported the new design by expressing their confusion on the old design.

“The first one is way faster than the second one, and (personally) I don’t find useful to have the face of the tutor instead of more valuable information to pick or select them.”

“Second design feels weird. Unexpected actions and button placements.”

This means that the redesign is definitely improving usability. YAY 🥳.

What’s next?

It is great to see that my redesign is solving the problem. However, I think the unexpected hiccups are more meaningful.

To recap…

1. I fell on my face first by trying to overanalyze with content inventory and card sorting with straightforward information architecture. The lesson here, DO NOT overanalyze, or even if you do, act fast and pivot when you realize you need to.
2. then I tripped again by trying to A/B Test two wireframes when one is clearly better than the other. I guess you can still do two versions, but in reality, speed and recourses matter. If an expert evaluation/cognitive walkthrough can trim off some workload, use it!
3. finally, I made the wrong decision to skip sketches. okay, if the design system is mature enough, skipping low-fi to high-fi might be possible. However, always skipping sketching does not seem like a good idea. I tried, and really, designing and doing digital maneuvering at the same time did not work for me.

I think these lessons may or may not work for everyone or even every project. But indeed, this personal project helped me improve my workflow and figure out my design style a lot. I think that’s another important lesson here as a junior UXer — find out what works for you.

Hope this is helpful and see ya next project. 😊