GOAL
Enable environments to clearly separate resources and user permissions while aligning with the software development lifecycle practices teams already use across their tooling.
1
Introduce environments as a first-class platform concept so resources, workflows, and context can be shared consistently.
2
Evolve the existing environments model beyond Event Portal without breaking current mental models or workflows.
3
Extend environments into Mission Control and other product areas that need to operate inside of environment boundaries.
4
Design a cohesive, platform-wide system that allows all products to work together seamlessly while supporting scale and governance.
METRICS OF SUCCESS
👍 Environment management lives outside of a single product area
👍 Environments are configurable to match real world relationships to each other
👍 Teams are segregated in their environments
👍 Build off existing environments so users don’t need to re-learn navigation
👍 The current environment in must be identifiable at all times
👍 There is a consistency of experience across the platform
👍 Users can navigate to different areas while staying in the same environment
CONTENTS
1.0 Discovery
Uncovering user needs, business goals, and technical constraints through research and stakeholder interviews. Defining the problem space and identifying opportunities for innovation.
2.0 MVP & Vision Strategy
Prioritizing core features for a minimum viable product while establishing a long-term product vision. Balancing immediate user needs with strategic objectives to create a focused roadmap.
3.0 Design & Implementation
Create detailed designs, prototypes, and specifications, then collaborate with engineering to build and iterate on the solution. Refine the user experience through feedback and testing cycles.
4.0 Post-Implementation
Validate the deployed solution with real users to measure success, identify issues, and gather insights. Use findings to inform future iterations and improvements.
1.0 DISCOVERY
Why Environments Matter
In a cloud-native event infrastructure, environments aren’t just labels. Solace Cloud uses environments to organize work across teams and lifecycle stages, letting organizations segment capabilities for dev, staging, and production use. This structure supports safer deployments, clearer ownership, while allowing resources to be shared across distributed teams.
An example of how products and resources live inside and outside of environments
Satisfying A Customer Need
Environments are used in many enterprise products as a governance and workflow framework. Instead of one monolithic space for all resources, users can separate them into environments. Each environment are then configured with differing controls, runtime policies, and deployment expectations, enabling clearer handoffs between stages of the delivery pipeline.
Because our platform was scaling, we needed to implement this key feature, match our competitors, and give our customers more control over their systems.
1
Solidify product requirements, use cases, requirements, and personas
2
Create a user research test plan
3
Interview subject matter experts to understand feature expectations and gather user needs
4
Use interview findings to provide context for a stakeholder user journey workshop and align with business needs
5
Research competitors to understand existing implementations
Note: Research details cannot be given due to proprietary information.
2.0 MVP & VISION STRATEGY
For this platform-wide feature, the product owner and UX worked together to break milestone features into a clear MVP and longer-term vision. I focused on defining the end-to-end happy path, while the product owner defined scope and priorities based on impact, risk, and dependencies.
1
Smoothing out dependencies between resources that live inside and outside environments and minimizing chained errors
2
Allowing power users to view and manage segregated resources across all environments without having a centralized resource page
3
Migrating high volumes of existing customer resources into environments
4
Consolidating existing customers accounts which were used as a workaround without environments
5
Coordinating efforts and reducing knowledge drift across all teams and domains
A big challenge was not having an environment agnostic resource page for Middleware Integrators to manage their services. So I added a toggle in the environments menu that turned environment filtering on and off for their resources
6 User Persona Needs
3.0 DESIGN & IMPLEMENTATION
I partnered closely with product owners, architects, development leads, and engineers to design multiple user flows for our personas. Together, we mapped complex scenarios into clear, intentional pathways that satisfied user, business, and technical needs. This collaboration resulted in a cohesive end-to-end user experience throughout the entire platform.
1
Environment creation and configuration
2
User's first time use and default views
3
Navigation into environments through 3 levels of hierarchy
4
Resource creation inside environments
5
Managing datacenters inside environments
6
Navigating between products outside of environments
7
Navigating between pages and resources that straddle environments
8
Other role and permission scenarios
Pages of exploration, high-level mocks, detailed designs, and visual specs
Final Design Examples
4.0 POST-IMPLEMENTATION
User Validation
After implementation, we validated the feature with 5 subject matter experts. Using the original product requirements, we walked through 3 flows and asked them to complete 6 tasks. Feedback was largely positive. Each participant shared what they liked, their pain points, and how the experience aligned with their expectations.
✅ Successes
Everyone felt that environments was a great feature and filled a missing need
Everyone loved the icons and colours used to visualize environments
Everyone agreed that it meets expectations for how it should work in a SaaS product
🚫 Pain Points
Implications of deleting environments weren’t clear
When asked, everyone expected having the ability to move services between environments, but the process wasn't understood
Everyone felt that services in a single region should exist across multiple environments
Navigation wasn’t consistent with participants’ mental models
ONGOING EVOLUTION
Environments is launched 🚀
With no critical usability issues identified, the feature was validated as a successful design. A set of targeted enhancement tasks were created to incrementally improve clarity and guidance, which will be tackled in upcoming roadmaps. This will allow us to continually work towards our vision, and for the feature to scale sustainably as additional products are added over time.
