Organizational Developement through
Team Building
Roles
Senior UX Researcher
Volunteered to create workshops for our team
Tools & Methods
Workshops
InVision Freehand
Google Slides
Substrate is all of the data inside Office 365. That includes files, actions, and information on entities. The data is user centered and stored on the individual, tenant, or organization. It enables services, like search, to run across different applications like Outlook, SharePoint, Teams, and more.
The process that developers went through to use the Substrate data to build apps and services was complex because of Microsoft’s high value on compliance and privacy. The complexity also came from many teams working on the Substrate without interacting with each other. Our team was brought it to helping people understand Substrate and make it easier to use for all Microsoft employees.
Our Team
Our team consisted of 2 full time designers, and 6 vendors (4 designer and 2 researchers). From left to right – Eddie Mays lead the group, focusing on budgets, managing, and helping our work get recognized by leadership. Jon McClay was focusing on the Project Builder, a fast way for developers to get their prototypes onto Substrate in 1 day.
Kobee who was in charge of the data explorer, a way for developers and eventually other personas to see the data available in the Substrate. Saumeela focused on monitoring which happened at the end of the user journey after the app was made. Paul owned the visual library and created the look and feel for both the product and Substrate Day. I focused on onboarding, information architecture, and helped put together the end to end experience with Eddie and Dan.
Dan lead the research, focusing on gathering insights on the end to end journey. He also ran user testing for Jon’s project and helped me with running cards sorts for the information architecture. Yao worked with Saumeela on monitoring and conducted the research on that side of the product.
I approached this job with the intention of working on this team for a long time. The team was being built before the new fiscal year because design resources were needed by Substrate ASAP. The plan for the contract positions was to turn full time once we had confirmed the need for designers. Unfortunately COVID changed everything right around the time that budgets were getting approved.
This team had never worked with designers before and there were zero design practices in place on the team. The way in which our team worked with this group would affect how they viewed design going forward. I did not want to be a production studio that just created visuals, but I also knew that I had to allow them to gain some easy wins from us to trust us over time.
Sometimes I let go of the “right” approach to take in order to establish rapport. Other times I broke down the problem for them future through mock ups, and helped open up discussions that I knew they had yet to have.
This project was filled with ambiguity. It was hard to get a straight answer from people, because no one knew everything about Substrate. Each team was working in a silo on their piece of the puzzle.
I wasn’t able to rely on all of my usual tools. Stakeholder interviews were being conducted by one of our researchers, and he was finding it difficult to figure out all of the stakeholders because of the complexity of the system.
Instead I had to rely on the partner I was working directly with, Uma, the Principal Content Developer. Her team was in charge of producing all of the documentation around Substrate. She was also in charge of putting together Substrate Day. She had a lot on her plate, so I had to figure out a way to ask her for content in an efficient way.
Then I had to work with what she gave me and restructure it for a user in the best way that I knew without talking to users. Because our primary target was developers, I used my experience from previous teams I had worked on with developers to make my designs. Then I presented them back to Uma and eventually to the entire PM and Engineering team.
Problem:
The first problem I tackled was creating the landing page. In order to do this, I had to understand what Substrate was so that I could explain it to new users.Goal:
The goal was to create a landing page that supports both new and returning users. It needed to be interesting enough and easy to digest to get people to use Substrate. The final page would also need to work for multiple personas – developers, data scientists, PMs, and designers.
I took the pages that were already on the site and some basic wires that Eddie had put together, and started sketching. I worked with Kobee to get some ideas about how the panel for data could be visualized and iterated based on feedback I got from the design team. Then I made my first round of wires to use as a talking point for a bigger design meeting.
I put them up on the screen and asked all of the designers to write down their ideas and feedback onto sticky notes in the meeting, so that we could build the page together. This way we could use what each person had started to understand about Substrate in their own area to build the entrance of the site.
Then I took all of their notes and organized it into categories I could see belonging on the home page. Then I went back to sketching.
When I had another round of sketches done, I presented them to Uma. This as the first time I was introduced to Uma and when I realized that I had access to an extra source of knowledge about Substrate.
Wireframing without content
I was trying to move forward with the project, but I was having a hard time designing the pages because of the lack of content.
I’ve been taught throughout my career to gather content first and then create designs based on the content. In this case Uma was too busy trying to juggle things she had to do for Substrate Day to give me the content beforehand.
In this version of the wireframes, I highlighted all of the missing content in blue, so that the team knew exactly where I was blocked in the design.
Getting the content for these pages was low on Uma’s priorities, so I was blocked. I had to find something else I could help the team with.
Problem:
The navigation on the portal page was inconsistent with the navigation across the site. There was a hidden navigation under an ellipsis at the top of. the page, along with a secondary navigation that unfolded to a tertiary navigation at times. Looking at the email thread, I realized that the navigation was being built by committee on a weekly basis. There was no data or user research used to make decisions about the navigation.Goal:
I wanted to create one owner for the navigation that was less bias than the people creating the different sections of the platform and asking to be in the primary or secondary nav. I wanted the navigation to be back by data and create simplicity and organization to serve the end user.As I clicked through all of the pages in the portal section, I realized that I didn’t understand most of them. Most pages were very technical with very minimal design and lots of spreadsheets or meta data that I didn’t understand the purpose of. I didn’t have access to users at this time, so I decided that I could ask one of our developers for usage data first. Then I could create a hypothetical simplified navigation that I could run by PMs to gather more information about pages that were important to user.
Once I dug into this data, I realized that I would still need to have someone walk me through the pages to make the hypothetical navigation. One of the PMs, Matt, agreed to walked through the pages with me and describe what they were used for and the level of importance.
As I was trying to figure out the navigation system, I found out that Microsoft had a design system that we wanted to use to build all of our new designs. The developer team thus far had not been using any of the Microsoft design systems, so we wanted to introduce them to the new design system – Fluent.
Unfortunately, as I looked into Fluent I realized that it wasn’t going to work for our platform. The Fluent system was built around M365 products such as Word, Powerpoint, and Sharepoint. It required a suite header that included a search bar with a waffle menu to get to other M365 products. This didn’t make sense for an internal developer tool. The design system was new, so I decided to propose a design for the waffle nav that would work across all developer tools.
I presented this in a design review with the Design Director of M365, so he could see the limitations of the current design system. I was told that I needed to explore further, or that I could use another library – M365 admin.
Navigation Audit
I decided to look around Microsoft to see how other teams were using the waffle. Maybe I had missed something and it was worth using this navigation system? After all I was knew to Microsoft and did not know how their design worked across their products.
I put together a navigation audit to see the patterns that teams were using across the company. I saw some consistency with the waffle nav, but the examples either made sense because they were M365 products or had the suite header that their users wouldn’t have used.
Card Sort
At the same time that I was trying to help our team decide on the type of design pattern we were going to use for the navigation, I was conducting card sorts. I had created enough interest from putting together a hypothetical nav to gain some time to do some research.
First I started with our design team to confirm that it was a good use of time to do the card sort. As I expected, everyone categorized the cards differently. Then I did a second card sort with people from our partner team who were building the product. Maybe they had a clear and aligned understanding of how everything was structured? Yet again, there were many ways to categorize the cards.
These card sorts were very valuable to me, because every time we did one I learned more about how Substrate worked.
The last round of card sorts was conducted by our researcher Dan, but I was there to observe and ask question at the end. Unfortunately, we were only able to do 4 with the lack of budget to create incentives for users to participate.
Additional Work
In addition to working on the information architecture of the site, I helped art direct some education videos for Substrate day and put together a visual walk through of the future user journey.
For the visual walk through, I collaborated with Dan, the UX researcher, on our team and a PM, Kerri to create a Power Point deck that would allow people to experience what a developer would once Project Day 1 was launched. It was the first end to end documentation that the Substrate team had to use and would be helpful if they hired more designers in the future when they received budget.
For the videos, I partner with Paul to offer feedback in imagery and consistency between videos. We also gave feedback on the voice over actor and how it related to the tone of Substrate’s brand that we were building. Sometimes we also restructured the script so that the visuals would work better in the video.
Reflection
For me, this project was about letting go of control and being flexible. There were many obstacles that I didn’t see ahead of time. It was a growing experience with a great internal team. I was able to build my patience with partners and let go of knowing many things upfront. This project made me want find projects at larger companies so I can have more of an impact. It also helped highlight my passion for organizational change. I loved the idea of building trust over time that leads to incorporating UX thinking into a team, like this this tech heavy one at Microsoft. I want to spend more time in the future working with people, processes, and systems to help launch holistic products backed by good strategy into the world.
Other Projects
That wraps this project up, but you can check out my other work below. In the Simplifi project, you’ll see my art direction, mentorship, and interaction design skills. In the Retrofit project, you can see same real world testing with users and some great metrics. In the Washington Wine Redesign you can see how I rearchitected a site while having the hurdles on not being able to work with users directly.
