This case study contains 3 phases: Phase 1: Understand, Phase 2: Create and Phase 3: Validate.
During this phase of the project, my team and I employed several techniques to understand the competitive landscape and the overall sentiment among potential users. We also sought to further understand the wireframes by checking them against Nielsen’s 10 Heuristics.
SCOPING OUT THE COMPETITION
Both Eric and I began this phase by evaluating five primary competitors based on six categories while Tori created the user flow and a basic prototype from the existing wireframes. The goal of this analysis was to find differentiation opportunities. Implementing such features could result in Tandlr attaining some of the benefits a first-mover might enjoy.
PRICING MODEL: $25/hour, $.40/minute, 30 minute minimum
PLATFORMS: Desktop/Mobile (iOS/Android)
LOCATION POLICY: Request any location, must be approved by tutor.
MEDIUM(S) FOR TUTORING: Face-to-face
TARGET AUDIENCE: Financially well off students who need flexibility with tutoring
NUMBER OF UNIVERSITIES: 12
PRICING MODEL: ~$15/hour, name your own price
PLATFORMS: Desktop/iOS/Android/Windows Mobile, smart watch support coming
LOCATION POLICY: Request a location
MEDIUM(S) FOR TUTORING: Face-to-face, online
TARGET AUDIENCE: College students who need assistance in a variety of areas including academics
NUMBER OF UNIVERSITIES: 3
With the exception of Sesh, which resembles Tandlr’s vision the most, we found that all competitors were nearly identical with respect to features and pricing models; most likely because every market player is still an early stage startup. This would make differentiating much easier than anticipated, especially since Sesh’s feature set is relatively basic.
Some ways Tandlr could stand out:
Note that the last three characteristics align with a few of Uber’s.
LEARNING FROM THE PAST
All three of us completed a heuristic evaluation of the wireframes while also creating the competitive analysis and wireframes/flows. I’ll admit that performing the evaluation felt like an inconsequential task since we knew full well the wireframes needed to be completely redesigned anyway. After further consideration, I realized that following through would help us avoid making the mistakes Tandlr initially made. My observations of the student and tutor flows Tori assembled are noted below.
The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.
The system should speak the users’ language, with words, phrases and concepts familiar to the user, rather than system-oriented terms.
No issues found
Users often choose system functions by mistake and will need a clearly marked “emergency exit” to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.
Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.
Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.
Minimize the user’s memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.
Accelerators—unseen by the novice user—may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.
No issues found
Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.
Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.
Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user’s task, list concrete steps to be carried out, and not be too large.
LISTENING TO THE USERS PT. 1
My team moved on to testing and interviewing potential users of the app after gaining an intimate understanding of the competitive landscape and conceptual groundwork as communicated by the wireframes, but not before addressing a critical problem. As alluded to earlier, we felt the wireframes weren’t in a presentable state, even for initial testing. It would have been like feeding people a cake that wasn’t baked and had missing ingredients then wondering why no one liked it.
We ultimately decided to proceed with the latter approach since it would yield more useful data. It was at this point my team and I formed questions, predicated on Tandlr’s vision, to ask the potential users. The questions were divided into three categories: High level, Student and Tutor. Some of these questions are highlighted below.
One of three tutor tests is shown below. Tori guided tutors through several task flows so we could understand how the most intricate aspects of the concept were perceived by the users. My role consisted of note taking and setting up/monitoring the recording tech.
DECODING THE RESULTS
After conducting several rounds of user interviews, we decoded all the data by affinity mapping. The patterns we uncovered were eventually translated into design principles and user personas.
The decoding process began with affinity mapping every data point we collected during the tests and interviews. Our process consisted of condensing every main idea into a sticky note then finding patterns among all disparate data points.
CODIFYING THE INSIGHTS
Unearthing key insights from affinity mapping allowed us to create a set of design principles which would serve as a beacon for our design solution. We also developed a problem statement, or a statement which encapsulates the ultimate problem the team should solve. This statement had a sizable influence on the design principles. In order to humanize the insights and help us understand the users’ goals, we further extrapolated the data into personas: one tutor and two types of students.
Students and tutors need an easy way to connect because coordinating a meeting with a professional qualified for a specific topic has inherent complexity.
1. Help the user understand how vital processes work
2. The user should always know where they are (i.e. in the app as a whole or within a specific process)
3. Give the user confidence in the quality of the tutor and tutoring experience (build credibility)
4. Support the user’s end-to-end tutor or student experience
5. Increase user confidence through clarity
The second phase consisted of ideating solutions based on our codified insights in the previous phase. My team and I started by sketching out ideas using the Crazy Eights technique to develop the conceptual foundation, then further developed the concepts with wireframes and a high-fidelity prototype.
We adopted a method which is part of the well known Design Sprint developed at Google Ventures, called Crazy Eights to commence the ideation process. I conceptualized a payment flow while Tori and Eric conceptualized tutor/student dashboards and the onboarding process, respectively.
After conceptualizing a basic payment flow, I created more comprehensible, mid-fidelity wireframes based on the sketches which incorporated iOS design patterns. Since the founders of Tandlr envisioned their business model to effectively become ‘Uber for college tutoring’, I drew inspiration from both Uber’s and Lyft’s payment flows to create Tandlr’s.
While Tori and Eric wireframed the rest of the flows, I began prototyping existing concepts produced during Crazy Eights. Their flows included:
I used my prototyping tool of choice, Proto.io, to recreate the wireframes Tori and Eric produced. This strategy allowed me to accomplish three things simultaneously.
1) Interactivity – I was able to make the prototype more interactive, and hence provide a more accurate depiction of how the final product should function, since recreating screens gives ultimate flexibility with each element. Simply importing screens from Sketch and linking them together, in my opinion, doesn’t fully satisfy the purpose of a working prototype.
2) Redundancy – Recreating the screens allowed me to fill any conceptual gaps or other errors, which may have been left by my team members.
3) Standardization – Having three different people wireframe using disparate design languages could result in the developers or UI designers misinterpreting our concepts; the ramifications of which, are obvious. To prevent any potential misinterpretations, I standardized Tori’s and Eric’s wireframes by using an iOS 9 design library and adhering to iOS design principles.
In this final phase, we performed another round of user tests with our new high-fidelity prototype as well as an unanticipated paper prototype to validate our design solution.
LISTENING TO THE USERS PT. 2
Since I wasn’t able to finish the student side of the prototype at the level of detail I desired by the time our scheduled student test subjects arrived, Tori and Eric quickly created a paper prototype simply by printing out their wireframes. We tested the tutors with the high-fidelity prototype.
Some of our findings are highlighted below.
At this point, we presented our work to the clients one last time and provided a suggested path moving forward with considerations for post-beta release features as well as recommendations for the expansion of our work; and given the team only had three weeks with the client, I laid out a plan for implementing the feedback we received in the validation phase and adding the previously omitted key user flows after parting ways with the client.
Overall, the client was highly satisfied with our work.
RECOMMENDATIONS AND CONSIDERATIONS
Tandlr can be downloaded from the App Store.