top of page
Internet of Things: Pattern Library

Marco Polo

Marco Polo is a (currently fictional) Internet of Things system that tracks and builds an personalized network inventory of smart devices for you. For this project, I designed the system's pattern library cataloguing the UI, SUI, and VUI elements in detail with wireframe visuals, text definitions, ems sizing guides, best practices, variation states, scripts, and animations (where applicable). 

View the live Marco Polo Pattern Library here.

Key Features /

Pattern Library

Internet of Things


User Interface

Spatial UI

Voice UI


Building the Ecosystem

Internet of Things (IoT) systems connect physical objects to each other, sharing information within itself and with other networks through the internet. With sensors, these physical objects are able to process live data and send it to a program that manages the information. The concept is parallel to how the body's nervous system works to sense information; an IoT system consists of a brain, sensors, and data. 

Designing the UX for an IoT system requires thinking beyond screen-based visual interactions. The experience of the system as a whole means considering the user's every interaction with its devices. With the idea of personal convenience in mind, I wanted to design a system that did the thinking and remembering for the user. If you can relate to those small moments of panic as you scrambled to locate your phone or wallet, then you would find this system useful. No more accidentally misplacing your belongings, because Marco Polo would know exactly where it was. 

IoT MarcoPolo Ecosystem

Acting without thought is an inherent human function (thanks, motor autopilot). We're only able to handle about 7 things in our working memory at a time, and we somehow expect our bodies to keep up. Marco Polo was designed with the intention to enhance experience by bridging that gap between human action and attention. 

Marco Polo - Ecosystem - HiFi

 How might the user experience the system?

 How might the system interact with the user?

Interaction Flows

For the purpose of starting somewhere and narrowing the scope of the system down to its UI elements, I isolated the 3 primary interaction flows to develop further.




Smart Object Overview

The user sets up the Marco Polo system by syncing their Smart Objects & Containers to their account. The overview displays each Smart Object's location, battery level, history of interactions & past locations. They can also purchase additional Smart Tags & Sensors for their non-smart objects. Expansions are also purchased through this store.

Devices: All Smart Objects & Smart Containers

Interfaces: Mobile App, Web, Ecommerce




Tracking Smart Objects

The user can track all their smart objects by accessing their account via mobile or browser. To find one smart object, the user can ask any smart object with the mobile app (VUI). Alternatively, the user can use a non-visual interface smart object to call for a response from the lost object.

Devices: All Smart Objects & Smart Containers

Interfaces: Mobile App, Web, Voice UI, Augmented Reality




Smart Container Inventory Check

The user can do a quick manual inventory check within most smart containers by gesturing with their hand down in front of a sensor for a 3D projected model of the Smart Container & all Smart Objects located within the container. Augmented reality (AR) arrows can also assist in directing the user to the precise location of the object, even if it is physically obstructed by other things.

Devices: All Smart Objects & Smart Containers

Interfaces: Mobile App, Web, Voice UI, Augmented Reality



Using the interaction flows, I mocked up some wireframes of the key screens to help me find visual patterns in the UI. From a retrospective perspective it was actually backwards of me to create full screens first, but it took me some time to understand the process of designing a pattern library. Starting from an initial template view gave me a bigger picture to easily see the repetition of what I could eventually identified as elements. 


Pattern libraries are subscribed to the idea of atomic design, which is the concept of designing from a system of components (in this case, UI elements). This methodology makes the most sense when considering responsive design and the fact that designers spend a lot of time and effort creating for different devices and screens. A successful pattern library ensures a consistent design system (regardless of the individual designers) and efficient growth as the system expands. 

Click the image below to view a sample of Marco Polo's pattern library. 

Real pattern libraries are typically much larger and contain more technical depth. For a first pass, I did my best to identify essentials and write as in as much detail as I could imagine, but I'm sure my work and design could benefit from some real world application.



Thanks for reading! I had a few more thoughts;

When I was brainstorming ideas for an IoT, I initially considered expanding Marco Polo to include tracking more than just the physical devices. There was something just so simple about using a system that connects objects manage and track those objects. It sounded unoriginal, as if IoT systems should already be able to locate its devices as a default feature. Early in the process, I had Marco Polo tracking moods and experiences as well. It would be able to find you more than just your keys, it'd also find you that last time you had a great burger or even replicate the last time you had a really good day. Now that was an interesting idea. But the question for me was, how?

As a system that can utilize the knowledge of databases from the internet, an IoT system is a higher level of intelligence. But does that translate to the kind of intelligence needed to interpret something as subjective as a mood? It's possible for the system to track physical data, such as the location of the meal you had, the time it was consumed, down to the listed ingredients of the burger. It could ask you after you finished the burger whether you liked it. Then you could tell the system you had a good experience, and it would remember this and log the details of your activities.

But wouldn't it ultimately be up to the user to have some introspective awareness? Did you like the burger, Y/N? Maybe that's a simple yes. Why? Was it the taste? Or was it maybe in some way also the company you ate it with? Experiences can be eclectic. Did you have a good day today? I don't think people always know. Or even think about it most days. A system that could track (let alone replicate) experiences would be so dependent on the user's self awareness that its usefulness would be highly inconsistent between individuals. 

To conclude, there was a lot to consider on top of designing how the system would operate so I filed those 'expansions' away for a less time-constrained moment. For those who aren't as conscious of their hands as they are their moods, this iteration of Marco Polo could still save the day.

This is an older project. 
bottom of page