Information management

Possibly the largest single piece of work I completed for IBM, Information Management was an effort by myself and one other designer to create a way for users to change how their device data communicates.

Design team

Myself and one other designer




This Information Management work was originally completed in around 2015, I performed a visual refresh early in 2016 in line with the UI overhaul, but later in the year we had the chance to revisit it.

So, what is IM?

Information Management was providing a solution for one of the main issues with IoT at the time: There is yet to be a defined standard for devices sending data, and no agreed and standardised format that they should send data in. Dealing with all of these unique delivery methods had previously been tricky for our users, and given that the IoT Platform was designed to be completely platform agnostic, this was a very well loved feature.

This is the original:

What we learned
However, From this original, we received loads of feedback that interfaces weren't explained in enough detail, and only users who were familiar with the APIs were able to use these correctly.

Months passed with this being the delivered solution as we couldn't find the time to fix the issue, however I saw the opportunity when there was a big push to improve the developer experience, to revisit these steps for personas such as Devon (the Device Developer).

Below are the hi-fis I produced as a pitch to show how we could tweak the flow to separate and explain physical and application interfaces and provide a more simple creation experience.

The new designs visually distinguished the previous concepts as separate and allowed more explanation for each interface type.

But what are interfaces

The concept of interfaces is to act as a layer of logic after devices send their data to the Platform. This comes in 2 parts:

  1. Physical Interfaces
  2. Application Interfaces

Physical interfaces handle the ingestion of data into the Platform. Think of these as a schema, but with added functionality to enable rules and alerts.

Application Interfaces are a layer after the Physical Interfaces and take this new standardised data and repurpose it for multiple 'Applications'. API calls to the Platform can then make use of this data. (Note. These used to be called logical interfaces, some screenshots may be wrong)

Because both of these interfaces exist in a Device Type, it makes the usage of Device Types way more flexible, and actually brings them inline to how they were initially intended. Consider this use-case: You buy an internet connected thermometer from Brand X (which outputs Fahrenheit) and another from Brand Y (which outputs Celsius). These would previously have to be registered to the product under Device Type: Thermometer X and Device Type: Thermometer Y. With interfaces, now both sensors can be registered under the one Device Type: Thermometer, so no matter what brand of device you buy, the Platform possesses the capability to standardise the data.

The scale

To give an idea of the scale of this project, I produced 340 hi-fidelity artboards.

What we learned

This taught me a lot how to really use Sketch. It was also the first test run for the design system (above), and helped inform the creation of the symbols (which eventually got remade once Sketch Libraries came into existence).

It also taught me (admitedly early on in my career) a valuable lesson in clickable prototypes, and how keeping them simple is better for everyone involved!

Adding to the Application Interface

When an interface is created there is the option to add capabilities. For example, adding a state model allows the mapping between the incoming physical interface properties and the properties to be outputted in the application interface. The initial UX provided by the other designer was as follows:

There were lots of issues here. The options in their initial form disappear once you've selected them, but then reappear in a different form below the other options. The way the 'outputs' were presented was also not thought through.

Below are the mid-fis that I created to build upon the work done above. They required a new component, however, this new piece allowed the 'Adding' and 'Viewing' of the different models to happen under the same place, making for a more consistent and understandable UI.

Mapping state

Unfortunately the ability to map and change properties had to be removed before release due to priority. When V2 came around we were asked to provide designs for this piece, below is the flow I produced that removed the table'esque' experience we designed before to enable this new functionality.

Adding support for arrays and objects made things exponentially more complex. This was given to me as a purely hifi task. Adding Objects and arrays effectively meant I needed to add a level of nesting up to 8 levels deep. Eek. I worked closely with the developers to ensure tightly controlled spacing, and added a few interactions to aid the user in knowing what level they would be adding to. (Unfortunately I have since lost the video I had demoing this)

Adding an instance of the Thing

A "Thing" is a concept we introduced to compile multiple devices into one 'larger' device. Consider 'a room' a thing, and that room can have up to 10 chairs (each of these a device), could have an unlimited number of lights (another device) and a motion sensor (another device).

Below is the original wire the other designer created and the hi-fis I produced. I made the hi-fis align more with the mental model of Things (that an instance of a 'Thing' was simply taking the composition and filling in each 'bucket' with the required number of devices. I therefore wanted the Thing Instance creation to feel like you're filling in the buckets).

The core idea was here, but I felt a table wasn't the best representation of this data/interaction
The core idea was here, but I felt a table wasn't the best representation of this data/interaction

These is the full set of 'bucket' types that can be filled out.
These is the full set of 'bucket' types that can be filled out.



Working directly with the architect to allow for notification preferences to be set:

  • On state change: Notifications are only sent if the state actually changes as a result of processing an inbound event. So, for example, if a temperature device is constantly reporting the same temperature, the state will not change and, therefore, no notifications are sent.

  • On every event: Notifications are sent every time the platform processes an event for that device, even if it does not result in a change to the state.

  • Never: Notifications are not sent. In order to retrieve the state of a device you must use the REST API.


Whilst I would never profess to be an illustrator, as the formal 'visual' designer on the team, any required illustrations fell to me, below are some of the ones I produced for this project.