Improving the customer effort score of Savviest.
Mission control for your career. 🚀
PRODUCT MANAGEMENT + UX RESEARCH + UX UI DESIGN
BUSINESS OBJECTIVEs
Savviest is a career wrangling and document building platform which helps users find, apply and secure their dream job. Savviest requested our help specifically on improving the resume and cover letter building and editing tools through UX research, ideation, design, and user testing.
TIMELINE
5 weeks +
1 week post-project
INTERN TEAM
Kimberly
Patty
Fernando &
Jamie [thats me!]
STAKEHOLDERs
Co-Founder & Lead Engineer | Devin
Co-Founder & Marketing | Jared
In-house Designer | Hannah
PLATFORMs
Web + Mobile-Web
THE PROJECT GOALs
Optimize and improve the customer effort score of Savviest through research of users’ specific needs and goals.
STRATEGY
The scope of this project was extremely divergent compared to the allotted initial project plan. We had committed to an internship of 10 hours per week, for 4 weeks. After gauging the pace of our first week, I scheduled a meeting with Devin, one of the co-founders of Savviest, to discuss a revised project plan I made to help the team accomplish our goal for the project— within a slightly extended timeline past that 4-week mark, to 5 weeks.
PROJECT PLANNING + TIME BOXING TOOLs
View the revised (and accepted!) project plan I made.
View the details of our day-to-day work on this project.
Getting to know Savviest…
INITIAL AUDIT
After our first interview with the stakeholders of the project— Savviest’s co-founders and in-house designer— we each took a bit of time to perform an initial audit of Savviest. This gave me a brief understanding of what sorts of things Savviest has to offer and allowed me to ask questions of the Savviest team so that I could clarify anything that was confusing.
Initial Audit [Nielsen Principles & More]
Check out this spread sheet detailing my first impressions and evaluation of Savviest.
Getting to know our competitors…
COMPETITOR ANALYSIS
To better understand the problem space and industry in general, we each chose a few competitors to analyze... It was at this point that we split into two groups— 2 of us to tackle the resume experience and the other 2 of us to take on the cover letter side of the experience.
This analysis proved to give us an understanding of how Savviest aligns or differs from the resume/cover letter building industry and gave us some insight and inspiration to work from.
USER INTERVIEWs
With an understanding of the intersection between Savviest and our competitors, it was time to do some primary research with potential users. I interviewed 6 current and recent job seekers to gain insight and empathize with the frustrations that come with resume and cover letter building.
KEY FINDINGs
Participants mentioned that there was a significant ‘mental block’ when starting to write a cover letter and/or resume.
Not everyone’s industries require the same materials.
All participants mentioned that they used google docs for at least one recent version of their cover letter or resume.
KEY INSIGHTs
Most participants mentioned the most important tool or resource for them was their friends, family, or other people who read and gave feedback on their materials.
Participants frequently mentioned looking at examples of other resumes and cover letters for inspiration and direction.
All participants mentioned that their writing improved the most when they got feedback relating to the keywords present in their writing.
View the entire research report of the initial interviews.
HOW MIGHT WE STATEMENTs + PAIN POINTs
From these insights and the following four pain points, we crafted four How Might We statements to leverage when sketching. Below are all four of the statements used in this project, however, I was assigned to focus primarily on this first statement:
Pain Point 1 | Users struggle to find the right words to communicate their intentions, skills, abilities when drafting resumes and cover letters.
How might we inspire users to write effectively in their cover letters?
-
How might we standardize the editing experience to meet users’ needs and expectations?
-
How might we motivate users to seek feedback so that they may improve their resumes?
-
How might we improve the visibility of Savviest’s various features so that users can effectively build their resumes?
IDEATION
I took some time to quickly sketch possible solutions to the How Might We questions we created. After we all presented these sketches in a check-in with the Savviest team, I met with Kimberly to choose one of our solutions to hone in on. Together, we decided to go with a merge between one of my solutions and hers.
“You were the chosen one!!!”
SOLUTION SKETCH
Introducing the Savvy Scanner! Inspired by Savviest’s Resume IQ Score calculated when a user ‘scores’ their resume, our Savvy Scanner provides the context and details of how to improve that score. When a user links their cover letter to a specific job description, Savviest’s AI will scan it and generate a checklist of keywords, phrases, and job experiences the user should include in their letter. With refinement, this checklist also incorporated grammatical suggestions—all of which are components that improve the score and competitive-ness of the letter.
USER FLOW
USER FLOWS
Solution sketch in hand, Kimberly and I collaborated on a user flow to help guide our designs and first wireframes.
(Above) Cover Letter user flow which follows the red route a user would take to use our Savvy Scanner, edit their cover letter, and finally download it to send off to an employer.
MID FIDELITY WIRE FRAMEs
Take a look at our initial designs in the form of mid-fidelity wireframes below. In creating these wireframes the four of us came together to unify our designs by collaborating live in Figma.
(Top Left) My low-fi wireframe of a modal onboarding users to the Savvy Scanner. (Top Right) Kimberly’s Mid-fidelity iteration of the same screen.
(Bottom Left) The low-fidelity wireframe of the builder screen showcasing comments & suggestions along the left and the Savvy Scanner’s checklist along the right.
(Bottom Middle) Kimberly’s mid-fidelity iteration of the same screen with an expanded side navigation.
(Bottom Right) This stage’s final mid-fidelity wireframe of the builder screen containing components from all four designers.
PROTOTYPE
After finalizing the wireframes and stringing them into a wire flow we would move forward with, I prototyped the wire flow into an interactive prototype using Figma.
USABILITY TESTING
As the project timeline was becoming more compacted at this point, we committed to finishing usability testing with a quick turnaround. Kimberly wrote our test script and we all came together to workshop the script for testing. There was no more time for indecisive, uniformed design decisions. With vigor, we all approached this phase with confidence and ready to learn by putting our work in the hands of real users.
TEAM WORK
While I conducted the majority of the usability tests, Kimberly attended and took amazing notes throughout the process. Without our flawless team work here, there is no way we could have caught ourselves up to the project timeline like we did or accomplish 7 usability tests out of the 11 total!
TEST REPORT
Alongside the notes from the other 4 usability tests conducted by our other teammates, I synthesized a report to present to the Savviest team. This report included key insights, iteration recommendations, and a chart of all usability issues we encountered ranked from critical to low priority.
THE END [Kinda…]
Upon presenting these findings and recommendations from usability testing, this project was ‘officially’ concluded. However, the four of us decided to continue an extra week, on our own time, to apply some informed changes to our designs.
REVISING MY ROLE
After discussing some feedback I’d gotten from Devin and Hannah throughout the project, I decided to further develop my leadership skills by taking a different approach to the reiteration process. As everyone’s availabilities during this time varied significantly more than previous weeks, I proposed that we each take full ownership of one of the critical issues we found in usability testing. In this phase I met with each of the other students individually to help in their efforts to brainstorm redesign solutions to their respective usability issues.
FEASIBILITY MEETING
Before getting too far in finalizing these solutions, I wanted to be sure our end product was actually feasible and possible to develop. Until this point, Savviest had told our team to shoot for the moon in our designs. It was now time to consolidate everything into a plausible solution. I scheduled a meeting with the Savviest lead developer to go over the feasibility of everyone’s individual proposed redesigns. Afterwards, I communicated the relevant responses to each team member.
TEAMMATE ITERATIONs,
that I helped with :]
Patty's Iterations | Patty chose to tackle the issue of confusion around the share, feedback, and professional review features we encountered. In our session, I brought her different example of how various competitors approach these features. As a result, we chose to eliminate the ‘get feedback’ button and combine the two feature’s modals into one. Below I’ve included side by side of Patty’s iterations.
Fernando's Iterations | Similarly, Fernando and I met to discuss the iterations he had in mind. We ended up choosing to reuse Savviest's existing commenting and suggesting element which exists separately from the building screen and integrate those components directly into the builder screen. Additionally, we included a highlight to the area the commenter referenced their feedback.
Kimberly's Iterations | Lastly, Kimberly and I met to discuss iterating on the Savviest Score and checklist in addition to relieving the flow of its extraneous modals, specifically the download related modals. We decided on a lot of minor changes by removing components that were complicating the checklist and also collapsing the checklist and relabeling it as a ‘score breakdown’. We removed the download modals by incorporating a dropdown for when the user clicks the ‘download’ call to action button. Collapsing the checklist allows for the user to see the other professional review and feedback sections along the right. Relabeling it as the ‘score breakdown’ makes it easier to understand that by incorporating or improving the items on the list, the user’s score will improve and their document will be more likely to perform well in the job search.
PART TWO
Redesigning the Mobile-web UX
MOBILE-WEB SAVVIEST AUDIT KEY INSIGHTS
To start, I did a brief audit of Savviest’s mobile-web experience and took a look at the mobile versions of various competitors. Here are the key areas I chose to attack in my redesign of the mobile- web experience of Savviest:
Savviest’s document selecting screen has extremely detailed, large cards for each document and the user is forced to scroll quite a bit to get to the next document and so on.
The editing view of Savviest has particularly large margins. Every pixel is particularly important in mobile design, therefore these have got to go.
The editing tools for the document are all beneath the document. The user must scroll quite a bit to get to the end of their document, adjust perhaps the font type, and then scroll back up to see how the document has changed.
Incorporating the feedback comments from others in the mobile-web experience, to mirror our desktop iterations.
RE-DESIGNS
See below my annotated redesigns of the mobile-web experience of Savviest!
FUTURE RECOMMENDATIONS
The next step for this project is to do usability testing, even on the mobile-web prototype I made. Even though I mirrored the solutions from our desktop solutions into these designs, it has yet to be vetted by real users. In this next phase of testing, the goal should be to uncover the accessibility of all editing tools and also especially the ‘feedback’ tab I created.
LEARNINGS
The biggest takeaway from this experience for me is that everyone needs to have a bit of leadership within them, but also that the final decision— regardless of who makes it— needs to be informed by data, user goals, or business goals. It was really difficult, throughout this project, to make decisions when not everyone had an opinion or point of view to advocate for. It led to a lot of ‘I could go with either or, really…’. At the same time, I struggled a few times to choose based on data and how best the design would fit with our problem and user goals because I wanted to include everyone’s point of view.