UX Case Study: The Role of Slack in Bootcamp Education
Overview
Our project challenged us to deliver two new features for the Slack mobile app that would help the company better serve students in the bootcamp education space. Slack offers solutions for workplace-oriented collaboration, through direct and group communication, file sharing, and organization around projects and initiatives. While Slack is most prevalent within traditional workplaces, it is also viable for education centers, as it offers a way to connect students with a format that lives completely within the school structure, without divulging personal contact information.
Responsibilities
I had the opportunity to collaborate with two colleagues for the user interview stage of the project. Liz Mak, Ajani Ojoye, and I split the responsibilities equally in preparing a discussion guide, recruiting and interviewing participants, and documenting our results. Outside of that stage, I was responsible for all other components of the project below.
Problem Space
Thinking through why Slack would identify bootcamp students as a development centerpiece, we began to consider how this relationship could be mutually beneficial, and how the needs of the bootcamp student contrasted with those of users in other education formats and traditional corporate settings. Based on our knowledge at the time, we saw the bootcamp environment as being unique with its short, fast-paced programs, and the constant turnover of population that results.
Users
The intended users were students studying in this bootcamp education environment, who face unique experiences based on the format described above. Based on the education setting, the average student was likely to be new to the targeted industry, surrounded by peers of similar situation, and facing heavy time constraints.
This led us to the initial hypothesis that, with the time constraints and accelerated pace unique to the bootcamp educational experience, students needed an easily adoptable pattern for communicating and sharing information, without the benefit of typical social learning methods.
Scope and Constraints
The project was confined to the time period between August 26, 2019 and September 5, 2019, with no funding, and both our team and participants needed to be based in New York City. The limited time and budget presented some unique challenges, especially in our user research and usability testing. We had little choice but to prioritize timely availability of participants over careful screening, which ultimately showed in some of our results.
Process
We structured our work around a double diamond process, in order to ensure that our design would be user-centric and properly address the problem space.
Research
Because of our time constraints, we conducted four in-person interviews, averaging 15 minutes in length. All participants were current or former bootcamp students in New York City, ranging in age from 24 to 42. We prepared a discussion guide based on behavioral questioning, asking participants to describe specific experiences with the app in the bootcamp environment.
We synthesized the results by first visualizing response patterns through three iterations of affinity mapping. This led to far ranging insights which we further developed into a few key takeaways:
- There is a lack of understood communication norms, which leads to frustration in students.
- Disorganized communication makes information harder to fund, and stress-relieving activities harder to initiate.
- In the attempt to avoid connection to their devices at all times, students can have anxiety about missing important messages.
With these insights in mind, we crafted a primary persona to better shape our decisions as we continued into the design phase. This gave us Melanie, a 25 year old career changer that prioritizes organization in group collaboration, and wants to carve out some mental space and disconnection while away from school, without the anxiety that she will miss urgent messages from her team members when working on group projects.
Now being able to directly address the concerns of users such as Melanie, we returned to our initial problem statement, and revised it to the following:
Based on the schedule and requirements of bootcamp education programs, students constantly feel short on time, and must prioritize their activities to handle the fast-paced environment. This leaves little time for learning and agreeing upon standardized communication techniques, and as a result, Melanie feels frustrated with the impact of disorganized methods on her time. How can we provide Melanie with an easily adoptable, less intrusive, communication system for collaboration with her peers, in order to give her peace of mind both on and off campus?
Design
With our problem statement and persona in mind, we began to ideate potential solutions through sessions of rapid sketching. The aim was to visualize a large pool of solutions that could then be funneled down into appropriate responses to the key insights.
Initially there were ideas of having separate guides within the app to explain the available options for initiating and organizing messaging. However, the concern was that this would not be leveraged, as users showed reluctance to devote time to learning more about the app if it was not directly incorporated into their regular use. The solution needed to be tightly wrapped around the features they looked at most. This led to idea of having suggested phrases and functions built into a horizontal scrolling bar above the input box in the chat channel, where users could select from multiple options. Yet, this could bring problems of users accidentally selecting undesired options while scrolling, if selection would be from a tap. Ultimately this led to presenting three random phrases or question functions (polls, thread questions, and sign-up lists) that would be responsive to words that came up in the chat channel. Next to the random options were buttons to select additional phrases and question functions. In this way, the random options would introduce the user to what was possible, and show a route to additional options without causing frustration.
To address the need for a more balanced connection to the alerts from the app, we sketched out solutions within the app’s current “Do Not Disturb” settings. There were current nuances to the notification settings (what users receive), but the options were much more binary for the Do Not Disturb option (when users receive notifications). Thinking through our persona’s perspective, we came up with the need to turn Do Not Disturb on while still allowing specific notifications to come through, based on channels, keywords, and individual users. While those solutions seemed to address the need to receive notifications for specific reasons during Do Not Disturb hours, they could still fall short in reducing anxiety when no specific reason is in play. So we added the option to have notifications sent in batches, with intervals ranging between 15 minutes and 2 hours. This way users could still feel that they were receiving notifications, while feeling more control of the cadence in which they came in.
We took these concepts to low-fidelity wireframes, allowing us to quickly move to user testing with a paper prototype through InVision. Using guerrilla in-person testing, the tests covered a diverse set of 5 participants and 5 separate scenarios and tasks, to better understand the usability and intuitiveness of the new features. The tests validated the purpose of the features, as the participants understood their value, but there were some issues in the representation and distinction between options. Much of this came down to word choice in the copy, and how the buttons were represented. The largest hurdles were creating in the eye of the user a connection between the three random suggestions and the buttons to access additional choices, clarifying the choices in the poll feature, and concisely explaining the batched notification option so that it would be obvious to the user.
We addressed this feedback directly when we went to Sketch to produce detailed mid-fidelity wireframes. While the structure of the features stayed intact, we reacted to the test results by adjusting the copy and making the association between the suggestions and additional option buttons more clear by adding matching icons to both sets. Phrases were represented by quotation marks, and the question options were represented by a wrench image, thinking of those options as tools.
Using InVision again, we ran another round of usability tests, with 5 new participants. These tests relied on the same overall methodology as the first round, except for the addition of quantitative elements, by timing the tasks, asking for an easiness rating from participants, and documenting the success rate of each task (distinguishing between the attempt being unsuccessful, successful with an indirect path, or successful with a direct path). Of the 25 total tasks that were tested, all were successful, although some were with an indirect path and took longer than the average to complete. This showed that they layout of the features was intuitive for some users, but not all. The biggest issue was the choice of using the wrench icon for the question tools. Users associated this issues with tools, and it made the tasks that required going to the settings menu more difficult than what we saw in the first round.
Prototype: https://invis.io/B6TQLZAFZGT
Outcomes and Next Steps
Due to the significant time constraints, we were unable to do another iteration and move to a high-fidelity prototype. Our primary recommendation was to change the tool icon to a check mark with a question mark inside of it. We also recommended using clearly distinct colors for the two categories in the high-fidelity version. For the notification features, we recommended changes in copy such as making the batched option more conversational (“Only send me notifications every…), and moving the location of the option itself. While the second round of usability tests proved that additional changes were necessary, we still felt that our identified problem and presented solutions were valid.
Beyond that, we concluded that the move to a final prototype was justified, and would ultimately prove valuable for both the stakeholders and intended users. By offering optional features that cater to the unique bootcamp pace and structure, Slack could provide a communication platform that offered small but important opportunities for stress relief and peace of mind to students. At a transitional time when the effects of these small pockets of relief are amplified, such adjustments could not only lead to increased use in comparison to other communication platforms, they could create lasting associations with the app that students would bring to their future workplaces.
I personally came away from this project with a significant takeaway. I realized that I went in wanting to provide solutions that directly addressed the most significant goals of the bootcamp student: excelling in the program and securing the desired job at its conclusion. I was almost disappointed when the interviews generated concerns about organizing group questions and post-class hangouts. I was pursuing a comprehensive solution to the most significant bootcamp student challenges. The truth is that, even if possible, users most likely do not want you to be that all-encompassing solution. That can be too intrusive, and disregard too much the star that they want to see taking the final bow: themself. But I could help protect the mindset to allow them to get there. That was an important lesson on UX design. Often it centers on crafting the smallest detail to help provide the user with the peace and clarity to use the best tool for the largest goals: the user.
