Connecting clouds with Console
Product Design for an Interconnection startup
Seriously, where do we even begin?
As enterprises increasingly move their business-critical applications and content to the cloud, they need safer, faster, more reliable access than the public internet can provide.
We were sold on a dream… the internet, but better. It might sound like a line from a Silicon Valley episode — but that’s exactly how it started.
Our small design team (Paul Hatch, Henry Wahyu, Tiffany Apatu) was quickly flung into the technical world of global networking and connectivity. We were asked to “make it all make sense” to non-technical people — to use software to automate and hide complexity.
We are a startup and for a long time, our product strategy existed on sticky notes and whiteboards that, of course, changed on a weekly basis.
We began with no reference points. We were trying to do something that had never been done before and we certainly couldn’t draw on our own experiences or gut-feel. On top of that, we were living in that exciting-frightening world of “people don’t know that they even want or need this yet”.
In the early days, we did have limited access to a small group of potential users. We were able to conduct interviews and test out concepts and prototypes as we sought any kind of validation and direction.
With their guidance and the know-how of some very talented engineers, we began to understand the problem space and technical needs for people building and managing networks.
Our process and the power of prototyping
As a Product Design team, we design in the truest sense: what something does, how it does it and how it looks. We take strategies and high level requirements from Product Management as well as feedback and ideas from customers and then begin to analyse, question and pull things apart.
We have a nice, neat process diagram that shows different phases of research, co-design, UI etc. It’s nothing new and I’m sure you’ve seen many variations on the same theme. Instead of showing that, I thought it more meaningful to share what we actually do most often.
We always want to transform words into pictures as fast as possible. Often we start with rough sketches on paper or whiteboards before quickly moving into some type of electronic prototype: some combination of Sketch, InVision and Principle.
We don’t wait until we have the answers we need, we use prototypes to ask questions.
Most people understand the benefits of testing prototypes with users and customers but think less truly appreciate their tremendous power as a design tool.
Not only does it help us — as designers — to understand and identify pitfalls and opportunities in our concepts, but it helps business and technical stakeholders grasp which questions need to be answered. Sometimes it even stimulates a change in direction.
We get things in front of customers as soon and as often as we can. For some things, that customer involvement has been early and extensive but for most features, it hasn’t been enough.
We’ve learnt many lessons along the way — including some critical direction changes our product may have taken had we had more access to customers early on. Nevertheless, we’ve remain highly responsive and reactive to learn from our customers as exposure increases.
Look what we made!
We’ve been gifted with some great feedback about our software. In an industry that’s been all about the tech, we brought people into focus and began our designs with their wants and needs.
“The way you made it… interconnection is not an application, it’s an experience.” someone @ LinkedIn
Since day one, we’ve wanted our UI to be beautiful, friendly, simple and a little bit fun. We care deeply about typography and agonize over color palettes. We put effort into the edge cases, empty states and errors and look to microinteractions as an opportunity to surprise and delight.
Some core features
Interconnection typically depends upon two network engineers knowing each other, both being highly technical and equipment in the right data centers. The process of interconnection could take anywhere between hours to weeks. We made it happen in literally seconds.
Obviously there’s a lot of interesting stuff going on under the hood but we’ve hidden this from our users.
Requesting and accepting interconnections features:
- Quick and easy search to find companies
- Clear indication of plan entitlements
- Smart defaults
- Holistic network view to give context and decision-making data
- Ability to contact chat with the other person during the process
- Support for more complex tasks for advanced users
- Ability to handle 20+ exceptions and edge-cases
“The Console application allows one to easily connect without having an in depth technical knowledge, and that is hugely beneficial to us.” someone @ LinkedIn
Monitoring active interconnections
Once the interconnection is established, it didn’t take us long to understand that monitoring becomes super important. We were told by a few users that they simply couldn’t get this level of detail (for an individual connection) anywhere else. It was an immediate differentiator, a way to make Console sticky.
We could see the potential of great monitoring capability to become the feather in Console’s cap. We relentlessly researched and iterated on a graphing and alerting function for both web and mobile apps.
Killer functionality — cloud to cloud connectivity
On a technical level, Console has been able to deliver a world-first in cloud-to-cloud connectivity that allows Enterprises to effortlessly and cost-effectively connect their clouds (such as Amazon Web Services and Microsoft Azure) together.
It’s kind of a big deal.
Building the community
In this very technical landscape, we quickly realised that network and business connectivity was actually built on people. Knowing-someone-who-knows-someone, conferences and meet-ups were all at the core of interconnection success.
We designed a full social platform to support the Console ecosystem as well as allow customers to create their own private communities and networks.
- Full scale search
- Profiles for companies and individuals
- Activity stream
- Event management
- Ability to post, like and socialise content
- Article editor
Messaging and chat
It is very important that people can communicate both on and off the platform. Their reasons might be personal/social but more importantly, they may need to discuss and negotiate their interconnections.
Like most things, it’s surprising how complicated the interaction design gets for the seemingly simple act of sending and receiving messages, particularly when you start addressing group messaging, archiving and controlling visibility of conversations.
Alerts began as a hygiene factor but became an integral product feature.
Alerts must be highly customisable. Users must be able to decide what they want to know, and how. In addition to community-related alerts, our utilization alerts underpin the success of network management.
We investigated at length how other alerting systems worked — not only existing network monitoring tools but anything we could get our hands on like mobile phone data plan monitoring. We also drew on the knowledge of “people-formerly-known-as“ network engineers and systems administrators in our own organisation.
Some — just some — things we learnt
- Prototype ‘til you’re blue in the face!
- Translate with prototyping. When someone keeps talking at you, translate their words it into a functional UI — no matter how rough — on which to learn and build.
- Be tenacious — and very polite — in getting concepts in front of users as early and as often as possible. No brainer.
- Draw on the experience within your organisation… you might be surprised to find out the insights that come from the “previous life” of a colleague.
- Wherever possible, look to other industries and verticals for inspiration. Seek how others have solved similar problems.