It might sound technical and dry, but it was really fun to coordinate with so many different feature crews and service providers to utilize and develop patterns that could accurately represent and communicate data to end users, and in the metro style of early Azure. 
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 a table, or content could bubble up on customizable and rearrangeable live tiles. Live tiles had eight (eight!) sizes with content optimized for each size. 
I organized and created generic content types and their correlating layout rules and guidance, created best case and worst case scenarios for each, created guidance documents for other designers and partners, and consulted with designers and on-boarding partners as new content and tile 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. 
I spent most of my time understanding 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 intrinsic patterns being adjusted (as we learned how intrinsics were used) and I kept an eye on these engineering changes to make sure updates wouldn't break other partner's intrinsic 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.
When I started at Microsoft my design team was just beginning the process of redesigning the Azure Portal. We landed on a 5-pixel based grid. We chose the above sizes for the tiles. "Unlocked blades" and the "Startboard" are made up of tiles. The user can customize the size of the tiles and rearrange the tiles. There's a progressive revelation of detail and information at each size, with many content types having interactivity on the tile, especially at the larger sizes. 
The above is just one Illustrator art-board from a massive file of resources for designers to help them follow patterns for the Azure Portal tiles.
The patterns for tiles became progressively more complicated as more services were added and more partner products came onboard. I developed several ways of classifying tiles to help explain patterns and to help other designers. These are the main classifications to determine which design rules new tiles would follow:
1. "non-thing" such as tiles that functioned essentially as buttons and direct somewhere (like to a dev console) or day 0 setup instructions;
2. "multi-thing" which were lists, tables, data visualizations, rollups, etc.; and
3. "single thing" tiles which might represent the health of a single resource or surface properties of a single resource.
Mulit-thing/collection tiles were the most complicated. Just the options involved in displaying tables of data at various sizes became very complex and we had to make some difficult choices along the way about spacing, wrapping text, rollup numbers, labelling, sizing, notifications, etc.
A lot of my daily work was with the people building Microsoft services in Azure Portal, converting services to the Azure Portal, or outside parties in the process of onboarding and offering their services in the Portal. 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.

& more

Back to Top