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.
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.