Internal ops

The first step in every project starts off with an alignment meeting with our Product team members. We focus on 5 major areas:

1. The problem we are trying to solve and the impact on our users and business
2. Users and their goals
3. Complexities and risks that might exist
4. Project goals and timelines
5. Team members who will be involved

Why is this important?

Every project is different. Some are small and we know a lot. Some are big and we know things are going to be fluid. The initiation stage is critical for us to get initial understanding and align on expectations. Timelines and expectations are crucial to help us understand where we need to focus our efforts as well as how much Discovery we might be able to afford.

Initial research consisted of qualitative research with our internal users where we learned about how they currently performed their job and learned about their biggest problems. We also ran sessions to audit the ecosystem and look at the flow of how clients are setup and maintained.

What did we learn?

• Information is fragmented and spread across too many tools and apps. It takes so much time to just complete a single task.
• Auditing a customers current setup is extremely antiquated and there is not one source of truth. Multiple sources have to be checked.
• Big need for making changes in bulk. One-off requests are not the problem.
• 95% of setups are for returning customers. New customers is extremely rare.

After our initial research, we invested time with our stakeholders and internal team members to visualize the complexity that lies in this space. Visualizing the space helped us better understand and align with our product and business teams.

Deliverables

• Created and shared a map of the different teams and applications that are used to on-board a new (or returning) customer.
• Created a diagram to showcase all of the objects in the system and their relationship.
• We shared the synthesized data that was gathered from all of our sessions with our product and tech teams to help foster empathy across the team.

Since this project was planned to start soon, had many unknowns and would take a significant amount of time to reach its goal, we elected to lean on an object oriented framework to help guide our decision making and set a foundation for scalability in this solution. The first phase of ideation, was creating high-level visualizations for major user task

Primary Objective

• Demonstrate how this framework would manifest across the major user tasks
• Represent how we would structure the content based on the objects and their relationships
• Visualize a repeating pattern that could be used for future scenarios
• Show how we could handle major user type scenarios
• Give our tech teams a sense of the scope.

How do we get there?

Being a multi-year project in a SAFe agile environment, we worked with our product team to create a roadmap that could guide us. The business was going through some changes on their commercialization strategy so it was important to define the direction and planned phases

As an internal tool with easy access to its users, we were fortunate to have constant touch points with them to get their feedback early during the ideation phase so that we could pivot quickly.

Constant Permission Model Changes

During the evolution of how the company would commercialize their flagship product, there were multiple changes in the architectural approach in how users would be permission to data. These changes had huge impacts on how the internal tool would be able to manage those permissions. We went through 6 different iterations of designs as those architectural decisions kept changing.

Design showcased its value in the midst of this confusion by quickly iterating. The low fidelity visualizations and flows were key in aligning the product and tech teams in a space with a great deal of complexity.

Data Coming from Separate Sources

As we pushed to have one tool for our users to support their work, we had to deal with the realities that data would be coming from multiple data sources which means we wouldn’t be able to serve up some simple expected UI features so we had to compromise in our designs.

For example, in our organizations view, we wanted to show orgs by default to help decrease the time it took to navigate to an organization by allowing them to easily access frequently managed clients.

We had to compromise by having users search for a provider by a unique query that would reach across multiple sources. Although this wasn’t aligned with quicker navigation, it kept the functionality simple and didn’t require the user to deal with the complexity of multiple data sources

Leaning on the Object Oriented Framework

We had two separate initiatives come to the design team that was trying to solve a problem for two different user groups.

1. Support teams wanted a way to clone a user’s specific asset so they could find out where a reported problem was coming from
2. Commercial teams wanted a way to bulk transfer assets for users who left their respective organization

With the object oriented philosophy we were able to easily identify how we would handle this. Users were an identified object in the system and assets had a simple one to many relationship to a user.

Since the user is a unique object, it made sense to locate it at the global level alongside the other global objects.

Image labels: EPIC 1 – Clone User Assets · EPIC 2 – Bulk Transfer User Assets

As a team lead of several different verticals, it was important that we leverage ways to scale our work. Figma libraries were used to extend our design system library by building versions that are specific to their respective areas that included major pages, views and components.

I also built a low-fidelity library as well as a library for FigJam for visualizing hi-level flows.