Shipping the MVaP of Empowerly’s student portal — A Case Study

Lai-Jing Chu
Dec 23, 2019 · 16 min read

Shipping a Maximum Valuable Product and raising task completion rate by 500% in two months

The bottom line with creating an MVaP [Maximum Valuable Product] is that even the first iteration of a product should be useful and desirable to customers or users. Without delighting users, or at least satisfying their most pressing needs, a product is bound to fail.
Cameron Chapman (on Toptal’s blog)

Empowerly Digitial Toolkit Beta Launch


The product

Empowerly’s Digital Toolkit is an all-in-one web portal that enables high school students to optimize their high school journey and college applications by providing integrated access to—

  • tools: time management tools, college list builder, etc.
  • human services: college counseling, essay editing, expert advising
  • resource directories: opportunities and scholarships databases

This case study mainly features the Dashboard and Essay Editing features.

The marketing blurb of the student portal on our (soon-to-be-old) official website

The business context

Empowerly (a Berkeley Skydeck startup) is quickly evolving from a bootstrapped college advising company to a VC-backed career-readiness technology platform. The company is in the process of transforming what was once an internal communication portal serving multiple user groups — parents, students, admin, contractors — into a B2C product. This long journey began with the students’ accounts.

My company hired me after a pretty successful internship, during which they granted me free-rein to imagine a highly integrated online service. Together, we imaged a product that would combine human service and AI to optimize a student’s high school journey and college application management. So, when I joined as a full-time employee, I expected to jump straight into implementing the designs.

That was naive.

Once I started as a full-time employee, I was immediately confronted by a myriad of practical realities that prevented those wireframes from happening anytime soon. The immediate challenge was to patch up our existing product’s most essential and crucial functions necessary for our business without losing sight of our startup’s long-term vision.

My role

I was the only UX designer working with one full-time engineer and a team of external contractors. Since we don’t have a product manager, I took ownership of user research, product management, and project planning.


The goal is to “repair” the existing web portal to the level of a ‘maximum valuable product’ in the shortest amount of it, such that it can:

  1. enable our current users to log on and accomplish a few meaningful tasks;
  2. be marketable and generate revenue;
  3. express our broader vision to potential investors.

Project duration

The beginning to the end of this case study took place in a span of just under two months, or four sprint cycles.

In the beginning, the entire product was functionally broken

Roughly two weeks after I joined the company, our team made a colossal mistake — we launched the new student portal before we did enough QA testing or any form of review to make sure it was functional. Many of our existing users and potential investors, having logged into our portal account, complained that they were confused by what they saw. ⬇︎⬇︎⬇︎

Plagued by broken user flows and bugs, the entire portal was unusable. Worse still, we already sent out marketing emails announcing its launch… very publicly.


We needed damage control, yet we faced huge constraints: time, money, and most importantly — manpower. The product team consisted of one designer (me) and one full-time in-house engineer.

Worse still, the MVP of the product was in a nebulous state at this point. Our product had introduced 10+ features which lead to unlimited possibilities for further design development and integrations. Fearfully, it may only start to gain momentum and create real value for customers after these features fully mature and integrate. If so, what is our MVP? And how do we prioritize work now?

Our immediate goal

If it is hard to force the product development fit into the mould of a “Minimum Viable Product,” perhaps it might be better to reframe it as a “Maximum Valuable Product” —

“How might we create a delightful experience for, and deliver the greatest value to our student portal users in the shortest amount of time, and it a way that benefits our business the most?”

To achieve this, I was adamant that we must implement a series of quick ‘band-aid fixes’ to the prematurely shipped product — i.e. repairing all the existing broken functionalities — so that when users log in, they can smoothly accomplish one meaningful task. The question is, what is that task?

I’ve learned a great deal throughout this experience. Click here to read my field notes of techniques and guiding principles specific to this project.

Part I: The product management process

Product management is about the “why” behind feature development. This section outlines the initiatives I took to fill in for the missing role in our product team, and it provides the context for the “design” part of the story. (If you prefer to skip this section and jump ahead to the design process, feel free to jump to Part II.)

1. Conducted organizational research to ensure team alignment

In the first week that I joined the company, I ran a workshop to understand the values, needs, expectations of different stakeholders regarding the product. I also did so to engage our marketing and sales team as my gut told me that it wasn’t right to sidestep their knowledge of our customers/users. The workshop helped me better understand the business, as well as generated a set of hypotheses that my subsequent user research set out to test.

team workshop

Here are two questions that our team collectively decided we needed answers to:

  • Is there a significant enough demand if we were to design an accessible web service targetting students themselves rather than their parents?
  • If students were motivated enough to take control of their college application journey, what are their greatest frustrations and pain points?
An empathy map of our users based on our team’s existing understanding during the initial workshop. The results formed the hypothesis to be validated.

2. Conducted contextual inquiry to understand the behaviors and needs of our users

To begin, we designed a detailed user survey to gauge qualitative data. Creating the questionnaire itself wasn’t hard — the difficulty was finding participants. In the end, we turned to Positly to find survey respondents quickly and efficiently received a volume of responses. To date we have collected 66 survey responses.

Together as a team, we conducted online interviews with individuals to learn about their college application journeys.

After each interview, we would discuss the most pertinent findings. We downloaded nuggets of findings as digital stickie notes on Miro Board, and then proceeded to build the affinity map and looked for patterns.

Then we translated the insights into personas.

Two personas: one who represents students that are likely to hire private college counseling, and one who wouldn’t but is eager to discover any relevant free/cheap resources (detailed obscured for NDA purposes)

The ongoing research reveals critical similarities and differences between our most familiar, existing customers and potential customers. For this reason, I generated two respective personas and displayed them alongside each other for contrast purposes.

Contextual inquiry, as a generative research process, runs in parallel to our design sprints, and is an ongoing endeavor. We have gained deeper understanding about our target audience than what is directly applicable to this project. The following signals are those that have a direct bearing on our decision making:

  • 99% of survey respondents reported being self-driven when it comes to applying to college.
  • 99% of survey respondents reported having either total ownership over the application process or at least 50–50 ownership with parents.
  • Responses revealed that Essay Editing is the second most highly sought after portal feature, after scholarship search.

More detailed research insights obscured due to NDA agreement.

3. As a team, we then prioritized the user stories for the most important red route(s)

Informed by our user research, we then, as a team, weighed our decision on which feature to work on first. We did so by balancing what our users desired, our business needs, and the level of engineering challenge.

Feature prioritization, following the user research findings, strongly suggested that we should finesse the user flow for students who are trying to access the Essay Editing feature. The reasons are that:

Feature prioritization, following the user research findings, strongly suggested that we should finesse the user flow for students who are trying to access the Essay Editing feature. The reasons are:

  • It is revenue-generating, and quotas have already been sold to our current counseling students as part of their existing premium packages. They needed to work.
  • The API calls were mostly already in place. The feature just needed to be better designed for usability. The Essay Editing feature is technologically a low-hanging fruit.
  • The research validated that the Essay Edit is the most in-demand. If we can get this fixed, we can also start marketing them as standalone pay-as-you-go services.
  • The UX pattern for Expert Advice (where users can submit any question and get meticulously researched answers on college admissions) is similar to Essay Edit, and the backend for that was also built. By fortifying Essay Edit, we can easily bring the Expert Advice feature up to speed as well.

4. “Repaired” the features along the red routes to ensure that the user can complete the entire task

The epic user story is this:

“As a student user, I want to be able to submit an essay to be edited, so that I could optimize it for my individual applications.”

However, in order for the user to be able to complete an essay edit submission, supporting functionalities needed to be intact as well.

Consider the typical task flow of a student who is submitting an essay:

We needed to refine not just the Essay Edit feature but also:

  • Sign in/Sign up
  • The Dashboard
  • The main menu
  • The purchasing flow for a la carte services
  • Essay Edit feature itself (and by extension, the Expert Advice feature which shares similar UX patterns).

Next, for each feature, we detailed the user stories on the product backlog. Only after that did I move on to the design process. More on that in Part II below.

5. Handed off wireframes to the engineers and monitored development progress.

To time-box our progress, we introduced two-week sprint cycles to our working method. It got us into a good rhythm.

When the design was completed and I switched over to monitoring progress, I quickly discovered that I needed the means to communicate markups to our developers. After attempting to file tickets on Google Sheets failed, we turned to Airtable instead, and magic happened.

Our contractor engineers, who work from Romania, would access the Kanban view of Airtable and pick tickets off the problems board to work on them, and I would be able to review their work when tickets enter into the “submit for review” board. We can even converse on the tickets! The whole process became beautifully streamlined.

6. Introduced a protocol to benchmark the quality of our work before shipping

Again, this is about team consensus.

What if our product team worked tirelessly on something that the rest of our company does not agree with, or does not know enough to sell?

To avoid this, I developed a protocol to ensure that the product passes through the eyes of our marketing, sales, operations and CEO before it is publically released. And I called this benchmarking.

Towards the end of the development, our entire team sat together and tested the product based on various criteria, from usability to tone-and-voice, to media responsiveness.

Benchmarking accomplishes three major goals:

  • Quality assurance of the product we ship and gives the product team confidence to stand behind the work;
  • Ensuring the voices of every department are heard and that their needs are met;
  • Enabling all departments to familiarize themselves with the product — since the knowledge would be helpful for their day-to-day work as well.

Obviously, the benchmarking meeting revealed significant shortfalls and bugs that still needed to be addressed. The product team took note of them and spent more time improving the design and the backend system, which made the product more robust.

Part II: Design

Now, in this section, I will discuss the design process. As a general rule, I took the approach of being economical with API calls, and reached out to front-end solutions to address usability issues in order to speed up development. The priority was to enable task completion. I constantly asked myself, “do users require X to complete the task?” If yes, I’d address it, if not, then I’d move on.

That said, if a small amount of effort (mostly through UX content, illustrations, or simple interactions) could increase user delight, I’d advocate for it too :)

The Dashboard (previously: “Overview”)

➤ The problem

The “before” portrait
  1. Poor visual organization: There is no apparent reason for lumping student profile, academic data, counselor’s info, and package details all on one card. There is also no indication that “My Tasks” and “My Agenda” are functionally connected — which they are.
  2. None of the widgets were usable: For instance, there are no means for users to update the Academic Snapshot or purchase or upgrade packages.
  3. Lack of empty states: There is no guidance on how any of the subsections on the page worked. The urgency was to redesign the very first screen users see when they log in so that they know what immediate action to take.

➤ The process

First, we created Lo-Fi wireframe options and established a long-term vision for the dashboard functionality.

Then, I took the lo-fi wireframes and reviewed them with our product stakeholders and users. As the design progressed to hi-fidelity, we conducted more thorough usability tests to gather feedback and ideas.

The dashboard proved to be the most complicated section to repair since it essentially contains a little bit of every feature and evolves with the user’s membership status.

In order to communicate the different scenarios and edge cases, I produced detailed wire flows for our engineers. Since I don’t directly interact with our remote contractors, these notes have proven to be critical to reducing confusion:

Hand-off notes+wireflows for developers

➤ The solution

Due to time constraints, the refreshed Dashboard follows clear developmental continuity from the existing interface design. The major interventions are:

  • Reorganization of the cards based on their respective functions and grouped them into categorized sections for better visual hierarchy. The main sections we worked on are “Empowerly Services,” “Your Academics,” and “Time Management.” (see image below).
  • Clearer empty states throughout the Dashboard to help students make the most of the portal.
  • Under “Empowerly Services,” the first card entices new members to access our free trial services, then afterward if they choose to purchase a la carte services or become a Premium member, how much quota is left in their service package.
  • Counseling now stands as its own card, which is positioned at the highest real estate location. While this widget is mainly for Premium users to manage their counseling appointments, for Free users, they are also able to sign up for counselor-run webinars or book a free 30-min Profile Review.
  • In the Academic Snapshot, we added clear explanations of all the different types of tests and scores, what they mean to an application, as well as our take on them, paving way for the portal take on its educational function and guide students through the college app process.
  • In the Academic Snapshot widget, intended to be a feature for students to log the GPAs and test scores for internal communication purposes, we added a simple goal setting function to entice students to enter their data. When a goal is achieved, a 🎖would appear as a reward.

Again — the tricky part of the Dashboard is that it contains a little bit of every feature, which meant that we could not ship it until everything else is done. For this reason, we made minor visual updates and bug-fixes to the existing, stand-in “Overview” page, and kept the new Dashboard design in the drawer until the Purchasing Flows, Essay Edit and Expert Advice were fully ready to launch.

➤ Next steps

Precise details obscured due to NDA agreement.

Sidebar navigation

➤ The problem

Our visitors have complained that the existing menu is confusing had trouble understanding the full scope of the Toolkit’s service. In short, they weren’t sure what to click, and the CTA was unclear.

➤ The process

Because our team had no preconceived notion of how features and sections should be grouped, I decided to conduct an open card sort on Optimalsort to see how potential users would categorize the items.

Even with an open card sort, I didn’t get an ideal result immediately. My first try was to categorize items based on the order in which a student would approach the tools throughout the standard application journey. That didn’t work out too well.

Serendipitously, in a separate project where I had to redesign the marketing website, I noticed that our entire company’s offerings could essentially be sorted into four buckets:

Empowerly’s four baskets of offerings
  • Services (Counseling, Essay Editing, Expert Advice, etc.)
  • Tools (Product features such as Calendar, Schools List, Applications Trackers, etc.)
  • Resource Banks(Databases for extracurriculars, scholarships, etc.)
  • Content (Blogs, Webinars, etc.)

Then the solution became obvious — the student portal just needs to mirror this structure.

Before showing the new menu design to anyone, I conducted a closed card sort to test its intuitiveness. The dendrogram showed promising results, as participants were at 90% agreement with the categorization.

➤ The solution

The evolution of the menu is as follows:

The development of sidebar design (Version 2 was never shipped)

Purchasing Flow

➤ The problem

The section was non-existent— users had no way to purchase our services on a browser.

➤ The process

I rapidly sketched a few design options and discussed the possibilities with the engineer. The final decision struck a balance between development time and user-friendliness.

➤ The solution

In the end, our team decided on option 4 for the following reasons:

  • Users can see all price ranges and discounts at one glance;
  • It was easy enough for users to customize their best-value package;
  • It was not too difficult for engineers to build.
Video demonstrating the purchasing page

Essay Editor

➤ The problem

Our company offers a 500-word free trial for its Essay Edit service, but there is no indication of that on the page. A user wouldn’t know if they would be charged or not should he or she consider submitting an essay. Again, the lack of an empty state is a huge problem. ⬇︎⬇︎⬇︎

Before: As the user, I’d probably feel confused. “Should I submit an essay?… will I get charged??”

➤ The approach

First, I took note of the main usability issues that plagued the existing interface. Then, I created wireframes to address the broken aspects of the user experience. To save time, we were economical with creating new API calls and relied on front-end design to improve user-friendliness.

➤ The solution

First time user accessing the Essay Edit free trial
Returning user retrieving an edited essay

The main interventions:

  • We added an empty state that explained the service scope, as well as displayed the remaining word count quota available with the option to purchase more. A fresh account clearly shows that 500 words of essay edit quota have already been preloaded for you.
  • We streamlined free-to-paid conversion by clarifying with backend how the “free 500-word trial” works, and I created wire flows for developers to detail how that should play out in the system.
  • We improved the visibility of systems status by letting the users know when their essay is being picked up by an editor and is under review.
  • Responding to operational needs, we enhanced the feedback system so that users would be reminded to comment on their editors upon leaving the page if they had not done so already.

Our Expert Advice section follows a similar UX pattern, so after laying the foundation in Essay Edit, we were able to quickly build out the Expert Advice section using the same template.

➤ Next steps

Obscured due to NDA agreement.


In the end, did we achieve our goals? Well, at least now the product is —

  • Usable: Google Analytics user flows demonstrate that our attempt was successful — our essay submissions increased 500% in the month our new version was deployed, while our expert advice submissions increased 400%. Of course, this increase in volume owes itself to the fact that it is college application season, and these services were naturally in high demand. However, imagine if we hadn’t patched up these web features in time! It was a crisis averted.
  • Marketable: Now that our product is that much more robust, we finally have something we can wholeheartedly advertise.
  • Pitchable: Recently a coworker and I had a rare chance to deliver a presentation of our company to a group of overseas visitors at our startup accelerator. As we walked them through the portal account, we saw that their expressions softened, their eyes widened, and their phone cameras pulled out — even when we are terse with our explanation. That’s when we know that our hard work is speaking for itself.


During my internship at Empowerly, my biggest takeaway was learning to customize a design process and adapt it to the realities of a given business context. I was surprised by how much I enjoyed the challenge of designing for the maximum value possible within a given time and budget. To me, the constant weighing of priorities and making decisions (i.e., which feature should come first? Form first or function first?) is in itself a meaningful creative endeavor. Because what’s creativity anyway? It’s being imaginative about your options and making deliberate decisions.

In architecture, a building design process goes from Conceptual and Schematic Design, to Detail Design, to Construction Design. When I was in architecture, one of my superpowers was designing the nuts and bolts in construction drawings (when frankly, most people I knew hated it 🤓). As a maker who relishes in that process of turning ideas into reality, I am looking forward to building out the rest of the Digital Toolkit with the rest of the product team.

Lai-Jing Chu

Written by

Product designer at Empowerly.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade