The way we organize companies is changing.
You’re probably familiar with the traditional top-down company structure, but many organizations are adopting flexible structures that distribute decision-making and promote cross-functional teams, in which the members have different skill sets.
With constantly evolving structures, you need a dynamic system that encourages collaboration by tracking people’s roles, responsibilities, and actions toward a common goal. We created Huzzah to solve this issue.
Step 1 : Research
Conduct user interviews to understand needs and motivations
Our first users were Zappos employees. Zappos is well known for shifting their organizational structure to Holacracy, which is a team-based, self-organizing framework. The company already had a Holacratic software system in place, so our product team was challenged to make adoption of our software worth the employees’ time and effort.
Through user interviews, we developed three personas:
The common thread? Employees wanted a centralized place to quickly find information about other teams’ purposes, members, roles and responsibilities.
Step 2 : Strategize
Create the app architecture and primary user flows, incorporating immediate user needs as well as long-term product goals.
The sitemap gave form to abstract ideas and helped identify what features should exist that aligned with the product’s goals and the user’s main needs.
To prepare to launch the application as a SaaS product with a marketing site, the application was planned with a full authorized and unauthorized section.
We created high-level charts to highlight critical user flows of the application and break down processes the user would use to achieve specific tasks. These visual workflows are essential for finding holes in processes as well as getting the product team on the same page, from ideation to development.
Step 3 : Test
Launch! Then observe, evaluate, and iterate.
We excitedly launched with the initial features. But we quickly noticed that something wasn’t quite right—employees weren't adopting Huzzah as readily as we thought they would.
We realized that one key ingredient was missing: robust data. We had migrated data from the previous software and included space for users to enter additional information, assuming that people would enter information to promote their team and keep records. But that was not the case. Users would come to Huzzah searching for a specific piece of information, not be able to find it, and decide that Huzzah was not something that warranted their time. So they, in turn, would not take the time to enter relevant information about their work. This created a negative feedback loop. (Check out this article by John Bunch for a deeper dive into positive feedback loops.)
This discovery spurred us to implement features that would get information into the tool and make it easily searchable.
We built another small tool called Survey Bite, which sent out a daily 15-second email survey to every team member. Each day, team members got one question about their hobbies, skill sets, or work preferences.
Every time someone answered a Survey Bite question, that data would be loaded into Huzzah. Each answer inching closer to Huzzah being a trusted source of relevant information.
Our first iteration of the search feature indexed major information like titles and headlines, so search results weren’t comprehensive, and many times the user couldn’t find what they were looking for.
Analytics and usability testing confirmed our assumption that users leaned heavily on the sitewide search. So, we overhauled the search feature to index all content and tagged items, prioritize relevant results, and categorize results to be more easily findable.
Step 4 : Refine
Observe, evaluate, and iterate...again.
For the 3.5 years that I worked on Huzzah, we consistently conducted usability tests, streamlined workflows, studied analytics, ran quality assurance tests, and refined the technology we were using in order to enhance the performance and overall experience of Huzzah.
We conducted moderated studies with small groups to get thorough feedback, and we sent out larger sentiment surveys to benchmark and track overall progress.
Testing led to iterations on many parts of the app, including the structure page. Since clearly conveying org structure is a pillar of the app, we tested it rigorously.
Behind the Scenes
From the beginning, Huzzah was architected to accommodate any type of organizational structure—from hierarchies to self-organizing teams and everything in between. To provide this hyper-customizability, the back end code was very abstracted and generalized. This allowed each organization to make their own “rule book” for how teams in their company related to each other (i.e. parent/child), and how roles and responsibilities could be distributed.
Since teams within organizations often have different goals and workflows, we created a template library in which admin users could create and customize the pages within group types.
For instance, a marketing team might use the default group type with seven tabs, while a dev team could use a specialized group type with nine pages, including a page that integrates with their project mangagement software and a page with specific development procedures.
Huzzah was used internally for two years at Zappos.com before it launched as a SaaS product in 2020.
What Went Well
- Immediate access to a core user group gave us lots of opportunities for research and feedback.
- The site architecture was robust and thoughtfully constructed so that vitually every element, from organizational structure to individual labels, could be customized by the end user. This required enormous diligence from all team members to maintain this level of abstraction in everything from user workflows to coded class names.
- Our product team was truly agile and could quickly pivot if there was a change in priorities. And we couldn’t have done it without our top-notch product managers.
- Thinking that users would spend time entering information into Huzzah because of its potential benefit. (Details in the Step 3 section)
- Balancing immediate needs of users with the long-term project goal. Because this app replaced exisiting Zappos software, users expected Huzzah to have all of the major functionality of the previous software, and it did not when it launched. In the future, I would more heavily focus the initial user interviews on determining the features and workflows that must be available on launch in order to accelerate onboarding and adoption.
- If we were to continue on this project, I would focus on complete implementation of the design system and UI accessibility updates. Although many of the elements were part of the design system, some of the legacy pages were not, so making complete global style updates was difficult.
- This application has a very solid foundation and lots of potential to encourage new ways of organizing companies. In a future iteration, I would recommend separating the major features into different webapps that pull information from Huzzah’s robust database in order to make the overall product lighter, faster, and more focused.