Ascendon Account Hierarchies

First Research Method: General Inquiry

I started this project with a cursory read-through of the feature solution document (FSD) so that I could pick out key concepts to research independently. While account hierarchies aren’t super common among our competitors, both Salesforce and Oracle use similar structures for handling internal billing relationships. Salesforce documentation doesn’t share any screenshots of their account hierarchy UI, but Oracle seems to display client org structures as a folder tree:

Oracle seems to refer to each entry in the account hierarchy as a pay group; while this isn’t quite right for Ascendon’s audience, I do like how the relationships between pay groups are described as parent/child. This seems to be standard usage, as Salesforce describes relationships between entries in the same way.

Second Research Method: SME Interview

After performing the general inquiry, I read the FSD more in-depth and scheduled meetings with internal stakeholders. I targeted the assigned system architect and client solution manager for a more high-level understanding. I outlined my findings below.

Client Context: Our main requesting client, CBTS, provides dedicated long-distance and toll-free products to commercial customers in the North American region. These customers often have multiple taxable locations and different structural reporting needs. Ascendon account hierarchies will allow CBTS to represent each commercial customer's corporate structure. 

CBTS will use Ascendon account hierarchies to create their customers' corporate hierarchical structure based on the following criteria:

• Reporting Level (Invoice/Statement/None)

• Tax Locations within the corporation

• Entitlement Sharing rules within the corporation

• Logical representation of the given corporation.

CBTS does serve commercial customers that don't have multiple tax locations and only need to receive one invoice. However, these customers still need to be defined in an account hierarchy so that order orchestration can submit an order request and create the pass-through entities necessary for managing a large volume of services. 

System Constraints: The ordering component required by CBTS will only be available via API to expedite feature delivery. Account hierarchy orders will be tackled in the next release so the UX focus should be on creating, viewing, and editing the reporting structure itself. To simplify the logic, every direct-report entity will inherit its parent's attributes by default - including the address, profile, and reporting level.

Research Synthesis: Jobs-Be-Done Profile

I created a jobs-be-done profile for the research synthesis rather than a full user persona because we already had a foundation of knowledge about our users based on years of prior feature sprints and only required something lightweight. Also, because the nature of our work is B2B rather than direct-to-consumer, it can be dangerous to make demographic assumptions when you’re further removed from the end-user. Since this feature is being used in the context of work rather than fun or personal fulfillment, we don’t need to dream up someone’s life story to give them a tool with which they can complete a work task.

After conversations with the product and client success teams, we determined that client customers would require the following features to be delivered as part of the account hierarchy solution:

User Flow

I created the following user flow to articulate what new pages, page elements, modals, and actions would be required by the user to help them achieve their goals. I also used this phase to codify the nomenclature we should use to refer to elements within an account hierarchy. I decided that each entity in the hierarchy should be called a node and that nodes with direct reports would be considered parent nodes and their underlying nodes would be considered children (based on findings in the general inquiry).

Working with a Design System: Choosing Components

Visual design elements, such as color palettes and iconography are already codified in Ascendon’s existing design system.

The Ascendon platform consists almost entirely of text-entry forms and search result pages. I specifically chose this project to highlight in my portfolio because I knew that account hierarchies would necessitate a more tactile approach where I would have to balance inventing new solutions with working within the bounds of existing patterns that would be efficient to build for our developers and recognizable to our existing users.

You should recognize most of the screenshotted design system elements in my final design. I’d like to call special attention to the second screenshot that shows our table patterns. You’ll see a variation of the Rows: Data-Rows element in the structural presentation of the hierarchies. In this way, I modified and expanded on an existing pattern to make it fit our goals rather than working against our design system by creating something entirely new.

Wireframes

I started the wireframing process by sketching out the most complex problex, which was how to represent a visual relationship when that is something we’ve never had to address before. To keep things in line with our design system, I started generating ideas based on incorporating and stretching our table pattern.

Cross-Team Review Session

Unfortunately, Ascendon’s release cycle does not allot the time required to perform meaningful user testing and the design team has never been granted access to clients or their users. To view examples of how I conduct authentic user testing, you can view my later work. I hope to use this section to instead demonstrate how I successfully promote cross-team collaboration so I can still obtain actionable feedback, even if not from the desired audience. I’ll discuss these results in my conclusion.

Iteration and Conclusion

This was a challenging project in many ways. Ascendon is a simple platform that, before this feature, consisted almost entirely of forms and simple data tables. The problem presented by account hierarchies forced me to develop a wholly new conceptual structure to allow users to view and interact with customer data and relationships more meaningfully. I had to balance the need for this new concept with considerations of developer capacity. In the end, I was able to draw from an existing pattern to achieve this balance. As you can see in the affinity map above, the team was pleased with this solution. 

The second challenge of inventing new naming conventions for ideas that aren’t common in the telecom industry took some extra research and workshopping with my team. Still, thanks to my writing background, I was able to surpass the team’s expectations in this regard, also. 

The addition of account hierarchies signals a substantial change in the Ascendon platform, and therefore this case study only shows the first phase. With new feedback from my stakeholders, I now know to assume that clients will mainly be using this functionality when they likely have hundreds of nodes to manage. This new knowledge is highlighted as the second pain point in the affinity map; the noted solution will only be the first step in catering to the dominant use case. 

While designing this feature, I noticed some gaps and missed opportunities as they relate to how account hierarchies will function in the entire commercial Customer Care experience - mainly as it relates to our existing service ordering and transfer wizards and service consumption management. Thankfully, in my review session with product management, I was able to have these concerns addressed and scheduled in the product roadmap.

<<Back to List!