Metratech is a company that provides a robust billing solution for enterprise-grade clients. The Metratech platform allowed clients to create complex online billing catalogs in order to charge clients for their products and services. One example would be a cable company, where the Metratech platform would produce pricing for customers depending on services purchased (cable tv and internet, for example) and region.
Prior to the commencement of this project, Metratech supplied only a rudimentary UI for building product catalogs and the real benefit of the platform for clients was the backend system. Metratech would need to send out engineers to go on site and hard code the billing solutions into the client’s backend. This was not expensive, so my team was brought in to develop a UI that would allow clients to create billing solutions for their products without any help from Metratech.
On a side note, Metratech was acquired by Ericsson in 2015. So not only was our job to modernize the interaction model, but to also align the platform with Ericsson UI conventions.
1
Overview – Before & After
The project’s main goal was to improve what was known as the Product Catalog. This is the area where a client can build a billing strategy. The Product Catalog needed to be easy to understand and easy to build with.
In short, the solution we came up with for creating complex product strategies on the Ericsson Metratech platform was to use a tree diagram to nest products into a visual hierarchy. The system we used for nesting followed this basic hierarchy:
- Stategies (often used to denote regions)
- Offers (often a primary facing product group or bundle)
- Products (a basic service)
- Rules (conditional rules for products)
Below, I elaborate on the process of designing this billing application.
Part 1:
Sprint 0 “Fact-Finding” Mission
We initially kicked off the project with a “Sprint 0” fact-finding mission where we did general product research, conducted user & stakeholder interviews, and built a flashy proof-of-concept for executive “buy in”.
2
Workshop
We began the project with a 2 day visit to Metratech’s campus in suburban Boston. The goal of the visit was to interview stakeholders, to learn about the current platform, and to define both achievable and aspirational goals for the new platform.
Activities:
- User Interviews
- Stakeholder Interviews
- Current Product Overview
- Product Goals/Aspirations
- Initial Sprint Planning
- User Personas
- Waterlines
3
Sprint “0” Documentation
For the first month of the Metratech project we got ourselves up to speed with the domain and the product through interviews, research, sketching, and finally building out a prototype. We reviewed our progress every week with the client. The goal of the weekly presentations was to build a comprehensive deck that would explain our learnings during Sprint 0 and our direction for the product prior to Sprint 1.
Activities:
- Customer Interviews
- Industry Research
- Competitive Audit
- Personas
- Service Model
- User Flows
- Sketching
- Wireframes
- Visual Design
- Invision Prototype
- Weekly Status Reports
4
Sprint “0” Prototype
The goal of this project was to create a Product Catalog, but we created a plan for how the whole Metratech system would work. To do this, we created a design direction during Sprint 0 to explain our concept of the “Modular Workshop”.
The notion of Modular Workshop is to create a platform where users of different types could assemble their own layouts to support their distinct job functions. The layout of the site is a canvas for templates that contains resizable modules. A certain user will choose the modules they want and will build a canvas template to support certain tasks.
While this concept was meant to appeal to the larger pool of Metratech users, we kept the focus on building out the Product Catalog. With the Product Catalog, what we wanted to showcase is the notion of creating product hierarchies using a visual tree diagram. The tree allows for visual nesting that better represents complex hierarchies.
The prototype was used by our clients to promote the project to Ericsson executives.
Prototype Demo
Part 2:
Full Project: Initial Framework
With Sprint 0 complete, it was time to kick off the full project. We only skimmed the surface with the initial work, and some of the ideas like the tree diagram were good, but we still needed to understand more complex functions of the Product Catalog such as pricing models, product strategies, and conditional rules.
Additionally, using the Ericsson UI system in a more prescribed way was now a requirement, so it required us to think more on how we wanted to structure the navigation and overall site map.
5
Participatory Design
With Sprint 0 complete, we held another workshop to kick off Sprint 1. We had our Boston clients down to NYC to review all of the work we created during the Sprint 0 to determine if we were indeed headed in the right direction.
6
Domain Model
During the first sprint, we needed to create a common consensus on how the application should be structured between Ericsson stakeholders and the staff at Idean. The focus would be determine the building blocks of the Product Catalog, known as the Object Domain Model.
Building Blocks of the Object Domain Model:
- Strategies
- Offers
- Products
- Lookup Tables / Price Lists
- Rules
- Overrides
7
Wireframes
While the focus was to build the Product Catalog component of Metratech, we also wanted to show how the user would get there and by forming a broader hierarchy for the full Metratech experience. We did this with an initial round of wireframes.
Metratech Hierarchy:
- Contextual Full Application Dashboard
- Product Catalog Dashboard
- Product Catalog: Library / Offer Studio / Product Studio / Tasks
Part 3:
Full Project: Sprint Work, Product Design, & Component Library
With the project framework settled, we began assigning features to subsequent Sprints, flushing out the component library, and collaborating with developers to build out the Product Catalog. The remainder of the project lasted for a few months before terminating due to budgetary concerns.
8
Final Design Vision
The highlight of our concept for the Product Catalog was the tree diagram composition component in the Offer Studio. All work went into making this a success. Future epics would encompass the Product Studio, Library, and Task Manager.
As a side note, we were tasked with using the Ericsson component library. While the header component used the library, the remainder of the app was largely bespoke, with stylistic references to the larger Ericsson system.
Objects within the Offer Studio
- Strategy – This is not sellable or selectable for the sales person. This is the node that holds the collection of changes/additions for the strategy. Where you can have multiple customer-facing Offers.
- Offers – Offers are containers for products and other offers. It allows product managers to package and rate products and services. They are maintained in Product Catalog Account administrators can then subscribe accounts to offerings or subscribers can self enroll in their self service portal. Behaviors/Features/Settings can be defined at offer level that determines it eligibility, compatibility, optionality, cardinality and so on.
- Products – It can be an NRC, RC or Usage type (Are there other types ?). This can be sold adhoc or grouped with other products to make an offer. A product is tied to a pricing model that determines how this product will charged/billed. A product is associated with Event Model. can be tied to a billable event that is metered from an external system (Usage) or it can be tied to a system generated event (RC and NRC). Product will have behaviors/features/settings associated with it similar to an offer.
9
Easy Construction of Offer Strategies
The concept of a project in the Product Catalog is known as a strategy. A strategy is a tree hierarchy component that is used to build out a billing plan for a client’s set of offers and products. Often a strategy is used to represent a billing plan for a geographic region such North America. This enables a client to augment similar billing plans for a specific audience.
The user of the Product Catalog can easily drag and drop offers and products onto the canvas of the Offer Studio to build out a billing plan.
10
Contextual Search
Users can search within the Offer Studio in numerous ways. The user can search through a whole strategy or within single levels of a strategy. This makes search for products and offers in complex strategies very efficient.
11
Assigning Rules to Offers and Products
The Offer Studio allows the user to assign rules to offers and products in a strategy.
Types of Rules
- Eligibility rules are a set of conditions that must be met to qualify for an offer or product. Typically based on account properties.
- Optionality rules can specify if an offer or a product is mandatory or optional.
- Compatibility rules specify which products and offers can work with one another.
- Cardinality defines a minimum and maximum quantity of offers and products a customer can choose.
12
Repositioning Widgets
The user can reposition widgets depending on monitor size and comfort.
Results
-
Set a standard for design-lead approach for building digital products
-
Became a model for enterprise web apps for Ericsson’s design system
-
First lengthy engagement for Idean’s new NYC studio
-
Project was eventually cancelled due to budget
-
Idean continued with more Ericsson work.