lineup

case studyJune 01, 2019

The Challenge

At Coolfire I worked with another strategic partner to design a platform that makes managing IoT devices and Persons of Interest a breeze. For context, IoT devices refers to internet enabled cameras and sensors. Persons of Interest (POI) could refer to suspicous folks or VIPs - depending on the context of the products.

The Approach

I worked to understand the users, their needs and current solutions. The client had sensitive engagements so I wasn't able to meet with the end users directly - so information was piped through management. This actually made it easier to abstract user needs into broader product concepts and fatures. My goal was to simplify the mess of data surrounding POIs and make it easy to access a feed of information from IoT devices.

The Deliverables

Two major experiences surfaced. The first was a web-based dashboard for viewing high-level activity, organizing people, and adding / removing users, persons, devices, etc. The second was a mobile app for field agents.

cover

Activity Feed

Major paint points were the activity feed(s) and person detail pages. Conceptually the feed was going to be the "single source of truth" for what's happening with your people / sensors. The sheer volume and variety of information coming in made it very hard to distil what was most important. Ultimately I landed on feed types within a "dashboard" - highlighting latest activity in buckets with an affordance to dig deeper and see additional entries.

activity

The mental model was "here's people to keep an eye out for", then "here's some sensors that have seen things", then "here's people who have done things", followed by "activity from social media". The sort order comes from ability to respond. High alert POI are actively sought out by field agents at events. Sensors would ping the agents when they spotted someone, prompting immediate action. People and social activity is less immediate - it could be something like getting a nastygram from a fan, or posting an angry tweet.

activity details

POI Details

POI Details were hard as there was a brutal amount of information to display, because you just NEVER knew what the users would want to record about a person, and all fields had their own CRUD process. I tried to bucket the types of data about a person into larger groups - things like appearance, contact, location, connections, media, etc. The goal being to quickly scroll to that section to enter that type of data. POIs needed to have their own mini activity feed as well.

person of interest

Cameras and Sensors

Cameras and sensors needed to be seen as a list for easy sorting and on a map for geospatial context. The MVP only focused on seeing cameras on a map - but future state would enalbe live-streaming from a device as well as onboard monitoring for CPU usage, memory, temperature, etc.

camera details

Map View

The map view is one of the more robust parts of the app. It lets users scroll around to view literally everything - activity events, camera matches, sensors, other users, and more. I created an expanded color palette and icon set for map pins - making it easier to distinguish one event from another. I also provided an easy map layers action to sift through the data on screen. Combined with search and card layouts for pin details, the interaction went from complex and overwhelming to easy and efficient.

map details

Subscriptions

This app had a unique business opporunity based around sharing data between accounts. High level - you have a list of people and cameras in your network, I have a list of cameras and people in mine. What if we opted to share parts of our data or access to our sensors? I fleshed out this theoretical model by mocking out a store where users can opt to share their cameras, or share their people (or groups of people). The goal being to make everyone's job of "find bad people" easier.

Privacy and protection of data was top of mind, so I made sure to emphasize this as an OPT-IN feature only, and did some extra work on verbiage and illustrations to communicate these concepts to skeptical, non-digital natives.

subscriptions

Onboarding and Messaging

The application grew over many months, often shifting focus with each iteration as requirements were refined and feedback obtained. I finally decided to mock out an onboarding flow to highlight what this app does well. This was done for the benefit of the users, management, and the development team. With the app you can add a person, create a list, and add a camera. As easy as 1, 2, 3.

Another mobile-only feature was messaging, which handled person to person communication as well as grouped conversations. Messaging in the app was intended to be helpful, with links to POI pages or events / activity details inline. Like Slack, if you typed a person it would inject a link to their profile. Or referencing an activity would create a hot link to it.

messaging

Navigation

The app became a Swiss Army knife of features. To make it easier to find the right information at the right time I broke it down to activity (what's happening now), a map (where are things happening), messaging (who's talking about what's happening), then search and more.

More opens a popover of sub navigation to the general buckets of people, sensors, users, data, account and app settings. A fairly straight forward to organizing the hierarchy of needs.

Search wound up being a Pandora's box of possibilities. Going back to the users I broke the search needs down to activities, people, and sensors - to help search be performant. Leadership also toyed with this idea of live scanning to search. The theory was a security guard might have a crowd of peope in front of him - they could take out their phone and do a quick scan of faces. Any hits would pop up and link to the appropriate profiles.

searching

The Results

This project was an ongoing effort for about 11 months. It was a strong first attempt at building a dashboard and mobile app for the client - helping them drive business through technology on top of their existing security services. I learned from some mistakes in the initial designs, having too much information with limited action items. By simplifying the dashboard I was able to create a cohesive mobile and tablet experience.

The client provided the name, but I worked on the logo which was later registered and trademarked. Coolfire also presented multiple variations of this software for new service lines including managing VIPs and handling corporate security.

In the end I established a flexible product that can adapt to new use-cases with relative stability to the user experience. I also created a strong design system for scaling the applications and transitioning between desktop and mobile. This was able to be passed on to future designers for continued iteration and expansion.