
Defining an MVP.
Systems thinking • Rapid Prototyping • Balancing Speed & Value
Context
What This Case Study Demonstrates
Time-boxed rapid learning
Prototyping at the appropriate fidelity
Co-create to nurture shared vision of the opportunity and the solution options
UX strategy, research, and design
Research participant recruitment
User interface design using an existing design system
The Product - Loopio
Loopio is a tool for sales teams (often called Request for Proposal or RFP) teams to collect, re-use, and re-mix their answers to common sales questions. It’s an efficiency tool that works similarly to a design system for RFP teams.
Prior to in-app translation, when users are faced with a non-English RFP, they would need to use a different tool and process to get the RFP into English before uploading into Loopio to complete their project.
With in-app translation, users can work on their non-English RFPs entirely in Loopio, saving time through a more streamlined process.
The Project - Add In-App Translation to Loopio
Business Impact
The Stakeholders
Stakeholders included:
The core team consisting of a Group Product Manager, the Director of Design & Research (me), 2 senior back-end developers, and 2 junior back-end developers
The broader Engineering, Product, and Design team
Sales teams
Customer teams
Senior leadership team
The users
Date
Iteration 3: offer translation after project creation - during “import questions” workflow.
Iteration 1 identified the technical unfeasibility of an ideal user experience. Iteration 2 uncovered a scenario that the team was not aware of: the Salesforce scenario. Iteration 3 addresses the feasibility issues uncovered in Iterations 1 and 2.
The Scope
Oct to Nov 2023
Balancing User Needs With System Needs
The system has two basic constraints:
The Loopio UI is already dense, so the new functionality needs to be enabled with minimal UI components.
The product architecture is such that the translation service needs to be built as a separate workflow rather than a componentized module that users can request on demand; in other words, the backend needs to know whether a given project needs the translation service as soon as possible in the workflow.
Desirability:
Minimal UI update - yes
Minimal disruption to workflow - yes
The business case for building this feature is to get Loopio onto the consideration list for organizations looking to subscribe to RFP software. It’s a table stakes feature, and success is measured by sales consideration.
And of course, from a feature perspective, active user adoption is a critical measure of success. This would be measured in a few ways:
adoption rates among users with non-English content and completed RFPs in their library of projects
the feature’s UMUX-Lite score.
My Role
Iteration 2: offer translation earlier in the workflow - during project creation.
This iteration notifies the system earlier in the workflow than Iteration 1 while still maintaining an optimal UX to show the translation option only when appropriate and to avoid adding information and interaction density with more options and copy in modals.
Project strategy
Project communication strategy
Project communication artifacts
The Work
The Constraints
Ship something within 6 months
Maintain existing workflows and mental models
Maintain existing data model and technical architecture
The Design Strategy
We needed to make three critical decisions:
What should be in the MVP?
Whose problem should we solve first?
Where and how to integrate the new capability into the work flow and interface?
The strategy I used to help our team answer these questions is to identify what work we could do to drive the greatest impact and value for our key user group (the RFP team members who respond to non-English RFPs).
This strategy led us to guide our decision making as follows:
Not MVP but MVE - Most Valuable Experience
Solve the most perceptible pain that allows us to tell the most marketable value narrative
Integrate the new in-app translation capability in a way that least disrupts users’ current workflow.
The Collaboration Strategy
The core team consists of three senior team members representing the voice of product management and engineering. In order to get to the solution, getting them aligned with design decisions was mission-critical. My most important work was bringing them, and other stakeholders, along for the ride. To do that, I used two methods:
Co-create and collaborate to define the UX of the MVP
Use the Socratic method to balance Engineering and User needs
The end-to-end scope was broad. For the purposes of this case study, we’ll focus on just one: where in the user flow to insert the new in-app translation capability?
Using rapid prototyping, I developed 3 concepts within a 2-week sprint to converge on a solution that met user needs as well as the system constraints.
View translated RFP on demand
Offer translation service within the “project creation” workflow
Offer translation service during “import questions” workflow.
Where in the user flow to insert the new in-app translation capability turned out to be a decision in balancing user needs with system needs.
Users have two basic needs:
Minimal disruptions to their existing workflows
Show them the translation option only when appropriate (i.e. if their RFP is in non-English)
Design Methodology
Each concept was created iteratively: what I learned from each concept was incorporated into the next iteration. In this way, we were able to quickly get the learnings we needed in order to make our three critical decisions:
What should be in the MVP?
Whose problem should we solve first?
Where and how to integrate the new capability into the work flow and interface?
Iteration 1: View Translated RFP on Demand
Iteration 1: Offer users on-demand translation through a toggle option once they're in a project.
User need: show translation option only when appropriate and avoid more options and copy in modals.
Feasibility:
This solution does not allow users to provide input early enough in the workflow for the system to know whether or not to direct people to the version of Loopio with in-app translation: this solution is not feasible
Iteration 2: Offer translation service within the project creation workflow
Desirability:
Minimal UI update - yes
Minimal disruption to workflow - yes
Feasibility:
Sometimes, projects are created in Salesforce and then continued in Loopio; with Iteration 2, users in this scenario would not get the in-app translation option: this solution is not feasible
Iteration 3: Offer translation service during “import questions” workflow
Desirability:
Minimal UI update - yes
Minimal disruption to workflow - yes
Feasibility:
Early enough in the workflow to allow system to know whether or not to direct the project to the version of Loopio with in-app translation: feasible
The Final Experience
Iteration 3 represents the final definition of the Minimum Valuable experience. The go-to-market messaging was simple yet powerful: if you work on non-English RFPs, you can now import those directly into Loopio for a seamless workflow.
Below is a video that I created using Figma and Quicktime for Loopio’s Sales and CX teams to use with prospects, customers, and users.