Mapped
Overview
Mapped is a startup in the building technologies and IoT sector. The tech deliverable for the company is an “independent data layer” for commercial and industrial spaces that helps property owners, facility operators, and solution providers rapidly access real-time data from building systems (like temperature, motion sensors, and lighting). The data extracted from physical spaces can be accessed in the Mapped platform through a digital twin (a 3-D rendering of the space and all data points within it). The main users of the app are software developers.
The Problem
Pricing structures for SaaS products B2C can be highly complex. Terminology and data structures for commercial building systems are also highly complex. We needed to solve for the massive complexity of these two factors and deliver a transparent pricing model with a seamless flow into payment and uploading data.
The pricing model for Mapped is based on the number of buildings deployed and the API usage fee is based on the amount of data consumed. A fee for a gateway connection: virtual (VPN) or a physical piece of hardware and contract term length were also elements to be considered.
The Goal: Bottom up sales
We were already selling to enterprise customers, but we needed a way to allow single developers or small development teams to access the platform quickly and easily. We dubbed this model, “Self-serve.”
A Fully Remote Team
Executive Team, Architecture Advisor, Lead Developer, Director of Marketing
My role: UX Research, UX & Marketing Design, Copywriting
Design Process
This project began with working directly with the Executive team to create a pricing structure that would translate to our marketing site and platform. I gathered best practices, examples, and presented an exploration of research to them on how we might frame his pricing model. We landed on naming three tiers: Starter, Basic, Pro. Now I had to align our pricing criteria to the marketing page and consider how this would flow into the welcome experience of the app.
I worked closely with the Director of Marketing to craft the message and usage of the pricing marketing page. There were many parameters to make clear and transparent to the user (buyer). Everyone liked the idea of a slider for the number of buildings, and this was a foundational item for estimating cost, so I knew that would be a prominent interactive component.
There was debate among the team about the importance of showing "gateway" costs, as most developers we were targeting here would likely never want the physical model and the virtual option was free. I always advocate for the most simplicity without losing any vital information, so I felt this could be handled separate from the slider and tier pricing, and it eventually was.
Three other elements of the pricing model that the Marketing Director and I felt were overload to getting users up and running were the API fee details, FAQs, and full feature list. In the end, the API fees became an FAQ, the FAQs were nestled into tidy accordions, and the complete feature list was tucked into a secondary page to accommodate all the info nicely on laptop and mobile screens.
Initial design that was built. The "term length" picker was eventually dropped to further reduce complexity. We also eventually added "sticky stops" to the slider to enhance expected behavior of the affordance.
Final Designs
You can explore the Figma of the initial mobile and desktop designs that were handed off for development below.
On the payment and data set up on the in-app flow side, I worked closely with our VP, CTO, and Lead Developer to mimic what we were creating on the marketing site. These two flows were being designed simultaneously. See them in Figma.
We offered a "free" forever model, but encouraged users to upgrade through thoughtfully placed prompts throughout the app. While I wanted these to be effective for the business side, I also didn't want them to interfere with the user's workflow. See them in Figma.
Discovering edge cases
As we rapidly iterated, we discovered some edge cases that we had to deal with pronto. One was for users that could be part of multiple organizations. Say they had an account through their business and also needed to access a personal account. We had not accounted for this and up to this point had no feature to allow users to switch. We remedied that. See the Figma.
Outcomes and Reflections
At the end of this project, we reached our goals to provide a smooth self-serve experience for developers to log in, pay, and get data uploaded to begin mapping all in one flow. You can see the final result here.
We spent over three months delivering the desired result, and we were able to deploy small-wins throughout the process such as launching the pricing page early, but having the payment tiers leading to contact forms, so we could collect emails for sales to contact and message at launch.
If I could have changed anything about this project, it would have been to deeply question edge cases before design and development began. We could have had a much smoother experience dealing with the array of issues that popped up along the way, such as the problem with the org switcher and the connectors.
All in all, this was a successful project that employed a nice flow between two design systems that I worked on (one for the marketing website and the other for the platform). We were able to get the single developer customer onboarded quickly and easily.
