Your customersThe partner workspace brings customer domains and assigned account managers into one list.
Product
Snow Atlas / Partner Layer
My role
Research and discovery; low- and high-fidelity design
Collaborators
Researcher, design team and stakeholders
Focus
Partner workflow
01 / Context
A partner needs to know where they are working.
Snow Atlas spans customer accounts and several product areas. A partner working across organisations needs a reliable way to find the right customer, manage the relationship and enter the appropriate environment.
The design problem is a shift of scope: from a portfolio of customers to the data and tools of one organisation. Every action depends on that boundary being clear.
01 / Find
Locate the organisation
Search a customer portfolio and identify the account to work on, even when domains and names look similar.
02 / Manage
Understand responsibility
See customer information and the people assigned to that relationship before making a change.
03 / Enter
Keep the customer context visible
Move into Snow Atlas with a clear indication of whose environment and data are in view.
Scope of the material
The supplied screens include partner application concepts, customer-environment screens and broader analytics explorations. They illustrate the proposed experience; production status and measured outcomes are not established by the material.
02 / Workflow
From portfolio to customer context.
The main journey connects the partner’s overview with a selected customer and the products available to that organisation.
Step 01Find a customer
Start in a shared list of customer domains.
Step 02Review the account
Check details and assigned managers.
Step 03Enter the environment
Switch to the customer’s Snow Atlas context.
Step 04Work in a product
Continue into the relevant SAM, SaaS or Containers area.
Customer details and managersA side panel keeps the customer list in view while a partner inspects a domain and changes its assigned managers.
Partner access and customer contextThe switcher connects the partner application with a selected customer environment; the current domain appears in the top bar.Inside a customer environmentOnce a customer is selected, the interface exposes that organisation’s Snow Atlas products and software spend.
03 / Design decisions
Make the critical boundaries visible.
The screens explore how partner tasks and customer tasks can remain connected without losing the organisation in view.
01
Keep account details beside the list.
The customer panel opens over the portfolio, allowing a partner to inspect the domain and assigned managers without leaving the list. The list remains a reference point for the task.
Design consideration. Editing managers, deleting a customer and entering their environment appear in one panel. These actions need distinct labels and stronger separation because their consequences differ.
02
Show whose environment is active.
The access bar names the selected customer domain above the Snow Atlas interface. The partner can move back to the partner application through the same navigation pattern.
Design consideration. A single, persistent switcher would make the current scope easier to verify before the partner changes settings or customer data.
03
Expose package state in one workspace.
The package builder brings operating system, version, specifications and status together in a searchable table. Partners can recognise available, in-progress, outdated and failed builds.
Package builderAgent packages are listed with their operating system, version, specifications and build status.
Design consideration. A failed or outdated status needs a route to the cause and the next action; the label alone does not help the partner resolve it.
04 / Further exploration
Find opportunities across customers.
Additional mockups explore an overview of users, contracts, licences and potential optimisation across accounts. They point toward a partner view that helps prioritise attention across the portfolio.
Important insights across customersA concept for prioritising potential optimisation across the partner portfolio.
Customer-level insight detailThe concept opens a customer panel to inspect product areas and a possible savings opportunity.
Overall summaryAn exploration of aggregate users, contracts and licences, with supporting charts.
These are concept screens. The example values in the mockups are illustrative. A usable savings estimate would need its timeframe, data source, calculation and an action leading to the affected records.
05 / Evaluation
Check whether the partner can act with confidence.
The work included a Figma prototype for usability testing. The available material does not document participant counts, task results or a verified post-launch effect, so the questions below describe what this experience still needs to establish.
What the artefacts show
Workshop and journey material, information architecture exploration, wireframes, interface concepts and a prototype used for testing. The source page also mentions a presentation of test performance and proposed refinements.
What needs a clearer record
Which partner tasks were tested, what participants struggled with, which design changes followed and whether the revised flow was tested again.
Choose the right customer
Can a partner find and distinguish the intended organisation in a large customer list?
Understand the active context
Can they tell whether they are in the partner application or a customer environment before taking an action?
Resolve a package problem
Can they identify why a build failed or became outdated and find a useful next step?
Trust an optimisation insight
Can they explain how a proposed saving was estimated and locate the users or licences behind it?
06 / Contribution & reflection
Designing for many customers means making scope explicit.
The partner layer brings relationship management, access and product workflows into one connected experience. The strongest design question is whether a user can move between those layers without losing track of responsibility or context.
My contribution
Research and discovery, low- and high-fidelity design. The wider work included workshops, information architecture exploration and a prototype for usability testing, prepared with a researcher and the design team.
What I would refine next
Make the customer switcher consistent, separate account actions by consequence, give package errors a recovery path and connect each optimisation estimate to its underlying data and next action.