I spent much of my time in Azure utilizing very limited pixels for a huge variety of needs. It might sound technical and dry, but it was really satisfying to coordinate with so many different feature crews and service providers to develop dashboard tile patterns and guidelines that could best fulfill the needs of everyone, including accurately (and aesthetically) representing data and notifications to end users, all within the guidelines of the metro style of early Azure, at Microsoft 2012-15.
Microsoft Azure Portal content was surfaced to users primarily through pages called "blades" that opened horizontally (creating a natural breadcrumb). Content on blades could either be locked (such as form fields or tables) or content could bubble up on customizable and rearrangeable 'live' tiles (interactive tiles). Live tiles had eight (eight!) sizes that users could switch between to customize their dashboards, with content optimized for each size. The visual pattern and interaction guidance needed was extensive, to say the least.
I organized generic content categories for the tile types and spec'd layout rules and guidance for each category (via meeting with a myriad of users internal and external). I explored best case and worst case scenarios for each tile type to avoid blind spots. I created guidance documentation for distribution to other Azure designers and Azure's onboarding partner services, served as a point of contact for all questions about the portal tiles, and continued to adjust and coordinate with all involved as new content and needs emerged.
For instance, general intrinsic (intrinsic: supplied by Azure for partner use) tile types fall into three categories: single item, multi-item, and non-item. I created a visual tree of these types of content and their layouts at different sizes, which you can see a few images down.
Much of my later time on the Azure team was spent understanding onboarding service partner's scenarios to advise them on pattern use/correct implementation and to identify situations that needed new patterns. Often, partner's scenarios would lead to portal-wide pattern adjustments (as we learned how intrinsics were used in the wild) and I kept an eye on engineering changes to make sure updates wouldn't break other partner's tile use. This also included policing when an intrinsic could be adjusted and when a partner had a unique enough need that they would have to develop a custom solution themselves.
A lot of my daily work was with the people building Microsoft services in Azure Portal, converting existing services to the Azure Portal, or third-parties in the process of onboarding. I would get tile ideas like what you see below on the left (this is by far one of the least complicated) and I would work with them to understand what their data was showing so we could appropriately represent it with the patterns established for Azure. Often this would uncover issues with how a service was already representing their data and it was wonderful helping them to rethink what their users were trying to get out of the service.
Sometimes the work was seeing problems with our patterns and being proactive about solutions. For some services, and for some users, charts were often empty even though they were working. These are explorations for showing a user that data is being pulled, but the values are zero through subtle tic marks, highlights, etc.
Below was another pattern fix. Permissions caused problems with shared dashboards and everyone was using their own style to show that a user didn't have permissions to the data under a tile. Below is just one of my mockups.
Another pattern problem I discovered while "pattern policing" was our misuse and overuse of ellipses. We changed some of the worst offenders, thankfully, to more appropriate options.