Making a scalable Internet of Things Platform

For 2 years I worked on the IBM Internet of Things Platform. The Platform was for enterprise level customers to hook up and monitor their devices.

Date

2016 – 2017

Creation of a Design System

This project explores how myself and another designer spearheaded the effort to take a product that was previously designed and built on a very case-by-case basis, to something that was built under a single, flexible and scalable system that carried the product for over 3 years, but has since been superseded by Carbon X.

The old design

Prior to me joining, there was no system for how to build the UI, no library of components, and no common set of experiences. This was a fantastic opportunity as my first design task as a grad!

Relationships.

The golden opportunity to remedy this came with organisational shifts to the development team. Prior to joining, it's probably fair to say that the designer:developer relationship had always been a bit… shaky. This new team, based in Austin, USA and Brazil provided the opportunity to really make some progress towards making Platform a solid enterprise application.

The relationships I built up over the 2 years with the engineers (especially front-end) I see as being the key for the successes I had on this project.

Project Kratos

Kratos was the project name we gave to the 'dramatic UI overhaul'. It began primarily as a visual exercise. Another designer proposed quite a dramatic shift in style (including a product colour change):

Not my work
Not my work

Although I was a fan of the slightly fresher feel, I wasn't a huge fan of the brown, and the visual balance of the header. I proposed a change that was slightly less dramatic, but still felt like IBM. See below:

Accessibility

There was a huge problem with the original proposal, it wasn't AA accessible. Using the light gray text, and the white text on green didn't satisfy any of the accessibility tests.

As an aside

This project was my first design role out of university, I wasn't familiar at all with accessibility standards... this has now changed, I now consider accessibility from the off!

I quickly pulled together 3 versions that used the next shade of green on the IBM colour palette. I wasn't a fan of these, but they were at least accessible, so started the right discussions.

Prototype to the rescue!

It was literally a week later on from my fights with the IBM colour palette that they released a load of new colours. Without wishing to propose yet another drastic redesign (again, the pragmatic, team approach) I started to propose designs using the new 'aqua' colour swatches.

Below is the beginnings of what turned out to be one of the most powerful design assets I've created, but was the first foray into using aqua, and also an attempt to tidy up the design a bit.

This involved:

  • Removing the excessive layering. This allowed us to have more efficient use of horizontal space.
  • Removing some of the visual noise from the buttons and the different levels navigation.
  • Going back to a collapsible navigation to reclaim some space. Further developments were made to this component to cater for both the beginner user, and the power user.
  • Exploration of a sidebar concept.
  • singe: This prototype was actually making use of the Platform APIs. The devices that you see on the following screens are 'real' registered devices. In the organisational sidebar too, an interaction allows you to change the 'Org ID'.
As an aside

Looking back at this project in 2021, there are so many things I would change and would do differently with the design, including the technology! But at the time, this performed it's function perfectly.

At the time, producing this prototype was the best design artefact I had made at IBM, it gave the momentum to the UI overhaul and has actually really moulded the way I see the role of a designer interacting with development. The prototype single-handedly pushed the general quality of the design forward and made a statement for how our product should feel.

This prototype document came about at the right time to reinvigorate the team and the product, and from a design point of view gave us a really great platform to try out ideas, refine UIs and deliver to development with almost perfect fidelity (in nearly all cases). It was received extremely well by the wider team:

What we learned

Up until now, everything the design team had delivered hadn't been tested in code. With this prototype, I instrigated a new style of working (when possible).

Sketch > Browser > Sketch > Browser > Sketch …

From a visual standpoint, many of these static UI components and design decisions (such as size and space) were made in parallel with a coded browser prototype. Within the direct team we had no FED (Front-end Development) resource, however when I joined with basic coding knowledge I was able to take on some of that responsibility. This has enabled us to have a far more refined visual style than was was previously created for the old UI.

Standardisation:

Introducing Common Components: UX + Visual + Dev

The combination of an improved design process, a realisation of an uber productive relationship with one of my colleagues, and great relationships with the UI developers, meant we were in a strong position to start making some real changes to the UI.

At the same time, as with any enterprise level projects, requests for new functionality and experiences were also coming in thick and fast. We needed to build a system to help with this scale.

Sketch Library

As mentioned previously, the old Platform didn't really utilise any uniform design or development system. One of the things we identified early on was a desire to fix this. Working closely with other designers and UI Devs, we started to produce a library of components in Sketch Libraries, React and a library of experiences for how, when and where each 'component' should be used. This meant a drastic overhaul to the product to component'ise' and match the designed experiences.

As an aside

We were actually the first product to start using React storybooks to document our system.

The library file I built contains each variation of what we called 'primitives', the component pieces that fit together to create the product.
The library file I built contains each variation of what we called 'primitives', the component pieces that fit together to create the product.

Each component was built to the same set of standards. They all fitted to a 0.5rem grid. They all conform to a standard naming convention (that allows me to really make use of plugins such as 'Sketch Runner'). They'd also been made in such a way that make them hard to use incorrectly. For example, locking certain layers prevents overrides, and allows text overrides only through the 'Button Relabeler' plugin to keep spacing correct (I'm investigating the suitability of Paddy to replace this functionality).

As an aside

This was in 2015, a lot of these features are no standard in design software, unfortunately at the time they weren't so I had to work out my own best practices!

Two of the areas that this transition to a centralised, well thought through design system enabled me to do, were tables and modals.

The old table

90% of the IoT Platform is tabular data as this is the best way to present the information. Therefore we realised early on that we need to create a table component that allowed the flexibility we required.

The problem with the old table was that it wasn't particularly flexible and a lot of the interactions were quite 'heavy'. The spacing was off and seemed broken due to the pagination row (which appeared every 10 rows!). In short the implementation lacked polish and was in need of a major refresh!

Old

TO DO: MAKE A PROP

New

TO DO: MAKE A PROP

The new design introduced extremely tightly controlled spacing and typography, which was one of the main problems visually with the previous table. The pagination row now feels part of the table without breaking the flow, the pagination remained sticky, and for any subsequent pagination rows to replace it by pushing it out (similar to iOS).

Infinite Scrolling (with Skeleton Loading)

We introduced infinite scrolling to the platform. I'm not sure I would do this now, given how it's a bit of an anti-pattern these days, and the amount of IoT devices we were expecting users to have, pagination might have been more suitable.

Nesting

Nested capabilities are built in, which was really useful for information management. The spacing here was crucial to manage and deliver in the correct way to development. With these nested components, spacing can very quickly get out of hand.

Using sticky headers, to make a more functional table with a less disruptive 'informational' row.

Filtering

Old

TO DO: MAKE A PROP

New

TO DO: MAKE A PROP

The search in the original UI works by 'adding filters' to the table which then appear as a list. It's a very sluggish method of searching the data and is very inefficient in terms of UX and Visual.

This new method does exactly the same thing, only the updated design introduces the search ability in a much more fluid way and allows the user to interact with the data directly rather than passively, which leads to a much nicer experience. Note: this is the first developed iteration and the first time we’ve been able to play with it. There are a few UX tweaks I would like to make.

Modals

Modals were one of the biggest problems with the previous iteration of the product. The actual point in time the original IoT Platform UI decided to present a modal was way too early, and we quickly decided that we thought modals should be the final step in a 'flow', e.g. modals should be a last resort.

They were also very dominating, taking up 100% of the screen and having some strange navigation paradigms meaning users were unable to find progress/actionable buttons. See example below:

This is currently the standard 'go-to' modal that the platform uses. A fullscreen approach that has a strange and unclear navigation.
This is currently the standard 'go-to' modal that the platform uses. A fullscreen approach that has a strange and unclear navigation.

Unfortunately I did not record an example, but clicking 'Create Device Type' added another of these modals on top of this one. Hiding the context, two times over! Things get even more broken when you get even the most basic of validation errors, resulting in 3✕ stacked modals without much effort at all. Each of these had a different visual style and UX treatment.

Multiple modal types, all using the same system

In order to remedy the multiple styles of modal, I set out to create a flexible system, in order to have one template to handle every modal in the Platform. Designing this hand-in-hand with the UI developers in React made this whole process a dream, and we ended up with an extremely flexible system/archetype that was used extensively throughout the product and was extremely well received by users.

Reducing complexity with interactions

Introducing Inline Modals

My personal opinion is that modals were often a lazy way out of a problem in the original platform. I proposed n alternative system of 'inline modals'. They sit 'hidden' beneath table rows, allowing users to quickly preview data; this had the benefit of not disorientating the user in a 'flow' and also allowed us to use 'pop-over' modals only as a last resort, preventing modal-on-modal scenarios.

Using an interaction, inline modals allowed us an extra level before we default to hiding content and removing the user from their previous context. We used these with the caveat that any data displayed in these should be relatively simple so as not to cram too much information into a small panel. We also only allow one to be open at a time.

An unexpected luxury: Inline on Inline

There were cases with information management (below) that had many levels of complexity, and each of these complex inline modals could be configured from multiple different places. I realised that with careful styling and tightly controlled spacing, these inline modals could theoretically be extended an infinite number of times without losing any horizontal screen estate (an issue with the standard popover modal), in practice, however, we limited this to one for the short term.

… and then popovers (as a last resort)

In the above example we are 3 levels deep, however, due to the new designs and the new systems, the product is able to hold itself together.

  • Level 1: Inline Modal
  • Level 2: Inline-on-inline Modal
  • Level 3: Popover Modal

Platform of old would have had 2/3 overlaid fullscreen modals, each of which removed the context, and then an additional smaller 'dialogue' on top of that.

A flexible system = consistency

Using the above system, all of our inline modals were utilising the same visual and UX system and were implemented using the same code. This extended to popover modals, the only difference being that we also added a slightly transparent background overlay to make the modal content more prominent (whilst still keeping the below content visible). Below are 4 examples of these new consistent modals/dialogues.