Software pricing design ​for IBM Tailored Fit Pricing

Sep 2018 - May 2019

Overview

In 2018, IBM delivered Tailored Fit Pricing (TFP) ​as a new pricing structure to our clients, which is ​based on a “pay as you go” utility method. This ​offering replaces the outdated and frustrating ​pricing methodologies and saves our clients ​money in the long run.

The design team was tasked with creating ​internal tools for our sellers to price software ​using this new structure. Being tight on research ​resources, I stepped in to assist our researcher, ​even though at the time I had no formal research ​experience.

Process

Research

I started the research phase with ​creating a research plan. I outlined ​phases, steps, desired outcomes and a ​rough time estimate. After getting input ​from the design researcher on my ​team, I finalized my research plan.

My first phase was to conduct ​secondary research with resources ​previously gathered by team members. ​This led me to developing questions I ​had about the team's pricing processes ​and software.

Having to better understand the user ​perspective of how IBM prices our ​software currently, I then drafted an ​interview protocol to find out more ​about these processes and any pain ​points. Main themes of the questions ​are outlined in the bottom right image ​(role responsibilities, software specific, ​process of pricing software, pain ​points, and suggestions).

After the protocol was drafted and ​looked over from the researcher, I ​started setting up interviews with ​members of the IBM pricing team. I ​conducted 6 interviews for a total of ​7.5 exposure hours with members ​across 3 continents.

Synthesis

After conducting interviews, I then ​synthesized the data I gathered. Using ​Mural, I mapped out all of the responses ​to the questions I asked. This allowed me ​to identify patterns within data to clarify ​common processes, pain points, delight ​points, and tasks.

From my synthesis, I produced a process ​map of how IBM's pricing team prices ​software. I outlined pain points and steps ​that the team has to take within the ​current tool they use to complete a ​client's pricing contract.

In addition, I created a persona to ​encapsulate the patterns I observed. I ​also detailed the responsibilities, pain ​points, internal relationships, client ​relationships, and tools used.

Lastly, I delivered a roadmap to integrate ​my findings into the the braoder team's ​workstream. The roadmap I created ​addressed IBM's pricing team's pain ​points with the current tooling as well as ​ideas on how to utilize their current ​processes in a new pricing tool that was ​to be designed.

UI design

From my research, I then moved ​onto designing interfaces for two ​pieces: the first being the new ​pricing tool that the roadmap ​addressed; the second piece being ​the a web-based “sales guide” to ​assist IBM sellers in understanding ​Tailored Fit Pricing.

The new pricing tool was to ​streamline the IBM pricing team's ​process in a simpler and easy to use ​format. While still encompassing the ​main features of the former tool, it ​removed the unnecessary features ​that were outdated or redundant. I ​worked on the interfaces for a few ​months until I passed them off to ​another UX designer. This concluded ​my work on this piece.

The second piece that I designed ​interfaces for was the web-based ​sales guide that assisted IBM sellers ​in understanding Tailored Fit Pricing ​and accessing sales enablement ​material. This sales guide was ​created by a previous UX designer, ​but lacked a component that ​detailed a newly delivered piece of ​Tailored Fit Pricing. My contribution, ​therefore, was designing the new ​pages that detailed this new piece. ​My process starting with low-fidelity ​wireframes and then progressed to ​high-fidelity after getting feedback ​from my team to ensure I was ​moving in the right direction.

I then uploaded these screens from ​Sketch into InVision to make a ​clickable prototype for the broader ​team to test.

Implementation

After designing the wireframes ​for the sales guide, I ran the ​wireframes past the team for ​feedback. I made iterations to ​incorporate the team’s ​feedback. I also had one-on-​one sessions with IBM sellers ​to better understand how they ​use seller enablement material. ​I was able to show the sellers ​early prototypes to get their ​feedback and incorporate their ​thoughts.

This then led to me ​collaborating with our front end ​developer so he could code ​and implement my designs. ​Through several one on one ​sessions, messages over ​Slack, and GitHub uploads, we ​managed to get the designs ​pushed out into the web, ready ​for seller use.

Conclusion

After passing the internal pricing tool to another UX designer and pushing the Sales Guide out, I was assigned ​to another project to work on.

If I had more time on the project, I would have loved to do follow up user research on the Sales Guide on both ​the usability and the content. This would have allowed me to understand how IBM sellers use the Sales Guide, ​what pain points they have, and if it could be improved.

In the end, I was pleased with the impact my research had on the team. I was also enthusiastic to learn ​research on the job and have a fabulous team member to mentor me through it. Looking back on my research ​plan, it is very high level and lacks a few aspects that I have learned to include, such as a constructed timeline, ​assumptions I aim to challenge, business impact of the research, measures of success, and specific tasks and ​methods to carry out the research.