Led design that replaced phone calls and spreadsheets for entire countries and municipalities


New backend management system for entire governmental bodies and countries to monitor their Motorola assets and software.


Design was sold for one breakpoint. UI assets were based on an outdated marketing site, which don’t have the same components as a backend system.


Held brand experience workshop with creative director to align on core values and experience of this system. Created a modular visual system to scale based on brand experience. Annotated system theory for development and future designers. Annotations were generated at the end of the engagement to ensure groundwork and rules were stress tested. 

Lessons Learned

The brand experience influenced the architecture of the web app. The brand experience gives reasons for each design decision and cuts out the fluff. 


Brand Experience Synthesis

128 Comps

Annotated Visual System

Fun Fact

My designs and other wireframes were stolen by a freelance designer who currently uses them in his portfolio.

Brand experience workshop

Key stakeholders were asked to flag dots on few hundred hanging images, indicating whether or not the image displayed a factor of how users should feel when interacting with the end product. 

Once dots were placed, images were placed on a spectrum from a positive to a negative experience. 

Stakeholders were asked to explain their reasons for a green or red dot. They were reminded to comment on what the product should feel like, not what it should look like.



Boiled down stakeholders comments on images into key words with supporting text. 

Defined a spectrum of different feelings where the brand experience can exist.

Defined what the brand experience should not be.

Style Studies

Expanded brand in style studies using the key words as a spectrum of feelings. The style studies used all attributes, but differ by accenting some words over others. 

This effects not only the visual style, iconography and color, but also the architecture of flows, framework, and copy.

App Map

100+ screens were eventually identified and more comps were made to show interactive elements.


Most of the 100+ screens were filled with expandable tables and heavily manipulatable graphs. Detail pages like this usually had a parent on a higher level dashboard that would give a summation on the material here.

Navigation was the last piece of the puzzle so most pages do not show it. This was by design so that we did not have to change navigation information every sprint until we knew of every piece on it.


Panels were used for multi-step processes initiated from an expandable table row. 

Modals were only used for zero or one step actions, while panels proved to be a better metaphor for a full process. Panels were used instead of full pages because wanted the user to still have a sense of where they came from.


The dashboard was populated only by information that could be summarized and information that could be acted upon. This was one of the clear ties to the brand experience workshop influencing the architecture of the app.

The dashboard was also one of the last pieces to design because we wanted to know exactly what was on each detail page first, before making a summation of information.


After most of the screens were finished, we explored the framework and how different elements scroll throughout the app. 

I put together many comps like this showing the developers how navigation scrolls separately from the rest of the app, how certain items are fixed and gain and lose their z-index’s to show overlapping content, and how things expand and contract.

These rules were also noted in the annotated visual system.

Annotated Visual System

There is a reason and place for everything in Motorola’s web app modular visual system. 

Tables, graphs, cards, dashboard items, alerts, headers, modals, panels and other components all have rules tied back to their business requirements, wireframes and overarching brand values. 

There should always be a place for a designer to write these rules and update them when the use case presents itself.