The Tools Catalog is a centralized place for employees to search, view, use and contribute to IP tools that belong to the wider company.
In a tech company that employs ~280,000 people, it can be difficult to track and have jurisdiction over the many projects that get spun up and could potentially be used in repeatable formats, resulting in saved money, consistent security practices, and client competitiveness year over year.
Interested in tech stack, code quality, popularity, architecture
Interested in capabilities, impact on sales proposals, legal aspects
The product team was tasked with creating an application that could sit on top of GitHub (where the tools would actually be stored) and act simultaneously as a place of discovery and a place where users could actively participate in the use and improvement of these tools. Several challenges existed before we even got started:
- A version of this platform had previously been built, and failed, because it was not compelling enough for users to want to use it. Jurisdiction was too strict, and it was easier for them to do things the way they had already been accustomed to.
- A lot of unknowns surrounded what the tools would entail (quantity, how they were used, ways to categorize them, etc.).
- There was no time for generative research, so the team had to get started with decision making based on assumptions.
We began with some group meetings to learn about the problem space, user types and challenges, and ideate solutions around how to solve the problems at hand. We put some rough ideas together on what various user types would be interested to get out of this application, as well as a list of features worth considering.
From there, I was able to kick off some big concepts for the long vision of what the product could be.
Inspirations for product types with great discoverability go far and wide.
- Streaming services: Horizontal scrolling sections based on categories
- Social media: A feed that might serve content based on user activity
- App store: Image blocks that could be curated by the tools management team
Having a long-term vision is a great way to kick a project off and get creative ideas flowing, but near-term goals are also a practical necessity. The product team collectively went back to the initial list of features and prioritized the most important ones in order to help us deliver a usable application quickly.
The initial concept was to have a landing page and a separate page that would be for search results.
For Phase 0, we decided to skip the landing page and have the search results page become the landing. This allowed the user to have a minimal set of clicks to get to results, and saved the tools management team any labor on having to curate what should belong on the first view. Basic filters and a search function made it into the first version of this search-as-landing concept.
The tool detail page started as a very basic single column where details about the selected tool would live, in addition to a smaller column where metadata, such as tags and contributors, could belong.
One discovery that came about early on is that many of these tools would have multiple repositories attached to them. This served as both a challenge and an opportunity, because one comment from the development team is that GitHub has a big weakness in that it does not have a UI to show related repositories. There are org-level organized repos, but not project-level repos. By showing related repos in one view, the Tools application has an advantage for users.
Secondarily, because community building is an important driver of this product, we needed to find a way for users to have project-level conversations. Yammer is already a widely used product with the larger company, so it was decided the path of least resistance (both technically and user behavior-wise) would be to embed Yammer discussions into each project. An added advantage was that the tools could have more visibility if there is cross linking at various entry points.
With these two feature sets added, it was clear that the single-column layout may not be the best format for the tools detail page in case important details got lost in a long scroll. Tabs were born.
IMPROVED SEARCH LAYOUT
When the initial search-as-landing page was developed, the whole page scrolled as one which had some detractors from a usability standpoint. Filters got hidden for one, and the search field quickly lost visibility. The first version also had a large splash banner to provide some context for the first time user, but didn’t offer much value beyond that.
A simple solution for the banner was to make it dismissible.
After wrestling with various locations, it was decided the search bar should move to the center of the header, with the added bonus that this made it available to use regardless of where a user might be in the application.
The standard Bonsai search component become a very strong focal point. To push it back in space and keep the focus on the results themselves, the component was broken from the design system. All states of the search field and button had to be redefined, but resulted in a much more subtle experience for the user.