Cloud platform redesign & information architecture

01Context

A console that has to sell servers too

Arvan Cloud is an Iranian cloud and CDN provider. Businesses use its console to buy and run cloud servers, store files and deliver content. Sina worked there full-time as a product designer, on the console’s interface and its information architecture.

A console like this does two jobs. It is where customers manage what they already run, and it is where new customers buy their first server. This study follows the second job, from the public website to a running server, and then shows console pages from the redesign, all of which shipped: the wizard’s last step, the server list, the server page and the file manager for object storage.

02Problem

Two places where buyers were lost

The research named two problems. Visitors to Arvan’s website rarely made it into the console to buy. And people who did start the create-server wizard dropped out while trying to work out which resources they needed.

Google Analytics showed the first one. Of the site events tracked for this path, about 90 in 100 were home-page views and 9 were visits to the cloud-server page. About 1 was a click on that page’s button on the home page, and fewer than 1 was a click on Buy.

The usability test board, dated September 2021, shows why. It records a session with a developer two years into full-stack work, on a 1366 × 768 screen, who wanted to set up a Windows server with a hosting panel. The participant’s main questions were about the product itself: what is the difference between cloud and hosting, is a cloud server the same as a virtual machine, and should they buy a server at all or a hosting plan? Then, about the console: “Why doesn’t this panel have an explanation, so I can understand what’s what?”

Each finding on the test board is filed as a copy, design, product or technical problem:

No introduction led from the console’s home to the cloud-server product, and the other cloud products around it distracted rather than helped.
The names didn’t match: the website said “cloud server”, the console said IaaS and “cloud computing”, and the product page introduced “Abrak” without explaining it.
A bug skipped the first-visit page, so the participant landed on “You have no servers” without ever seeing it.
The create-server button and the guides weren’t clear.
At the size step the decision criteria were complex, and the tabs didn’t read as parts of one choice.

The test and the analytics agreed: people were lost first in words, then at the size step.

Two Google Analytics charts: event shares for the home page, the cloud-server page, that page’s button on the home page and its Buy button; below, a funnel from the cloud-server page into the console’s create-server wizard, its counts blurred — Figure 02Google Analytics, from the site to the console: most tracked events were home-page views, and few reached Buy on the cloud-server page. The counts are blurred.

03Research

Choosing the analytics tool

Sina wrote the team a requirements document for a user-behaviour analytics tool and presented it. The tool had to capture behaviour without events being set up first, be simple enough for every team to use, turn goals into shared metrics, and never slow the product down or weaken its security. Google Analytics, Mixpanel, Amplitude, FullStory and Heap were compared, and Heap was chosen: it records every interaction, so a new question can be answered from behaviour already captured, and it had run without trouble on the panel for several months.

A board in Persian titled “Requirements for a user-behaviour analytics tool”, presented by Sina Oshaghi: what the team needs, the five tools considered, and the reasons for choosing Heap — Figure 03Two of Sina’s research boards, in Persian: the requirements that led to Heap, and the metrics the console would be judged by.

A board in Persian titled “Panel-side metrics”: conversion from the panel home to the server list, from the list to a new server, and from choosing a data centre to the end of the wizard, and a score for how hard creating a server was — Figure 03Two of Sina’s research boards, in Persian: the requirements that led to Heap, and the metrics the console would be judged by.

04Tracking plan

Measured by user-flow conversion

The whole flow was measured by conversion: of the people who reach one screen, the share who reach the next. Panel-side metrics set the three conversions the console would be judged by: from the console’s home to the server list, from the list to a new server, and from the data centre to the end of the wizard. A score at the end of the wizard would add how hard creating a server felt.

A tracking plan then took the flow screen by screen, one board for each, dated September and October 2021. Each board numbers the screen’s elements and says, for each one, what to record, with which tool and why: Heap for clicks, time and drop-off, Arvan’s BI for the operating systems and marketplace images installed, and Hotjar or Hantana for heat maps. Across the boards that meant clicks and time to find the create-server button, drop-off at every step, which data centres and operating systems people pick, how far they scroll the size tables, how long they stay on the custom size, whether they add private networks or firewalls, create several servers at once or rename them, and whether they copy their server’s details on the last page.

Heap turned the wizard into a seven-step funnel: the server list, the data-centre page, then choosing the operating system, the size, the access method and a name, and finally the server’s details. Each move from one step to the next was measured four ways: how many people made it, how many interactions it took, how long they spent, and how many left the product and came back.

One step stood out on every measure. After choosing a size, only 73.09% moved on, against 89–99% at every other step. That move took a median of 5 interactions and 23 seconds, about twice as long as the others, and 3.8% of people left and came back before going on, the most of any step. Choosing the operating system lost people too, above all those looking for something beyond the popular systems or in the marketplace. Overall, 52.19% of the people who started the wizard finished it.

Choosing a size is the one step that asks people to predict what their project will need. It cost the most clicks, the most time and the most buyers.

A board in Persian from the tracking plan for the console’s home: the screen with Arvan’s products and the cloud-server tile numbered, and below it the measures: the way into the product, time to find the button, drop-off and a click heat map

A board in Persian from the tracking plan for the cloud-server page on a first visit: an empty page explaining what an Abrak is, with a New server button, and measures for finding the button and the guide, drop-off, success after reading the guide, and a heat map

How the work ran

01
ListenA moderated usability test, surveys, and every message to the company on Twitter and Instagram
02
ChooseRequirements for an analytics tool, five tools compared, Heap chosen and presented

A Heap funnel of the seven create-server steps, from the server list to the server’s details, with the conversion between each pair of steps; the drop after choosing a size is the largest, and 52.19% finish — Figure 05Heap’s funnel of the create-server wizard: the largest drop comes after the size step (73.09% move on), and 52.19% finish.

Heap’s effort analysis of the same seven steps: conversion, interactions, time engaged and revisit rate between each pair of steps, all at their worst after choosing a size — Figure 06Heap’s effort analysis: moving on from the size step takes the most interactions, the most time and the most revisits.

05Solution

Two ways to choose a size

Sina designed the size step two ways. Both keep the same frame: the title “Choose the server’s size”, four tabs for general, memory-optimised, compute-optimised and custom servers, and Back and Confirm buttons. They differ in how a size is picked.

Option 1 lists ready-made sizes in a table, grouped by scale and starting with the small ones. Each row gives the CPU, memory, SSD, base package and monthly price, and a note above the table explains the two hardware generations. One row is already selected, so someone unsure what to pick can still go on.

Option 2, the custom tab, sets processor cores, memory and disk with three sliders. A card beside them updates the price per month and per hour as they move. A size built with the sliders costs the same as the matching row in the table.

Two versions of the choose-a-size step, in Persian: option 1, a table of ready-made sizes with CPU, memory, disk and a monthly price; option 2, sliders for CPU, memory and disk beside the monthly and hourly price — Figure 07The size step two ways, both shipped: ready-made sizes in a table (1), or cores, memory and disk set with sliders and priced as they move (2).

06A/B test

What the A/B test showed

Sina ran an A/B test of the two designs, with conversion as the measure. Heap’s report on it grouped people by the control they used at the size step: of everyone who started the wizard, 44% set a size with the sliders and about 1% picked a row from the table. The rest touched neither.

Everyone in the slider group reached the size step, against 87.74% of the rest. In the Heap presentation, Sina offered that gap as the start of a hypothesis, not a verdict: the size step offers too many choices in a complicated interface, so fewer choices and a simpler control should get more people through it.

That caution was right. The slider group reached the size step by definition, since the sliders only exist there. At the end of the wizard the two large groups were level: 52.04% of slider users finished, against 52.30% of the rest.

People clearly preferred setting their own size to reading a table. The preference did not turn into more finished servers, and both designs shipped, as tabs of the same step.

Preference and conversion are different results: the sliders won the first and left the second where it was.

Heap’s group analysis of the wizard: users split by whether they set a size with the sliders or picked one from the table, with the share reaching each step; user counts are blurred — Figure 08Heap’s report on the A/B test: users grouped by whether they set a size with the sliders or picked one from the table. User counts are blurred; the percentages are Heap’s.

07Next steps

A last step that starts the setup

The tracking plan watched what people did on the wizard’s last page: whether they renamed their server and whether they copied its details. In the redesign that page becomes a place to start from.

A stepper shows six steps done and the seventh, creation, under way: data centre, operating system, size, disk, advanced settings, name and count. Each new server gets a card with its progress, its username and a hidden password, both with copy buttons. A server that failed turns red, with a link to the details.

Below the servers, four cards offer what most servers need next, to set up while they are being built: add a disk, set up a firewall, turn on backups, create a private network. Each has one line on why, a guide and a button. Two lists close the page, one of articles to get started, such as configuring the firewall or protecting the server, and one for troubleshooting, such as SSH problems.

It is one answer to the question from the usability test: the page explains what to do next, where the participant had found no explanation at all.

An earlier version of this page, drawn two ways, was a success message for one server: its username, IP address and password, the last two with copy buttons, and a line saying the same details had also been emailed. Two notices sat under it: one said to check the firewall settings first if SSH would not connect, the other that once the window is closed the console no longer gives access to the login details. The two drawings differ only in the notices, which sit as two cards side by side or as two slim lines, one under the other.

The last step of the create-server wizard, in Persian: seven completed steps, three servers being created with their usernames and hidden passwords, one of them failed, then cards to add a disk, set up a firewall, turn on backups or create a private network, and getting-started and troubleshooting articles — Figure 09The wizard’s last step: each server’s progress and credentials, a failed server with its details, and four next steps with guides.

An earlier version of the create-server wizard’s last step, in Persian: a large check mark and a message that the server was created; a card with the username, the IP address with a copy button and a hidden password marked as copied; a line saying the details were also emailed; two notices side by side, one red and one teal; and a Got it button

The same page with the two notices drawn as two slim lines, a teal one above a red one, between the line about the email and the Got it button

08Console

The server list, the server page and the file manager

The redesign also covered the pages people use once they are customers. The server list opens on a tab for each data centre, in Iran and one in Amsterdam, with a search box scoped to the open data centre, bulk actions, a tag filter and a New server button. Each row shows a server’s status, name and size, its login user, tags and actions; a server still being created shows its progress. Another version of the list adds each server’s IP address and an action to move the server to another data centre.

The list is also the busiest page. Sina ranked the console’s eleven main pages by their Google Analytics views between 1 May 2019 and 14 March 2020, before the redesign: the list drew about 72 of every 100 views and the create page about 10. The wizard begins at the list’s New server button.

The server page, shown at the top of this study, answers one user story, in Sina’s words: “As a user, I want to see my server status and details to check everything is ok, with some operations to use my server.” What it takes to reach the server comes first: its name and whether it is on, the SSH command and the public and private IP addresses with copy buttons, and a guide to Remote Desktop. Beside them sit the plan’s facts and a row of actions: power, delete, settings, rescue, resize, rebuild, console and snapshot. Below, tabs hold settings, network, usage, snapshots, the console, rebuild and events; the usage tab charts CPU and memory over the past hour.

The file manager for object storage lists a bucket’s folders and files with their size, creation date and a switch that makes a file public. Uploads happen in the list itself: a row fills as its file uploads, and a failed upload turns red with a retry button. A breadcrumb at the foot shows the path from the bucket down to the open folder.

All of them share one frame: a rail of Arvan’s products (CDN, IaaS, VoD, Live, Ads and PaaS) and a menu for the product that is open.

The Arvan Cloud console’s server list, in Persian: a tab for each data centre across the top, a search box, bulk actions and a New server button, then rows of servers with status, name, size, user, tags and actions, two of them still being created — Figure 11The server list: a tab per data centre, search, bulk actions and tags, and two servers still being created.

An earlier version of the Arvan Cloud console’s server list, in Persian: a tab for each data centre across the top with the open one raised, a search box, bulk actions, a tag filter and a New server button, then rows of servers with a status icon, name and size, user, IP address, tags and actions; a row of round icons, the balance and a bell sit in the top bar — Figure 12An earlier version of the server list. It already has the data-centre tabs, search, bulk actions, a tag filter and the New server button. The later version adds a progress bar for a server still being created and the city under each tab, and moves the headset, calculator and book icons from the top bar into the rail.

The Arvan Cloud console’s object-storage file manager, in Persian: a folder’s files in rows with size, date and a public-link switch, one row uploading at 60%, one failed with a retry button, and upload and new-folder buttons above — Figure 13Object storage: a folder’s files, an upload in progress, a failed upload with a retry button, and a public-link switch on every file.

09Key decisions

Six decisions

Each one is visible in the shots, the file or the data behind them.

01
Choose an analytics tool that records everything
Heap captures every interaction without events being set up first, so a new question about the wizard can be answered from behaviour already recorded, by people outside design and analytics too.
Trade-off
A second tool beside Google Analytics means two sets of numbers that won’t always agree.
02
Measure every step before redesigning one
The funnel and the effort analysis put the problem in one place, the size step, instead of spreading the blame across the whole wizard.
Trade-off
Events had to be tracked across the site and the console before any answer came back.
03
Keep ready-made sizes, with a choice already made
The table groups sizes by scale, shows each one’s resources and monthly price, and starts with a row selected, so a buyer who doesn’t know what to pick can still go on.

10My role

Sina’s part

Listed from Sina’s published shots, the research pages of the Figma file, the frames there that carry Sina’s name and two earlier page designs that Sina supplied. Another designer worked on the console with Sina; that designer’s screens are not shown.

Owned

The research on the buying flow: a moderated usability test, surveys and social-media messages
The requirements for an analytics tool and the case for Heap
A tracking plan for every wizard step, and the funnel and effort analyses
Both designs of the size step, and the A/B test of them
The wizard’s last step, the server list, the server page and the object-storage file manager

Co-owned

Collaborated

Another designer, on other screens of the console
Arvan’s engineering teams, on how the servers perform
Arvan’s product teams, on turning the findings into the console

These designs shipped in Arvan’s console. Other screens in the file that carry the other designer’s name, or no name, are left out.

11Outcomes

What the work produced

The designs shipped, but the evidence holds no business result: no satisfaction or revenue figure, and in the A/B test completion stayed at about 52% whichever control people used.

analytics tools compared: 5; Google Analytics, Mixpanel, Amplitude, FullStory and Heap; Delivered output
wizard steps measured: 7; Each with its conversion, interactions, time engaged and revisit rate; Delivered output
designs of the size step: 2; Ready-made sizes in a table, and custom sliders with a live price; both A/B-tested and shipped; Delivered output
console pages redesigned: 4; The wizard’s last step, the server list, the server page and the file manager, all shipped; Delivered output

What was delivered

A usability test of the buying flow, its findings filed by kind
A requirements document and the case for Heap
A tracking plan, and a funnel and effort analysis of the create-server wizard

12What I learned

What I’d change

01
Judge a change at the end of the funnel
The slider group reached the size step every time, because the sliders only exist on that step. The number that could show a difference was the share who finished, and it was the same for both groups. That is the number I’d report first.
02
Report the groups the test made
The A/B test split buyers at random, but the report grouped them by the control they touched, which mixes the design with the people who choose it. Completion in each random half is the number that shows whether the sliders keep more buyers.
03
Record every session as fully as the first
The test board documents one participant in full, and its timing sheet has room for five. Filling in all five would have shown which problems are common and which belong to one developer.
04
Put words on the actions that can’t be undone
The server page lines up eight actions as icons, delete and power among them. A label on those two would cost little room and could save a costly slip.

Language

Cloud platform redesign & information architecture

A console that has to sell servers too

Two places where buyers were lost

Choosing the analytics tool

Measured by user-flow conversion

How the work ran

Two ways to choose a size

What the A/B test showed

A last step that starts the setup

The server list, the server page and the file manager

Six decisions

Choose an analytics tool that records everything

Measure every step before redesigning one

Keep ready-made sizes, with a choice already made

Sina’s part

Owned

Co-owned

Collaborated

What the work produced

What was delivered

What I’d change

Judge a change at the end of the funnel

Report the groups the test made

Record every session as fully as the first

Put words on the actions that can’t be undone

Let buyers set cores, memory and disk themselves

End the wizard with what to do next

Explain an evaluation licence before the server depends on it