Azure SQL vCore pricing model

Objective

SQL is moving to a new pricing model

This will enable custom configuration of performance and storage

Design an experience for new and existing customers

Scale pricing pattern across multiple products within Azure SQL and [C+E]

My Role

I was the UX Design Lead for this project. During this project my responsibilities were:

  • Helped established business goals and mapped to user/customer needs
  • Mapped the user flow and designed wire-frames
  • Creating high fidelity mocks and prototype flows
  • Met with partner teams and gained buy-in for new business model
  • Assisted research team with user studies

Partners

  • 1 Researcher,
  • 4 Project Managers (working across different products within Azure SQL)
  • 5+ Engineers (working across different products within Azure SQL)

Journey

Where we were

Leveraging some prior usability studies and outreach programs we found a major barrier existed between customers understanding SQL’s pricing structure and how it could be applied their current data needs. This issue grew with the reality that each SQL database product had their own pricing metric.

Azure SQL Database: DTUs/eDTUs

Azure SQL Data Warehouse: DWUs

Azure SQL Elastic Pools: eDTUs

Azure MySQL Server: CUs

What made these metrics difficult was that it was not easy to correlate a value to the real world.

For example: The DTU/eDTU model did not showcase how much CPU, Memory, IO was allocated per a DTU. There were online resources to help calculate a potential DTU range but there wasnt a pure formula on how those metrics built a DTU. Along with this it took up to 30 days to determine if the amount of DTUs selected was correct. This could cause bigger issues for a user in the first month. All around throttling or over-spending.

You can see some of confusion within reddit posts, like this one.

Outlining pain points and goals

Customer pain points:

  • Customers dont have visibility into their system
  • Customers don’t have flexibility
  • Customers pay for capacity they don’t use
  • Our offerings are hard to comprehend.
  • Each product has a different experience

User Experience Goals:

  • Customers know what they are getting
  • Customer are not surprised by their bill
  • Can choose their capacity and functionality
  • See value in our new offerings.

It is important to note that with any project you need to also assess what is important to the business. This was no different. I worked closely with my PM and Leadership to determine what their goals were and how they would align with our UX goals.

Business Goals:

  • Old model will exist with new model
  • New world is the future
  • Be transparent but not to much
  • Consistency
  • Growth in profit margin

An important goal mentioned here is around transparency. We want to be transparent but not so transparent that we are no longer competitive in the market. This is a stark reality when working in data, to build more performant systems you may have technical specs that sound less impressive then your competition. This could lead to a lack of faith/trust from your users and lower the bottom line. So this work needs to instill confidence in our dev community and help grow the cloud platform effectively and ethically.

Wires and iterations

The next stage was to start mapping out the flows and how this new vCore model will integrate with our old world of DTU/eDTUs. This goal was focused on creating an experience that was intuitive and consistent with our other products. This required me to lead efforts with the PM and engineering team to fine tune our message and UX goals.

Early wires focused around these concepts: old tiers and new customizable tiers. The new Tiers would provide our customers more freedom and be founded in industry standard terminology. This would make the process of allocating more resource and migrating to Azure less prone to friction.

Migration became a huge piece of this puzzle since all on-prem systems used a concept of CPU and cores. Before this project Azure SQL had not talked about their performance in that connotation.

These explorations would lead us to creating a dual world where we maintained our old pricing and new pricing models. Foundationally, this was temporary and the pricing models would help encourage customers to migrate to the new vCore model. But from a business standpoint we did not want to make it feel forced and knew that changes in DB resourcing is not something taken lightly by large companies.

Below shows the high fidelity user flow:

Breaking down the new pricing pattern

What you will notice here is the overall breakdown of an azure blade and how other partners can consume it. If a team doesn’t have “pricing tiers” then the tabs on top disappear and they just have the commands, control area, and the cart. This is also how I promoted this content across other partners and ensured our SQL products were building a stronger alignment in our overall pricing story.

  1. Top level commands: Allows the user to save, cancel, or send feedback
  2. Pricing tiers: Names for tiers should align with what the user needs from the DB. They are templates that help them get started with their pricing selections
  3. Control/Form area: Here the user can adjust and manipulate their tier to fit their data needs.
  4. Shopping cart: This cart helps bring visibility into how the monthly bill is determined. The target is to build confidence and trust in our users.

Variations of the shopping cart

Each shopping cart variation enables scenarios for our teams. These are some of the options but not all that is possible within the cart. The idea behind this was that it needs to be open enough to encompass different needs while always maintaining its foundation.

Create
Additional charges & animation

Create
No additional charges

Management
Charting control integrated

Create and/or Manage
No top level animation/chart

Expanding pattern to partner teams

Once a solid foundation was built for SQL database’s pricing model I move the pattern across multiple other teams within Azure. This was the integration of the new design as well as the use of vCores.

Azure SQL Database

Azure MySQL Server

Azure SQL Elastic Pools

Azure SQL Managed Instance

Outcomes

SQL databases new pricing experience launched in the spring of 2017. From the get go we saw an increase in customers manipulating their database levels as well as positive feedback around our development community. The vCore model was able to provide a more streamlined pricing structure for users coming from on-prem as well as demystifying the way our data stacks work.

This design was also patterned and integrated into several other products within Azure, as a new way for them to handle “tiers” and customizations. As well as leading the way to Hyper-scale, an accelerated performance tier targeting large scale businesses.

I am currently leading a new initiative to further update the experience, unfortunately that will have to wait to be shown until it has GA’d.