Leader on the Floor
Microsoft retail needed a way to track employee metrics in Microsoft Teams
CSEO Retail needed help creating/placing their "Leader on the Floor" tool seamlessly into the Team's ecosystem. As a member of the Platform team, at Teams, I help 1P, 2P and 3P partners create applications that will exist in Teams. I previously worked at CSEO so I was familiar with their ecosystem.
In short, the tool provides the ability for store leaders to track their employees’ successes and shortcomings as a way to better understand how well their store is doing at a given point in time. It needed to look and behave like any first party Teams’ application should. CSEO came to us with high fidelity mockups and broad ideas but the flows were not fully realized and needed my support in being built out. Scalability at this point was not considered.
Project
Design system, UX, Layout
Year
2020
PM art was provided to establish a loose vision of the tool. The proposed experience required a significant UX and UI pass to align with Teams’ interaction patterns and stylings.
I reviewed the comps they provided, filled gaps, and created end-to-end flows in Figma at varying breakpoints in both the desktop and mobile spaces. I leveraged existing stylings and patterns provided by Teams when possible and created net new patterns when there were gaps in what Teams were capable of providing.
I had meetings with a CSEO designer, dev and PM on a weekly basis. In these meetings, I responded to feedback and handled a number of additional asks by updating designs promptly and pushing back when necessary. I communicated with their stakeholders directly. I worked with the Platform team directly and shared out designs when I had questions around new patterns (specifically complex navigation, complex table sets, complex charts and timeline views).
Screens were created to adhere to CSEO’s requirements, Teams’ design system & Teams’ interaction models
Of course this experience needed to scale at a variety of breakpoints. Similarly, it needed to work in a mobile setting. The content we were provided was dense and made working with the existing Teams system of patterns difficult. The cards and tables in particular weren’t specced out to handle so much information. This was in many ways a blessing in disguise. It forced us at Teams to reevaluate and expand on guidance created around specific patterns previously built.
For instance, consider a table view that needs to accommodate upwards of 30 or more columns. From an accessibility perspective, creating an experience that scrolls both horizontally and vertically isn’t responsible. For this reason, we introduced a “Column configuration” filter system that allowed users to toggle on or off specific columns so content remained readable at shorter breakpoints.
A timeline view both in a card as well as in a full page was created net new with this exercise. These are only a couple examples of how we built on Teams’ existing system of patterns & components.
Below are only a handful of screens created for the mobile experience.
At Teams and Microsoft, we really stress the accessibility component. I worked extensively with our accessibility representative to make sure the tool we were putting into code could be easily used by all. Working with accessibility acts similar to a design constraint. It’s great because it forces us as designers to cut out unnecessary complexity. It also provides me added leverage to push back against proposals from PMs or stakeholders if a potential improvement harms the tool’s integrity regarding accessibility. Once again, below are a handful of accessibility specs created by myself for the devs to work with.
