UX Research & Design
Find an Expert
Teacher with Exam Pro
Case study for a responsive web app that allows users to connect with proven experts who can help with passing common academic exams such as the IELTS (International English Language Testing System) or CAE (Cambridge Advanced English) exams.
These exams open doors to universities abroad, emigration, and career advancement, so it needs to be right.
Find-an-expert apps are commonplace on the net and to some extent, they work well. However, I discovered that a lot of users are not satisfied with the type of experts they can find online.
Experts can also become jaded with such apps as they find they can be undercut by unqualified experts, and also exploited by the app itself where they find they are doing all of the leg work and providing all the materials; only for the app to take a large commission from them.
I wanted to build an app that would meet the needs of the users and do what it says on the tin. The app had to be easy and intuitive to use without too much guesswork.
I decided to build Exam Pro. Here users (both learners and experts) can benefit from a quality service where experts are guaranteed to deliver a good service at a fair price and users can feel safe that they are in good hands for preparing for their exams.
Pen & Paper
UsabilityHub (A/B test)
1 UX designer
Overall: 8+ weeks
Discovery & Research: 2+ weeks
Design & testing: 6 weeks
To help me get some inspiration, I took a look at the competition that is out there. Two very popular web apps are italki and Preply. I did a S.W.O.T analysis of their apps to see if I could find out what they are doing right (or wrong). It yielded some interesting information. This includes:
Both apps have massive followings.
Both offer many languages.
Both have huge numbers of teachers signed up.
It is not clear if the teachers available are professionals.
They are very competitively priced which could be demotivating for potential teachers.
Students are spoiled for choice, but may not find exactly the teacher they need.
User Research (Interviews)
For this part of my research, I conducted interviews with both quantitative and qualitative questions. I used the data to compile Affinity maps to add more insights into how Exam Pro would take shape.
It seems that:
There does not seem to be an app that is solely for preparing for an exam.
Potential users would like a professional teacher with assurances they are capable.
Teachers should have in-depth knowledge of a particular exam.
A broad range of exams should be available to users.
Teachers should be quick and easy to find.
Below you can see more in-depth findings.
After collecting such useful insights from the participants of my survey, I went ahead and created some user personas. This was to help me empathize with future users and get to the root of what they really need with an app like mine. You can see a couple of them here.
Before I started sketching out any wireframes for the app, it was logical to put together some user flows, just to see how easily and quickly the users could get from the start point to their success criteria. I've included a couple of them below.
& Low-fidelity wireframes
I also needed to figure out what the sitemap would look like while taking into consideration the user flows. From the feedback I'd received from the first interviewees, I knew that it had to be easy to navigate without any sticking points.
Once I'd put together my initial sitemap, I also implemented a card sorting exercise so I could further gauge what information users would expect to find under certain headings.
I used a card-sorting app online via Optimal Workshop and posted the test on social media. I certainly got some interesting results.
I realised that my original map was not the best it could be.
Using feedback from the card sort I rearranged some of the items from the original map.
Here are the before and after versions.
For this next part, I had to put pen to paper and start getting some ideas down about how the app would look. In the following images, you can see my first low-fidelity wireframes with explanations of important assets. I took inspiration from several different apps that all feature components and design patterns that users are familiar with. I learned quite a lot during this stage, it makes a world of difference if you stick to the usual patterns and designs that users are familiar with.
Now that I had a rough idea of what the app was going to look like, I set to work with the next step - mid-fidelity wireframes. For these, I put together, onboarding, signing up, searching & booking an expert, and messaging an expert. I used Figma for these iterations.
Now it was time to test my prototype. I made sure to follow best practices and make sure participants knew that I would not be passing their data on to third parties or doing anything untoward with their information.
All tests were scheduled to be moderated and take place either face-to-face or online using Figma as the source for the prototype. Here I learned that it is always better to have a few extra participants in reserve in case they can't all make it on the big day. I needed six for a workable amount of data, but I recruited eight, just in case.
When users tested my app, I could observe any pain points or any positive responses they might have either visually or non-verbally. If any problems did occur, I would rate them with Jakob Nielson's scale.
Once all the tests were done, I got out my sticky notes and created another affinity map. After that, all of my observations were compiled into rainbow spreadsheets so I could visualize the data further to find common pain points.
The interviews and these spreadsheets yielded some great information, from both what I saw participants do and say, and would help to shape the high-fidelity version of the app. In total, I identified five issues that need to be dealt with, and so I made necessary changes to the app design. I rated these issues according to the Neilson scale. These issues were:
Search button not clear - high severity
Users could not return home from taskbar - high severity
The title text was mistaken for a button - high severity
Booking times were confusing - high severity
Card payment options were a little confusing - medium severity