AIRSPACE · CUSTOMER PLATFORM
Unlocking Aerospace Growth by Fixing Vendor Access
At Airspace, I designed multiple flows across 3 features to support a new user role for the customer platform. These updates enabled customers to add third-party vendors to access their accounts in a limited capacity and place orders on their behalf.
Impact
Streamlining account/user access for vendors led to 39 orders placed through this new role within a month of release.
Core Team
1 Designer (me), 1 Developer, 1 Product Manager
Role
End-to-end Product Designer
Duration
6 weeks | May 2023 – July 2023
Note: Certain details are left out and images are intentionally blurry/cannot be viewed in higher resolution to adhere to an NDA. To learn more about this project, please contact me directly.
Project Brief
The Context
What is Airspace?
Each Airspace customer has its own company account, accessible through the customer facing platform, and team members are added to it by email. Their user role decides what they can do, from placing orders to tracking shipments in real time.
The Business Problem
Our platform restricted business with certain customers who had their own third-party vendors
In 2023, Airspace aimed to grow aerospace revenue from $2M MRR to $4M MRR. Product and account management discovered that aerospace customers often relied on third-party vendors to place orders, but the customers weren't always choosing Airspace.
These vendors fit a combination or one of the following profiles:
The Workarounds
Our login system limited each email address to a single company account
For example, spongebob@kp.com could belong to "The Krabby Patty"'s company account, but not on "The Chum Bucket"'s company account. So customers and account managers hacked around this in two ways:
Nesting vendor sub-accounts under each customer account
Vendors needed separate credentials (for each of their own employees) for every Airspace customer, causing friction and lowering user traffic
Customers had exposed pricing/tracking data that they didn't want their vendors to see
With more accounts nested within a company's main account, account structures got confusing fast
Entirely separate accounts were created for the vendors to use
Vendors still had to juggle multiple logins
Customers could not track the shipments placed on their own behalf, breaking the transparency that Airspace promised
The Challenge
How might we let vendors order for multiple customers without customers losing control of their data?
The catch: My team had 6 weeks for both design and development.
Design Process
Brainstorm & Ideation
Auditing the existing roles pointed me and my team to a new one, instead of another workaround
I audited our user roles and permissions to anchor team discussions. After weighing feasibility and scope across several options, we introduced a "vendor order placer" role: one in which an email could be assigned to across multiple company accounts, alongside any role it already had.
Unlike existing roles, emails assigned to this new role could be under multiple company accounts and sub-accounts with the same role, or any other existing roles (in cases where an email already existed under their own company account). Thus, the 1:1 email-to-account restriction was no more.
Prioritization
My team scoped an MVP by prioritizing issues we gathered from our stakeholders and from auditing system capabilities
This set a clear design scope for myself and let the developer start reworking the account architecture in parallel, which mattered given the 6-week timeline.
Task and User Flows
Mapping flows across user groups surfaced unanswered questions like who gets notified when a vendor acts
I took these open questions to my team, stakeholder feedback sessions, and customer feedback to resolve them.
Stakeholder Feedback
Internal testing surfaced gaps around legal terminology and new use cases
From testing two prototypes (one for adding/removing vendor users, another for navigating the customer platform as a vendor) with our account management team, I uncovered a few insights:
Legal needed to spell out exactly what the role could do. The terms and conditions needed more explicit information to describe this new vendor user role.
Customers wanted more guardrails. For example, hiding prices from vendors or limiting their routing options.
Customers will often create will call orders — prepared, but inactive shipments to activate at a later time to fulfill — and needed to assign specific vendor(s) to activate them
Will calls needed a vendor access. Customers often created "will call" orders (which were prepared, but not yet live orders) and needed to assign specific vendors to activate them later.
I folded the first two into the prototypes and the usability test plan.
Prioritizing for the Future
Will call activation was a real need, but we could not fully scope it into the remaining project timeline
I mapped a task workflow of will call activation to discuss scope with my team. Given we could not fully address this request, my team instead laid the groundwork support future iterations:
The developer updated the backend schema for a separate "will call activator" role. Both this role and the order placer role could be assigned to a single email address, giving companies role assignment flexibility.
I simplified the "vendor order placer" role name to "order placer" in the UI. This matched how vendors could have more than one different role in future iterations.
Usability Testing
Three rounds of customer testing led to more iterations on access limits and confirmed will call activation requirements
From testing, we learned a few new insights and verified the following:
Some vendors run their own ordering platforms. Customers order there and enter their Airspace account details. The vendor then books the shipment with the customer's Airspace account.
Routing could stay locked. Customers were fine defaulting vendors to the "fastest" option, and vendors already followed these procedures.
Vendors only needed tracking information, not the full order details after placing an order.
Will call activation was confirmed. Customers want their vendors acting on their behalf to activate them.
The vendor platform integration was out of scope for our timeline, in addition to the already-scoped-out will call activation. To wrap up, I worked with the developer to limit routing options and tracking access, and finalized the MVP.
Conclusion
Final Designs
What shipped: Three flows built to give customers control and vendors a clear, limited path to placing orders
New flow to add the “Order Placer” role
Centralized page to switch between company accounts
Revised order placement process for the "Order Placer" role
Results and Impact
39 orders were placed through vendor users across 4 company accounts in the first month of release
We released the feature at the end of July 2023. Sales used it as a differentiator in aerospace deals, and account management simplified support for vendors working across multiple Airspace customers.
Reflection
Speed forced trade-offs, starting with early, upfront research with the customer
Push for more research before kickoff
Customer access was hard to get, so we leaned on stakeholder insight. Earlier customer research would have surfaced vendor platforms and will calls before they became deferrals.
Working with a time constraint
Six weeks meant re-prioritizing and discussing work constantly; ongoing scoping talks kept the MVP focused.
Involving my team at every step of the way
Having my product manager and developer in nearly every meeting was invaluable. As a result, we had little misunderstandings and let us build scalability into design and development as new insights arrived.
Next Steps
Will call activation is still highly requested
The schema already supports a will call activator role. Building it out would open more order volume from customers and their vendors.
Can't get enough of my work?
Well you're in luck—here's another project
you can read up on ➡️
