Contact
Get in touch with me
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
or send me an email at
rebeccalothan@gmail.com
We (my manager and I) worked with our client, Minoa, B2B Saas start-up serving salespeople, in a 2 week sprint to redesign their ROI Calculator, a tool to help salespeople more quickly arrive at value propositions within their business cases.
The overarching goal of this sprint was to increase the number of business cases created. In uncovering barriers to users creating business cases, we identified the ROI calculator as a major sticking point. Its block layout was not intuitive for users who are used to representing equations horizontally. Its interface did not support exploration, and overall it was difficult to quickly edit calculations.
Our new calculator featured:
Build calculations horizontally in a formula bar. Enter operators, search and select inputs and subcalculations in the formula bar.
Users with diverse workflows are supported in the new design, whether they start with configuring inputs, or the formula.
Easily see, add and edit inputs, subtotals and formula bar outputs, all at once.
Duplicate calculations and revert to old versions, edit inputs in a spreadsheet-inspired UI and see the overall output change.
Minoa is a B2B SaaS start-up that helps salespeople with value selling and co-selling, earlier in the sales cycle, they do this by helping salespeople quickly produce Business Cases.
Business Cases are documents that salespeople create to lay out their value proposition for their customer, which includes a narrative and a financial component. Minoa’s ROI Calculator helps salespeople make a financial case for their product, or how their proposed product will either reduce costs or improve revenue.
Engineers would need to be able to translate existing use cases and calculations into our new solution, so the same functionality need to be accounted for.
Without Minoa, this ROI calculation work is typically done in spreadsheets. There is an element of play and exploration users can easily do in spreadsheets, and it was important to allow for this kind of tinkering.
Some salespeople work from inputs to outputs, configuring all the input information, then configuring the formulas that build on them - bottom-up workflows. Some salespeople begin working from their output formula, and as theyre building this, they start to compile the list of inputs they will need to track down - top-down workflows.
Minoas current calculator solution relied on blocks and vertically stacking information. I noted that I needed to click into subtotals and totals to see the calculation detail, to understand how they all fit together to create the output. Substantial space was being taken up by “No description available”, which contributed to an overall feeling that I wasn’t easily able to see enough of the right kind of information.
Minoa conducted two customer interviews and came back with several insights about the builder, big and small. A few key takeaways of the interviews:
Both users expected to find their total/output called out, or a large calculated total number somewhere. One user suggested it would be nice to show the spatial relationship between inputs and outputs.
Neither user changed their inputs type. Both could not figure out how to change the input type and were confused by the input detail panel.One user commented that it would be nice to easily see and use the ‘building blocks’ of the calculation (input values and subtotals) to then create new subtotals and totals.
One user did not understand the concept of calculation blocks. They also commented that they expected drag and drop functionality. This expectation I attribute to the block interface itself.
To better understand competitors’ calculation workspace user experiences, I researched Pry, Causal, and Scratch. I focused on the surfaces they used, their overall layouts, and the input interface. How do users configure input information in these applications? How do they see, add and edit inputs and outputs?
Some of my major takeaways from reviewing Pry, Causal, and Scratch:
All three competitors have the center of the page dedicated to the main “work” area. 2/3 used a three column layout, with the process flow starting at the left, with a space to configure inputs, and the far right, a space to configure outputs.
2/3 use a formula bar where the main job of calculating takes place. They communicate the calculation information horizontally, following the format of a formulas in spreadsheets.
After my competitive research, aspects of our solution space seemed clearer. Keeping an eye on our requirement to accommodate current functionality, I started by figuring out how to translate an existing Minoa ROI calculation into a new interface based on my competitive comparison learnings, something with a large centered workspace, and formula bar.
A couple of rounds of iteration and a UI skinning pass later, we arrived at our final design. Called out here are the major areas of change from initial wireframe to final, and why we made those decisions.
We replaced blocks with a spreadsheet UI for inputs. Users typically do calculator work in spreadsheets, so our solution is familiar and allows users to experiment to develop their calculations.
Added support for multiple calculations, allowing for quick duplication and experimentation with different inputs. Included an affordance for versioning, users can now revert to older versions.
We tried allowing for both block and formula strategies in one design, but ruled it out because it was too confusing. Ultimately we committed to a horizontal formula bar approach across the board.
