How we tested, designed, and built a brand-new team onboarding process
Two weeks ago, we released Stack Overflow for Teams — a way for teams to share information privately. A ton of work over the last year has been done to release this exciting new product. This post goes into how we designed the custom Team onboarding experience and how we see this feature possibly expanding in the future.
Hard problems
The hardest problem at Stack Overflow isn’t creating the functionality to post questions or answers, notify users of these posts, calculate reputation, commenting, voting, or any of the other various tools that are used within a community (These are all core features to a Stack Overflow community.) The hardest problem is starting a community.
If you’ve ever tried to start a forum discussion, chat, or other type of online group, you’ve experienced the massive amount of effort needed to start that group. And once the community starts generating some momentum, your work doesn’t go away — it shifts toward increasing the community’s momentum. It’s difficult work, which is rarely recognized.
In fact, if you’re a part of a community like this — take a minute and tell the community owners how much you appreciate the effort they put into helping shepherd and guide that community.
Small(er) communities
One interesting feature about the Stack Exchange network is that anyone can suggest creating a new community. If there’s a knowledge area that interests you and potentially interests others, you can submit your idea on our “Area 51” website. This website walks you through a number of steps to help you go from a community idea to an actual Q&A community.
One criteria we’ve held for new communities is that they need to be of a certain size and show consistent growth for us to “graduate” that community as an official Stack Exchange network site. There have been hundreds of proposals submitted, and failure to reach the needed community size is consistently a top reason for a community’s inability to graduate.
Understanding the problem
One of the largest, initial problems for Stack Overflow for Teams then was a three-fold problem:
- Communities are hard to start.
- Smaller communities are even tougher to start and maintain.
- An inability to solve problems 1 and 2 will mean Stack Overflow for Teams doesn’t have a future.
This is a big problem. It’s also a unique problem. How do we help anybody start their own private Q&A community and be successful at it?
Some key findings
Thankfully we had already been starting to think about this problem for our Stack Overflow Enterprise customers. Through this team’s work and other work the User Research team conducted, we started to learn a few key things:
1. Identify people who really care about this.
It’s hard work to start a community, and it becomes even harder if people don’t care about the community’s success.
2. Starting with an empty community rarely works.
It’s really tempting once you create a Team to let everyone know about it. The idea is that if you build it, people will come — right?
What we find though is that people prefer to have some content already in place. This seeded content removes the decision paralysis that comes with a blank canvas: there are so many possible questions that could be asked, that you end up asking none.
Seeding content provides some ideas right away and helps people overcome this paralysis a lot quicker.
By sharing the community setup workload … , the task becomes easier for everyone.
3. Don’t go it alone.
If we find that starting with an empty community doesn’t work, the goal during setup becomes about creating some initial content before everyone else joins in. While this content could be created by 1–2 people, we found that the task becomes a lot easier if its shared with 7–10 people. By sharing the community setup workload with this core group, the task becomes easier for everyone.
Testing ideas
Taking this initial research, our next step was to test out these ideas. A typical project at this point at Stack Overflow would have had us writing a spec, creating some wireframes, designing artwork, and building a prototype before testing it with users. This process would take weeks for us to learn crucial information. We didn’t want to waste weeks to test an idea, so we changed our approach by testing lo-fidelity versions within a couple days.
Using slide decks and clickable prototypes we were able to test and adjust our ideas within a couple weeks versus a couple months. We knew that above all else, clear copy would win the day. So we created a simple Google Slide presentation with our proposed copy and interviewed a number of individuals to gauge their reactions.
By testing the ideas out early and in such a low-fidelity manner, we discovered two things:
- By keeping things low-fidelity, we didn’t become attached to the idea. Since we hadn’t invested a lot of time in the ideas, letting go of them became easier.
- Because we were able to let go of ideas more easily, we were able to iterate more quickly.
Altogether we were able to test multiple low-fidelity versions within a two-week period.
Finalizing our checklists
One thing we learned during our research was that people responded well to being provided a setup checklist. One person, upon seeing the checklist, remarked that it helped them better understand the effort level required to start their community, which they had not considered before.
Every feature or task holds some value — otherwise why would we have it? The hard part when creating onboarding workflows is identifying the core items people need to understand at specific moments in the process. For example, while it might be a good idea for someone to understand how to create a new tag, this isn’t a primary concern. Understanding how to create a tag only becomes important when people are asking and answering questions.
Our goal was to help a Team focus on specific, core tasks during certain stages in their first 60–90 days. We divided these tasks into three groups:
- Setup period: Initial 10–14 days during which 5–10 people help seed content and get the Team setup for everyone else to join.
- Launch day: The day you’re ready to invite everyone into your community.
- Post-launch: Provide community goals for the next 45–75 days to help continue and maintain momentum.
Every task within these checklists reinforced core activities that are regularly found within successful communities.
Along with the checklists, we also created starter questions. Going back to one of our original key findings: “Starting with an empty community rarely works.”, we found this applies to Team creators and guides as well! To help this first group get started, we provide questions that range from identifying people within a team to type of questions that should be asked. These unanswered questions allow for admins and Team Guides to jump in right away and start providing thoughts.
Looking ahead
This is just the beginning for onboarding. Our goal isn’t just to start communities, but to create strong, healthy, lasting communities that are trusted sources for a team. But that doesn’t happen if people don’t continually participate. So we’re exploring how we can continue to help teams as they reach the 90-day period and beyond.
That said, we know it’s not perfect and we’ll continue to test and observe communities as they use the current onboarding process.
We also excited about the possibility of taking this work and bringing it back to Area 51 for public communities. Much of what we’ve done within Teams applies within a public community setting as well.
Healthy, strong communities don’t just happen. They’re products of purposeful, diligent work from a cohort of dedicated individuals that help provide a place for others to join in and share. By providing initial guidance, we hope that everyone will feel confident in starting their own community today.
This post was originally published on the Stack Overflow blog.
