Embedded Files
Background
Background
Across the org, different parties had different ideas about the role a homepage needed to fill. Internal company politics, unclear audience, and no defined user goals led to a lot of noise about the type of content that needed to land on the homepage.
The info here is a deep dive into the process of creating the Fluent documentation site homepage. Feel free to skip around.
What I did
What I did
Align the asks
Align the asks
Stakeholders put a lot of pressure on the homepage. As the first impression of a well-known design system, it needs to be many things:
Enticing. The site should be so engaging it makes people want to use our system. Even better, it makes them want to come work for us.
Competitive. Fluent's homepage has to stand out from the other big players in design system documentation.
Informative. We want to let people know about everything the system has (or will ever have) to offer.
Principled. Because why not throw our design principles up there?
I gathered the asks before diving into the opinions of the most important stakeholders: system subscribers. After all, if the homepage is not immediately useful to them and their needs, it's likely to be immediately frustrating. No matter how many of the other boxes we checked.
Conduct, gather, and analyse the research
Conduct, gather, and analyse the research
Surveys and moderated interviews indicated that internal design system subscribers were frustrated by many things:
Unclear system status
Lack of a singular source of truth for design system documentation
Inconsistencies across platforms
Externally, users received updates to the open source code libraries, but were confused by the outdated documentation and design assets. Essentially, the system was out of sync.
Communicate findings
Communicate findings
I created a brief that showed how we could refine our list of needs based on user and business goals. Then, I showed how to create that information in a scalable way.
To counter frustrations with a disjointed and out-of-sync system, I focused on flow and how the new design system enables it.
It's easy to move within the system
Fluent facilitates flow across apps in the M365 family
It creates seamless avenues across roles working to build those apps, and
It provides assets for building across the environments and platforms that customers are familiar with
Set the stage for the story
Set the stage for the story
When it came time to begin collaborating with partners to create our first iteration, I created two assets to help communicate the idea. The first was a simple text outline that allowed me to walk through the story in detail.
First thing's first: tell people where they are. Fluent 2 is an entirely new evolution of the design system. It also lives alongside Fluent 1 instead of replacing it, so it's important to give folks context. Introduce Fluent 2 and convey why anyone should care. But understand that people don't come to the homepage to read, so give them an out.
A dedicated What's new in Fluent 2 page details the changes and explains the benefits of upgrading. People can opt into this information if and when they need to without having to scroll past it every time they visit the site.
Next, the page serves up quick links for onboarding to the system for both new users as well as migration info for tenured subscribers. Then, component documentation info for getting in the mud with the design system.
These links are the core, evergreen information that people will always come to the site for. In all iterations of the homepage, they will remain easily accessible. Especially as people familiarize themselves with a new site and new navigation patterns, it's helpful to keep the component links front and center.
In addition to surfacing how the design system product aids in workflow, we also highlight the design system community. The resources section showcases the tools and practices built by Fluent teams that can make the design and development processes easier.
Next, Fluent highlights editorial content that evangelizes the ease and efficacy of the system, while also touting optimizations and improvements. This content is meant to shuffle periodically so that it never feels stale and users can always find a new update or opinion on Fluent.
Lastly, links for getting in touch with the team. Having avenues to affect change gives people a sense of ownership and increases audience engagement, making them feel like we're building something together, for all of us.
The second asset I created was a low-fidelity homepage mock-up. I used this to give an idea of how visual and interaction design could support the homepage story. I shopped this prototype with leadership, stakeholders, and design partners to brainstorm, get approval, and bring the idea to life.
F2-homepack-mock.movTest and tweak
Test and tweak
Testing this proposed content with internal designers and partners led to making some small changes in how the information was organized.
Initially, five platforms were supposed to be available at release. However, we later learned that the first iteration of the Fluent 2 design system would only include three platforms. This allowed us to revisit how we surfaced platform-specific component guidance.
System subscribers had other avenues for discovering Fluent-adjacent plugins and resources. So while the resources were useful, they didn't need such a prominent spot on the homepage.
On the other hand, subscribers had a hard time finding a single spot for news on Fluent. Highlighting news stories earlier on the page was a desirable change.
I incorporated this feedback in future iterations of the homepage design.
The final product was a result of collaboration between content and visual designers across the org. We came together to find artful ways to highlight the homepage content, draw the eye to areas of highest importance, and bring in moments of delight.
F2-homepage-final-proto.movPage updated
Google Sites
Report abuse