CloudSetu
Designing a multi-cloud networking platform from scratch, so teams can connect clouds and build network connections by drag and drop, with fewer steps and fewer errors.
Summary
CloudSetu is a multi-cloud networking platform for enterprise teams. I led the UX design from scratch: how teams connect cloud accounts, see their resources in one place on a Cloud Resource Map, and build network connections between cloud regions in a Configuration tab.
- The problem: every cloud provider has its own accounts, permissions, terms and network rules, so setup was slow, error-prone and dependent on senior engineers.
- How we learned: several days of in-person workshops with the client's stakeholders and users, together with my Calsoft colleagues (product managers, engineers, designers, managers and network engineers), all in the same room.
- What we designed: guided onboarding, a Cloud Resource Map for overview and details, and a Configuration tab where two networks open side by side and users connect them by drag and drop, with provider rules checked in the backend.
- What testing showed: users completed setup with fewer errors and less assistance, and reported higher confidence managing multi-cloud environments.
- Status: designed and handed off to engineering.
The business problem
The client wanted to give enterprise customers one place to manage networking across AWS, Azure and Google Cloud. The same pattern kept appearing in the sessions:
- Setup took a long time and needed senior engineers.
- Manual configuration led to errors.
- Complex tooling meant rising support effort and slow adoption.
Cloud account onboarding mattered most. It is the first thing a customer does, and each provider has its own sign-in, permissions and terminology. If it feels hard, customers never reach the rest of the product.
How we did the research
Instead of interviewing users separately and reporting back, we ran several days of in-person sessions with everyone who shapes the product in the same room: the client's stakeholders and the people who use the tool, and my team at Calsoft, including product managers, engineers, designers, managers and network engineers.
This mattered because a networking design is only useful if it can be built. Hearing a pain point and its technical constraints at the same time let us settle ideas on the spot instead of through rounds of handoffs.
Whose workflows we needed to understand
| Participant group | Workflow to understand |
|---|---|
| Cloud architects | Account structure, network architecture and cross-cloud design decisions |
| Network engineers | Networks, subnets, routes, gateways and connectivity rules |
| DevOps engineers | Repeatable configuration, automation and integration with delivery workflows |
| IT administrators and operations | Access, resource visibility, monitoring and operational troubleshooting |
How participants were chosen, and how we worked
| Question | Answer |
|---|---|
| Who took part | Client stakeholders and users across the four groups above, together with my Calsoft team. |
| How they were chosen | The client nominated their stakeholders and users. |
| Methods | Several days of in-person workshops. Workflow decomposition that mapped each drag action to a system event. Feasibility discussions with engineers on API readiness. Edge-case analysis of invalid states and failures. A comparison of enterprise networking tools to understand trade-offs. |
| What this means for the findings | Because the client chose the participants, the findings describe their organisation's workflows well, but they are not a representative sample of every cloud team. |
Questions we worked through together
- How do teams work across AWS, Azure and Google Cloud today, and where does it hurt?
- What should we improve or add, and is it practically possible to build?
- What can the system do automatically, so users take fewer steps and remember less?
- How can we make it clearer visually, prevent errors and handle them calmly when they happen?
What we found
Each finding is written as a gap: who is missing what, followed by the hypothesis we bet on (the "If we" line). This kept every decision tied to a person and a need. How I answered each one is in the Solution section.
1. Connecting an account
2. Seeing the environment
3. Building a connection
4. Getting feedback
5. Knowing the state
6. Repeating setups (later phase)
Signal and noise: what we focused on
The sessions produced more ideas and complaints than a first release could hold. Each one had to pass two checks: does it remove a real pain point, and can engineering build it? What came up repeatedly and blocked a core job was a signal. What was real but not needed for the first two jobs, connecting accounts and connecting networks, was set aside.
Signals we designed for
- Users were highly technical but short of time.
- Most errors happened during initial setup and topology configuration.
- The tools people use today assume expert knowledge and punish mistakes.
- People wanted clarity and control, not abstraction without feedback.
- Account onboarding was a high-risk first step, because of confusing external flows, permission errors and unclear validation feedback.
What we set aside, and why
- Reusable and exportable configurations: a later phase, so the first release could get onboarding and connections right.
- Analytics and trends: a later phase, once the core flows were in place.
- Separate Cost Management and Network Operations areas: they did not serve the two core jobs.
- Every resource editable on one canvas: Configuration opens two networks in detail, to keep the canvas readable.
Domain constraints that shaped the design
Public research on how the three providers differ shaped three design rules.
- Clouds scope and name networks differently (regions versus global networks, VPC versus VNet), so the map is anchored on regions with a shared label.
- Large setups use hub-and-spoke designs, so the topology is the first choice in the flow.
- Some limits fail silently, so the system validates before it creates a connection and blocks unsafe ones.
Sources: Pluralsight, networking services compared; Console Connect, July 2025.
Design hypothesis and principles
Why drag and drop was a business decision, not decoration
For users
- Less to hold in mind, because the relationships between networks are visible.
- Fewer invalid configurations, because interactions are guided.
- Faster understanding for people who are not experts.
- Fewer long, error-prone forms.
For the business
- Faster network configuration for enterprise customers.
- Less reliance on senior cloud engineers.
- Fewer configuration errors and support tickets.
- Better adoption and perceived ease of use.
- Consistent, not identical. Use familiar patterns across clouds without pretending the clouds are the same.
- Validate before you execute. Find problems before anything is applied.
- Explain, don't just reject. Say why something is invalid and what to do next.
- Less to remember. Let the system discover and offer choices, so users recognise instead of recall.
- Progressive disclosure. Show what matters first and keep advanced settings one step away.
- Be clear about state. Syncing, proposed, being created and done are different things.
The solution, as a prototype you can click through
I built the solution as an interactive prototype, so you can try the flows instead of only reading about them: look at the environment, drag to connect two networks, and see the guardrails step in. It uses sample data.
CloudSetu prototype
Dashboard, Cloud Accounts, Cloud Inventory, Cloud Networking (Overview, Configuration, Connections) and Policy.
Open the prototype ↗Opens in a new tab. Sample data only.The sections below explain the decisions behind it.
The product structure
I ordered the menu to follow the customer's journey, and gave each place that shows resources a different job, so nobody has to guess where to look.
| Menu item | Its job |
|---|---|
| Dashboard | Health and totals at a glance |
| Cloud Accounts | Connect and manage cloud accounts (Day 1) |
| Cloud Inventory | The searchable list of everything discovered |
| Cloud Networking | Three tabs: Overview (the map and how things relate), Configuration (build connections), Connections (status, edits and history) |
| Policy | The rules behind the guardrails: what is blocked or warned about |
| Analytics | Usage and cost, planned for a later phase |
| Settings, Help | Kept apart from the main journey |
Overview comes before Configuration because people look before they change anything.
The first release focused on the journey for a new customer, from first login to everyday use.
Provisioning & discovery
From an empty product to a full picture of the cloud estate.
Configuration
Connect two networks without leaving the screen or memorising details.
Monitoring & management
Everyday use: keep it healthy and change it when needs change.
The journey from first login to everyday use, redrawn from my original flow.
From insight to design
Each finding from the research has a design answer. This is the short version. The sections below show it in detail.
| Insight | How I solved it | See it |
|---|---|---|
| 1. Connecting an account | Provider selection, a short credential form, two designed error states, and a sync with visible progress. | Day 1 |
| 2. Seeing the environment | A dashboard with a resource map, a resource list and an accounts list with status. | Day 2 and More screens |
| 3. Building a connection | Draw-a-line connections on the canvas, a Create Connection form as an alternative, and pickers for networks and subnets. | Day 2 |
| 4. Getting feedback | Backend validation, with unsupported or unsafe actions blocked (with a reason and a similar option that is possible) or warned about, and clear messages. | Behind the scenes and Safety checks |
| 5. Knowing the state | Progress indicators, sync notifications, a progress dialog for new connections, and a Connections tab with status and history. | More screens |
| 6. Repeating setups (later phase) | Kept in mind and moved to a later phase, because the first release had to nail onboarding and connections. | Later phase |
Day 1: connect an account without guesswork
The user picks a provider, enters a label and the credentials for it, and connects. The form is kept as short as possible and uses each provider's own terms, for example an access key ID and secret for AWS, so engineers recognise what to enter. Everything else that differs between providers is handled in the backend, so the user doesn't have to learn each cloud's setup.
I designed the failure states on purpose, because that is where onboarding is lost:
- Error A: wrong credentials. The message says the key or secret is incorrect and lets the user retry. The user can fix this.
- Error B: verification failed. The message says the connection to the provider failed and to try again. This is a system problem, not the user's mistake.
After a successful connection, the user can start with the data synced so far, or add more accounts. A progress indicator and a notification when syncing finishes mean nobody stares at a spinner. The dashboard then shows the resource map and totals, and the accounts list shows each account's sync status.
Connecting an account: fill in the form, start with the data synced so far, then go to the dashboard.
Day 2: see the environment, then connect it by drag and drop
Day 2 happens in the Cloud Networking section, which has three tabs. The Overview tab (the Cloud Resource Map) shows all connected resources at a glance, and clicking one shows its details. The Configuration tab is where networks are connected, and the Connections tab lists every connection with its status and history.
The Configuration tab has two halves that work together. On the left is an Actions panel, where the user chooses what to connect: a topology (point-to-point, or hub and spoke), then for each of the two ends a provider, a cloud account, a VPC/VNet and the subnets to route, all picked from resources already discovered. On the right is a Topology View that shows those networks as cards with their status, and a proposed connection appears as a dashed line. Once the right networks are chosen, the user makes the final connection by dragging between them on the canvas, or with Propose connection in the Actions panel.
Dragging is quick, so connecting is a two-step decision. As soon as the user drops a line, the system checks it. If it is valid, the line turns green and a short review shows what will be created: the topology, the two networks, the subnets and the connection type (a site-to-site VPN). The user then presses Confirm, a progress dialog runs and ends with a Connection created message (traffic can now flow between both networks, with a shortcut to View in Connections), and the connection becomes a solid line with its details. If it isn't valid, the interface says why it isn't possible or safe, suggests a similar connection that is possible, and Confirm stays unavailable for the original request. If the user accepts the suggestion, the usual review and Confirm follow. Reset clears the proposal before anything is applied.
Clicking any network opens a details panel with its properties and its subnets, so the user can check what is inside before connecting it. Creating a connection can take a while, so a progress dialog lists each step (checking provider rules, creating a VPN gateway in each cloud, setting up the tunnels, updating route tables) and lets the user run it in the background. Progress stays in Notifications and the Connections tab, so nobody has to wait on the screen. A one-time dialog explains the ways to connect the first time someone opens the view.
Why drag and drop? We treated it as a usability and business decision, not a visual upgrade. It reduces the mental effort of linking information across separate forms, cuts the form-heavy steps where errors happen, and lets the interface steer people away from invalid setups. The form path stays for precision and for people who prefer typing.
Behind the scenes: how the system makes it work
A visual builder only works if the system behind it can interpret what the user does. Because our engineers were in the room from the start, we worked this out together and the design did not promise anything the backend could not deliver.
I mapped each drag action to the system events behind it, reviewed API readiness with engineers, worked through edge cases, and compared how enterprise networking tools handle similar tasks. Together we decided which configurations to automate and where guardrails were needed.
For invalid actions we used two levels:
- Block when a connection is unsupported or unsafe: explain why, suggest a similar connection that is possible, and let the user decide whether to proceed with it.
- Warn when something is possible but risky, and leave the decision to the user.
Safety checks that prevent mistakes
Together with engineering we decided which configurations the system could automate, where guardrails were needed, and when to block and when to warn. The result balances freedom and control:
- Backend rules constrain drag and drop.
- Invalid connections are blocked or clearly explained.
- Feedback is immediate and in context.
- Complex logic is abstracted, not hidden. Users can see why something is allowed or not.
This protects system integrity, builds user confidence and reduces costly configuration mistakes.
More screens
Screenshots of the prototype, with sample data and no client data.
Validation and outcomes
I ran task-based usability testing on three things: cloud account onboarding, network configuration, and whether people understood the system's feedback and constraints.
What we observed
- Users completed setup with fewer errors and less assistance.
- Onboarding time was significantly reduced.
- Users reported higher confidence managing multi-cloud environments.
- The product shifted from “expert-only” to operationally accessible.
Outcome and business value
By standardising account onboarding across AWS, Azure and Google Cloud, despite their different external flows and permission models, the platform is designed to remove a major deal-breaker step and cut configuration errors at the source.
The drag-and-drop network builder became a key differentiator of CloudSetu. It is built to make configuration faster and safer, with fewer configuration errors, less need for support and senior engineers, and better adoption across operational teams.
How I would put numbers on it
The designs were handed off to engineering, and I have no post-launch data. To put numbers on these observations, I would have network and cloud engineers do the same realistic tasks the current way, in each provider's console, and then in CloudSetu, and measure:
| Goal | Measure |
|---|---|
| Simpler onboarding | Account connection completion rate, time to first connected account |
| Fewer errors | Invalid-action rate, how many people recover from a validation error unaided |
| Clearer networks | Whether users can correctly explain the topology they built |
| More confidence | Post-task confidence rating, and whether they can tell proposed from applied changes |
What I would do next
- Re-test the built connection flow with more network engineers, especially the block and warn behaviour, and measure completion rate, errors and time to first connection.
- Add reusable and exportable configurations for teams that work through scripts and automation.
- Make permissions visible in the interface, so users know what they can and cannot change before they try.
- Bring in Analytics and trends once teams are using the core flows.
- Extend the same safety-check patterns to Policy and to troubleshooting.