UX Challenge 2021 Case Study / Design of a software interface to improve the experience of taking remote classes at University

KEYWORDS: UX DESIGN, USABILITY TESTING, PROTOTYPING, UI DESIGN, INFORMATION ARCHITECTURE, USER FLOW, INTERACTION DESIGN

In February 2021, I was selected to participate in the UX Challenge, a yearly Design Sprint hackathon happening in several cities, at European scale, that has the aim to help companies innovate the User Experience of their digital products and services; I took part in the challenge in Trento, Italy, organised by Hub Innovazione Trentino (HIT).

Well, not only did I participate, I won it, together with my team-mates! And, for the first time in my life, I found my beardy face posted around online.
Regardless of this amazing result, I still feel that I wanted to share the summary of this experience. As a matter of fact, those unforgettable 5 days really marked my first steps in the UX design world. I will credit my teammates and mentors whenever it is due (let me tell you straight away: they were all amazing) but of course I will focus on my own experience and the main takeaways I got from the challenge.

Description of the company and problem they had

We were assigned to a company, TxC2, which is a local startup in Trentino Alto Adige operating in the field of educational technology. The people at TxC2 were building an amazing product that would have made life for students attending classes remotely much easier: D.a.d.dy, an artificial intelligence-based tool that allows students to personalize their learning experience. By using machine learning algorithms, the product is able to create ad-hoc videos of classes by eliminating dead moments and by dividing the class by topics and specific keywords, thus making the job for students rewatching the classes much smoother and efficient.
Only, while the solution could already work, it lacked a real UI and UX - specifically, what needed to be redesigned was the entire interaction flow, from when students open the product to when they actually rewatch classes, and the general look and feel of the interface of the software.
During the course of the challenge, we were in constant contact with the company - and thatwas great, as not only it was important to get feedback from them, of course, but especially because it allowed me to get some first hand experience with dealing with important stakeholders in a real design project.
After we met with the companies and understood what they were looking for, we could startworking. I will share the process by going through each phase of the design sprint. At the end, I will share my main takeaways from the experience.

Day one / Map the problem

The first day of the sprint was very hectic, to say the least. We used the HMWs (“How might we”) tool to brainstorm about possible ideas we could have about the product. Problem was, because we were inexperienced with UX, we started thinking about features and trying to go for solutions directly. I think every inexperienced designer does that, naturally; Stefano Bussolotto, one of our mentors, noticed that we were facing some frustration. He told us “You need to stop thinking about functions, that’s what an engineer would do. Designers think about USERS first”.

This simple phrase made me realize what we needed to do; it felt like a click just went on. Together with the team, we started to focus on the users and we created user journeys and conducted proto-research by asking some questions to other students we knew, just to start gathering some information about what students would typically do when taking remote classes. We came back to the HMWs, much more focused, and I feel we were really starting to make sense out of the problem.

We came up with two different flows that needed addressing: the online and offline flows for the software.

Day two / Ideate the solution

The next day, we worked on the HMWs that we produced and we started thinking about possible solutions - but only in the form of sketches. Again, jumping straight to solutions is just inefficient and doesn’t yield the desired results; sketches were perfect for this phase. Each one of us sketched some UI solutions that we could create, and we had a vote to determine which ones were best. One of my ideas was voted as second best. Here is my sketch that was voted by other team-mates:

We put together my idea and the one from Alessia. Now we knew what we had to work on, and the next day was the prototype day. My favorite one!

Day three / Prototype

Prototyping is something that I really enjoy. I love sitting down,  opening my favorite design software, and just spending as much time as needed in order to try and create the best solution. And that is what I did. I drew from my past experiences with Figma and I just started designing; only, this time, I didn’t feel like I had to do something particularly pleasent in visuals (like I used to do in my experiments), but I had to create interfaces to solve an actual UX problem, that is the experience that people would have with the software that the company wanted to build.
And I took on the challenge. I started working on the prototype - and the different interactions - by working on a flow that we had created in the morning. This one:

My colleagues were super helpful in giving me feedback and guiding my hand while I was sitting there, picking up colors for buttons and attaching wires to all the screens. In particular, my friend and colleague Hossein Mapar was really helpful in helping me with the navigation and wires of the prototype.
So, in only one day we managed to create this, which would be used for the testing the nextday.

This was prototype v1.00.

Day four / User Test

The user-testing day came (HIT provided us with real target users that they hired), and every designer knows that it warrants a really scary feeling. Especially if you are the main person who worked on the prototype. What if the users don’t get it?
This question resonated in my hand, and some overthinking started. (Yes, I honestly believe designers should be overthinkers, up to a certain degree); but, luckily, users seemed to grasp the interface almost immediately. Of course, I am not saying the prototype was perfect (it was only created in one day, after all), but users could absolutely navigate it and give us feedback based on what we instructed them to do.
We ran usability tests - we had users run the click-through prototype and we instructed them to do specific things, and then we registred whether these actions were succesful or not.
My turn came, and I tested the prototype with a girl who was part of the target audience for the product - university students taking remote classes. Everything went smooth, but still, as expected, the users’ feedback is just absolutely fundamental and you cannot avoid it if you plan to deliver a good design. After these user testings, we had some new material to work on before final delivery. For example, in terms of actionable feedback, in the first version of the prototype we had one single button, one main CTA that users could click on to perform an action “seize the moment”, that essentially allowed them to both take a screenshot and be able to ask a question at the same time. From the user research it emerged that having two buttons for the two different functions would have been more clear - something that emerged from all tests. So, we decided to go for it, and we essentially changed the flow thanks to this discovery. Then, almost all the labeling and the microcopy had to be changed, as users felt they were a bit vague. The button "watch more about", for example, was universally misunderstood as usersdid not understand if this referred to resources from other classes or external resources, in general.

In the end many fixes were done and the interface was improved considerably after this research phase; here is a screenshot with all the insights we got from the interviews with an appropriate solution that was implemented in the final protoype:

Day five / Tune and deliver

Last day of the sprint came. We were exhausted and probably sleep deprived, but it did not really matter. We tuned the prototype based on the user suggestions, and I was able to implement everything in a v.1.01 version. Here is the final version of the MVP prototype that allowed us to design the experience and the interface of D.a.d.dy, both for users using the software while online (watching classes live) or offline (rewatching classes asynchronously).

In the end, we delivered this prototype with a video explaining the overall project to the company.

After a few hours where we could finally breathe, there was the main ceremony. After a couple hours, we were finally declared as winners of the 2021 UX Challenge!
And let me tell you, that felt super great! In case you are wondering, the first prize was a one year subscription toall the courses at the Interaction Design Foundation -
something that I am still reaping the benefits from!

Here is the video in which the host of the challenge in Trento, Nicola Doppio, announced our team as winners (you can also hear me making a comment on that, immediately after).

Last thoughts and main takeaways

@2024, designed by myself