I joined Habanero Consulting Inc. attracted by their approach to creative leadership, employee experience and non-hierarchal teams. Even though they have had a product rolling for many years, I had the privilege to become the first full-time member of the new permanent product team for GO Intranet.
My Role
I performed as a Product Designer and led the development of the product alongside our Product Owner and Technical Lead. As the only permanent designer, I was in charge of the experience from end-to-end, from the UX strategy to the smallest details of the design libraries. For client engagements, I lead other designers.
The Opportunity
GO, an intranet-in-a-box created on Microsoft SharePoint, was already a successful product when I arrived in Fall 2019. However, Microsoft had released the new version of SharePoint called Modern, meaning that we had to move to this new version if we wanted to continue using the platform and have constant support from Microsoft. It didn't make sense for us to keep offering a dawning product to new clients. GO with SharePoint Modern meant a new product and a fresh start.
The "Classic" version of GO was a mature product with years of development and a robust client base. It included many custom features, which was why companies chose us instead of the out-of-the-box experience. Still, in the eyes of a regular customer, the new Modern approach meant we were selling a product with fewer features than before. Our first competitor was ourselves and our existing offering. We had the task of prioritizing the initial set of features for our new product and applying what we had learned from previous engagements.
The Modern environment also changed a lot compared to the Classic version. It added new features and removed some while embracing new patterns and a total commitment to Microsoft Fluent Design System.
The Approach
We weren't starting from scratch. We had the data from GO Classic, and we knew which features were used the most and what users wished to have. The support team was doing a great job taking feedback from our users, and we planned to make the best use of that info.
We kickstarted the development with a Design Sprint aimed to bring all the stakeholders and data together. We had to prioritize and figure out how these priorities fit the new Modern environment. Was Microsoft already solving some of them? Did they leave opportunities for us to fill? Do we have to rethink how to solve validated needs to fit the Modern paradigm?
The most important part of this process was the creation of a principle that directed all of our operations since:
It is not our purpose to compete with Microsoft or create a Frankenstein Monster out of SharePoint. The product team's goal is to be direct and precise with our development. We never planned to reinvent the wheel. It makes more sense when we note that our clients are usually Microsoft shops, and their Intranets will be in the middle of the entire Microsoft 365 ecosystem. We want users to feel familiar with this environment instead of creating an experience that feels alien to the rest of their tools.
The Challenges
Design language
The decision not to modify Modern's look and feel wasn't all based on lack of resources. SharePoint Modern is not as flexible as Classic in terms of customization. Some providers replace the whole front-end with their own to control the entire experience. Others inject their designs into SharePoint, resulting in an uncomfortable mix of design languages. Users don't care about which web part is created by Microsoft and which is done by us, nor do they want to hear why some buttons look radically different from others. They care for a consistent and predictive experience.
We started designing our components used Fluent UI as guidance. However, every time we saw a change of improvement, we took it, providing that it would not create confusion with other out-of-the-box behaviours. The result is a library of custom components that blend perfectly with the rest of the experience.
Thanks to this frictionless mix, we can react faster to Microsoft's new features. Clients don't have to wait for us to create our own versions of a new component because all out-of-the-box web parts work seamlessly with ours.
Reach and flexibility
Because we serve different companies with distinct cultures and priorities, we had to create features to solve the needs that basic SharePoint wasn't cracking, but at the same time be flexible enough to avoid creating custom solutions for each client.
One example of us reaching for those specific needs is the What's Happening web part. It is basically a News web part, but it can be easily customized to support different communication models.
Here is an example of the web part supporting various news sources, such as internal articles, external links, and other tools like Yammer and Teams. We use those extra colour styles to help differentiate the nature of each card.
Here, the web part only supports internal articles but differentiates between central news and regional content.
Both of these examples use different alternatives of a system of labels and tags that we created to support the navigation.
Structure
The information architecture of SharePoint Modern is quite flat, which has noticeable consequences in the experience. We knew from the Classic days that users don't arrive at the Intranet with the same purpose every single time, nor do all teams have the same priorities. We had a primary Job-to-be-done for the Intranet:
The essential Sharepoint backed us in part to satisfy a primary communicational need. However, we knew that the employee experience needed more support than that. We needed to sustain scenarios where the user searches for actionable information. We had to create a pattern to support these scenarios without getting in the middle of that core communicational objective. With the help of some user validation, we constructed this special job:
The proposed solution to solve this job is the Springboard—a place to access tools without abandoning the primary experience. We designed the contents of these tabs to be consumed fast. The bar format was selected to avoid bloating the experience and add the right amount of scent to these tools, which differs from client to client.
We saw other versions of a similar pattern on competitors. However, they offer a single experience for all clients, or the tools are only available for specific roles such as authors. Also, these tools look very pretty with icons only, but doing that is a crime against accessibility and common sense. Even Microsoft released their own SharePoint Bar in the Summer of 2021. Nevertheless, it is just a repack of information found elsewhere, and clients usually ask if it can be removed (also, they don't use labels either.)
The challenge of bringing this new pattern into mobile was also big. We faced the scenarios of competing against the SharePoint Bar (while accessing the Intranet from a mobile browser) or the Teams menu (while accessing the Intranet from the Teams native app).
The Solution
Here's a sample of the current capabilities of GO, including other features that we created for our clients:
The Result
Less than two years after hitting the market and in the middle of the financial uncertainties attached to a global pandemic, GO Modern managed to reach the goal of annual subscriptions, with more on the way, including migrations from the GO Classic version.
Clients have praised how good the product looks and how much we add to the out-of-the-box experience. Some companies were so interested in our Springboard that they asked to have it included in their SharePoint Modern Intranets, even if they were not part of the GO subscription model.
Industry reports such as Clearbox have commented on how flexible we are and how easy it is for a product like ours to be up to date with Microsoft's updates, which makes us a reliable and trusted alternative.