Cerebro is the icebreaker for meeting and sharing knowledge with other professionals in your co-working spaces! On the Cerebro website and app, you can discover and book members for professional advice, and exhange knowledge on different areas of specialty.
User + Market Research I was given 3 weeks to conduct research and design a lean MVP product with specs ready for development. I conducted 13 qualitative interviews, and researched co-working environments to identify features and market positioning for Cerebro.
UX/UI Design As the sole designer of Cerebro, I envisioned and sketched the workings of the entire app holistically, allowing for future feature additions to be seamlessly and sustainably added. I established the information architecture, logic, and workflows of Cerebro, and talked in detail with the development team from day 1 to ensure designs are feasible for development.
Usability Testing Whenever a development sprint was complete, I tested the product and watched other users engage with the product as well. I used Github to document bugs and issues, and ranked these in order of priority to be fixed.
Product Management I documented all requirements via Github and Zeplin software for the development team to ensure quality and accurate development execution.
Pitch Presentations I worked alongside the sales team to pitch and give live demos of Cerebro to companies interested in using this product.
The Cerebro app concept was conceived by my CEO Danny, who noticed that employees in co-working spaces are often siloed from one another, and not leveraging nor sharing their diversity of knowledge and skillsets. The diagram below (referenced from Coworking Insights) shows that 97% of co-working space members are freelancers, remote workers, or people in startup and smaller companies. These workers and companies, often bootstrapped with less resources than larger companies, could benefit from shared knowledge.
To validate if there was a need for the Cerebro app, I researched and assessed the features and functionality of existing communication and professional networking apps used in organizations.
Since WeWork is the undisputed leader in the co-working space industry, I studied their mobile app for members. Its only functions are: (1) home feed to see posts from other members, (2) reservation system for conference rooms, (3) following other members, and (4) direct messaging. Below are screenshots.
Excessive Spam Posts WeWork members have complained about logging into the home feed, and receiving too many spam messages or promotional content from other WeWork members. Many members have stopped using the app for this reason.
Unwelcomed Communication Although the app offers messaging ability, members feel it is unexpected for them to receive a message from a stranger. A similar "employee directory" effect exists in LinkedIn. In order to facilitate discussions between members, that action needs to be called out prominently.
No Community Karma There is no incentive nor gamification for sharing knowledge or communicating on the app. For ex, Quora users can gain upvotes for their answers and enhance their credentials.
Slack is a major app for reference since it is popular amongst organizations and startups for communicating and file-sharing. It facilitates quick messaging within groups, and many employees have the Slack desktop app open while they work throughout the day. However, its parameters limit knowledge exchange.
Non-adaptable Network Structure In Slack, a user belongs to a network, and within a network are multiple channels. A user can only communicate with others that also belong to the same channel. Under this model, a user would not be able to contact someone in another company even though they both belong to the same co-working space network.
No Global Member Search Slack is primarily used to communicate to entire groups. In order to message or contact an individual, one must first enter the appropriate network and select that member to message.
No Skills Search Even after entering a channel, there is no means for a user to search or filter channel members based on specific skills. The members list serves as an employee name directory only.
Hit or Miss Communication Slack enables users to message in real-time or asynchronously. However, in order to have a video chat or phone call, there is no way to formally schedule a meeting. Slack has been discussing integrating calendar functionality.
Microsoft Teams is the go-to app for organizations to communicate, share files, and collaborate. It is less used in startup environments and smaller companies. Like Slack, it is not intended for searching or discovering members based on skill sets for consultations or knowledge sharing.
Non-adaptable Network Structure In Teams, a user belongs to an organization, and within an organization are multiple groups. A user can only communicate with others that also belong to the same group. Relating this to the co-working space knowledge sharing model, a user would not be able to contact someone in another company even though they both belong to the same co-working space.
No Skills Search Even after joining a group, there is no means for a user to search or filter group members based on specific skills. There is also no global search for members with specific skills.
LinkedIn is perhaps the first source that people think about when searching for a connection or contact to consult with. Even though LinkedIn enables meessaging, users often are shy about reaching out to someone they don't know well. This phenomenon also exists in other social network platforms because they do not encourage or facilitate "strangers" communicating with each other, aside from adding each other as "connections". Facebook and LinkedIn users mainly connect with people they already know.
With 2,188 new co-working spaces opened in 2018 (according to Inc), this trend is predicted to only continue and increase. People in these communities are currently under-leveraging relationships with professional acquaintances in their co-working spaces. Thus, there is an opportunity to cultivate knowledge sharing in these communities to benefit both co-working space owners and inhabitants.
I also considered Cerebro's use within larger companies and interviewed 4 management level employees. Most relied on traditional methods such as asking co-workers to direct them to the appropriate contact. Only one of them used Microsoft Teams at work. Even on Teams, he still needed to message co-workers in order to reach the right contact. The steps required for these employees to find and reach people within their companies were similar, and are summarized in my journey map below, through a persona.
Since co-working space owners would need to authorize companies and employees to have access to Cerebro, they were users as well, and getting their feedback and perspective would be important. I spoke with several owners based in New York City, and they expressed unanimous excitement for Cerebro, since it can:
Based on user and competitive research, I proposed MVP product requirements, and received approval from my team. I prioritized features for phased roll-outs, as shown below.
One of the first and most important design considerations was determining the relationships between members, networks, companies, and departments within the Cerebro app. I studied use cases for both single entity and multi-entity companies, as shown in the diagrams below.
I came up with 2 types of co-working space memberships: (1) Flat Network Model, and (2) 1 for All Model.
Flat Network Model resembles Slack, requiring members to join and be approved for multiple networks. The advantage of this approach is easier sorting for searching relevant members. The disadvantage is that a member may have to join multiple networks, as indicated in the diagrams above.
1-for-All Network Model resembles LinkedIn, enabling members to connect with all members of the parent network through a single association. The advantage here is convenience - members just have to register once with any network, and they are now part of the parent and associated networks.
Instead of committing to either the Flat or 1-for-All models, I proposed an agile solution in which we manually verify an organization in a co-working space, and once their employees sign up with a corresponding company email address, they are automatically connected. This would be a way to test demand for our product quickly before developing further registration forms. Once we get sufficient feedback, this closed model could be monetizable; it would be in the best interest of co-working spaces to pay for using Cerebro, thereby enabling their members to share knowledge with, and gain access to each other.
In addition, Cerebro, at least for now, is only intended to help members of co-working spaces share knowledge and consult with one another. It is not intended to replace professional communication and networking apps such as Slack, Teams, and LinkedIn, since these apps offer other value.
With this in mind, I created a relational map of my proposed classes and attributes for the Cerebro app. I enjoyed designing this taxonomy, which helped me visualize and design the entire Cerebro app holistically. Writing in SQL and Ruby on Rails coding languages also enabled me to communicate efficiently and precisely with the development team, leaving nothing for interpretation.
The search page is one of the most important screens and probably the go-to screen for user retention. Below is my initial design for the search page.
As a believer in the iterative process of rapid prototyping and obtaining feedback, I asked 9 of my co-workers to provide their opinions on this initial design for the search page. Most felt this design "did the job", but thought it could still be improved. While I had strong assumptions about what these improvements are, I never want to assume - I wanted to hear about them directly from my co-workers, to avoid my own biases. I also wanted to avoid developing any features early on that weren't requested as necessities. Below are some of the feedback.
In my second version of the search page, I considered all of the previously listed feedback to design a holistic solution; 1) I removed the double header, 2) network filters are now directly above the search results in the same module, 3) highlighting any expert on the left will give you a peek of their profile on the right, 4) users no longer need to go back and forth between expert profile and search pages.
Upon scrolling the member list on the left, the Networks and Favorites filters remain fixed. On the right side, the favoriting and book buttons in the member profile preview stay fixed too, as shown below.
All my co-workers and testers liked this design, and were in unanimous agreement with implementing this solution. However, since this layout is not possible on mobile, selecting a specific expert would redirect to the expert profile page on mobile, as shown below.
Once a user finds the right member, the next step is the booking process. I designed an overlay booking module that can be easily opened or closed, enabling users to "X" out of the booking process and return to the member profile without being redirected. Based on my user interviews, the minimal information needed can be acquired through four simple steps: 1) Booking Type, 2) Booking Duration, 3) Reason for Booking, and 4) Booking Dates and Times, as shown in the workflow below:
The company profile page will be a way for members to browse a specific company's employees. Hovering on a member's thumbnail will enable you to preview the member's skills, favorite or book the member. This page will be implemented in the next phase.
My company has been using the Cerebro MVP frequently as a way to schedule meetings, and thus far, it has proven to be very helpful - mostly, in terms of documenting the topics discussed, committing members to the assigned meetings, and virtually meeting via Cerebro's installed video chat feature with remote team members. However, my team's ease of use may be due to our biases based on our intimage knowledge and emotional connection to the product. Thus, I am also working with the sales team to pitch and provide live demos to interested companies for adoption with their respective employees. Our goal is for extensive testing in co-working spaces. Below are some of the feedback we have received during the current beta phase.
One of the biggest frustrations our users faced was the ability to add new job titles and skills. Originally, I had advocated for an open platform, enabling members to add any job title and skill because I recognized that there are many unique job titles and skills that we would never have considered. Conversely, our development and management team felt that opening up the titles and skills database could be a pandora's box, with potentially bad and inconsistent data being added, which would mean lots of cleanup work for our admin team. They certainly had a valid point, and I agreed to try closing the platfom (not allowing new skills and job titles to be added yet), on the condition that our admin team diligently added job titles and skills into our database.
Although we manually added many titles and skills, during my live user testing sessions, I witnessed users' frustrations with being unable to add exactly the job title and skill they wanted. This was inevitable - sometimes job titles and skills sounded similar, but had subtle differences, and our platform did not accommodate these entries. My admin team had to manually enter it in the database for them, which meant they were unable to edit these entries, and would need to contact Cerebro admins to help them. Below are some comments from frustrated users:
Seeing this as a major pain point, I proposed a compromise-solution with the development team: enabling users to suggest and enter job titles and skills. It is almost like the users are actually entering in the fields, except Cerebro admins would get notified immediately of these suggested additions, and upon approving these entries, the new titles and skills would be shown active in the users' profiles. Below is my compromise solution, where pressing the "i" info circle icon in the job title and skills fields will open pop-up modules for suggesting new entries.
The development team was happy with this compromise solution, and our users had no trouble with it either. Moving forward, the development team has agreed to implement the ability to fully add new job titles and skills.
Most users had an easy time completing the onboarding process and searching for members. However, for a few users, after creating their member profiles (and arriving at the screen shown below), they were at a dead-end and did not know where to proceed.
Thus, I proposed implementing tool tips to appear once a user arrives at the newly created member profile screen. Tool tip #1 introduces the dashboard features, and tool tip #2 introduces the network search feature, as shown below.
Since implementing these tool tips, I have not observed any user being stuck or unsure of their next steps after onboarding. In fact, following the tool tips, most users have clicked on the network icon to see if other members within their networks have signed up.
Below is a list of additional features suggested by testers in my company and co-working space. Most of these functions will augment our usability and desire for users to engage more frequently on Cerebro. What I was happy to find was that some of the suggested features were brought up over and over again by users without me asking them, such as the message board, office hours, and direct messaging. This is valuable feedback for me, as I initially left out direct messaging because I did not want one-off messages here and there to prevent actual bookings from occurring. However, I understand users' view that a direct booking without a soft message may potentially appear cold and too transactional. I think there can be a way to integrate messaging while compelling users to make bookings. These recurring feedback justifies the need for: 1) Direct Messaging, 2) Message Board, and 3) Office Hours.
However, I consider a few suggestions to have less credence, such as the "chatbot for booking", since only one user brought it up, and requires a significant level of effort to develop. As I continue to collect more feedback, I can prioritize which of these we will develop next.
In speaking to users, I had the chance to evaluate their underlying motivations behind using Cerebro. The majority seemed genuinely excited about having a platform where they could search for people in network with the skills they need. One of the major takeaways is that users liked our focus on setting up bookings between members, whereas other social networks may prioritize adding connections, which does not necessarily lead to real conversations. Below are some of my main takeaways.
Within my co-working space, I have observed interactions between members of different companies. Because we are in a compact space, it is very convenient for others to pop in to our office and ask if we have some time to give them advice about something. It's also more "human" for us to interact in-person considering our close proximity, as opposed to sending booking requests to each other via Cerebro. However, in larger or remote co-working spaces, booking requests work best.
I believe that in our age of social networking, we have accumulated so many connections on LinkedIn and Facebook that we've lost track of who we actually know or would contact in times of need. I hypothesized that if Cerebro only allowed members to view people in their network - people in their companies, company departments, and other companies within their co-working spaces, that members would have more meaningful connections, since these are the actual people they see daily, but may not interact with. In order to validate this hypothesis, I asked users how often they reached out to someone on LinkedIn that they didn't actually know. Though some users said they had added people they didn't know because of their interesting backgrounds or for job opportunities, most of them did not end up having meaningful correspondences. Most users liked that Cerebro filtered people within their co-working space, so there is actually more value in each network connection.
One of the users I interviewed is a CTO who felt his skills as a software engineer were very much in demand, as he is frequently asked by others for freelancing opportunities. He feared that he would get booked by others often on Cerebro, and feels he would be on the losing end of the bargain since he doesn't foresee himself booking others much. Below are a few potential solutions, some of which have been proposed by users:
Credit System where every member is given a default amount of credits for use (1 credit = 1 booking), and for every additional booking request they make, they owe the network a booking session. In other words, they have to share their knowledge with someone in the network who books them.
Payment System where members get paid their specified rate for offering advice or help to those who book them.
Karma Points where members are given "karma points" for helping others in the network. This would be similar to an expert on Quora gaining upvotes, which credentialize the member.
Advantages In theory, these 3 systems would make members feel pride within the co-working space, and may be valued more by their immediate employer. For those with less bookings, there is a gamification effect where they would feel more obliged to help others. This would ensure every member is contributing to the network, thereby strengthening the network. This would also justify a monetization model where co-working spaces pay Cerebro a monthly fee, and attract new members to join.
In order to have a deeper understanding of how to convert some of the more hesitant and laggard users, I not only designed potential solutions, but more importantly, examined the deeper motivations behind why these users would use Cerebro. I referenced Maslow's Hierarchy of Needs in regards to the desired Cerebro user behaviors. Maslow believed there are different levels of pyschological needs that may influence behavior:
Maslow's Hierarchy of Needs
The chart below shows why some users would not use Cerebro. By identifying their exact objection reasons, I was able to understand their underlying motivations of what it would take for them to use Cerebro. I was therefore able to suggest and confirm solutions through this process.
Through this project, my development team and I have formed strong chemistry in our working process. We had daily standups for 15 minutes to review our daily tasks and provide updates on revisions or pending issues. After designing high-fidelity mockups, I uploaded my Sketch files into the Zeplin software, which automatically converts the designs into HTML and CSS code for our front-end developer. In Zeplin, I provided specs and documented logic and workflows between screens. I used GitHub to manage development requirements, status and issues.
Once updates were pushed to the development server, I took the lead in usability testing, and documented all bugs and priority fixes in GitHub, as shown in the screenshots below. We used GitHub to message each other as well, keeping accounts of our design and development discussions. In the screenshots below, the highlighed BennySOL issues were documented, and signed off by me upon successful execution from the development team. I used email as well, with direct links to the GitHub issues I created, for my team's easy access.
I believe my development team and I have established an efficient and accountable process, as we completed a functional Cerebro MVP within 7 weeks.
The Cerebro MVP is currently being tested in three co-working space franchises - Kin Spaces, Convene, and Salt Flats. I am focused on obtaining sufficient feedback to determine feature additions and revisions, as well as our product roadmap, launch strategy, and business model moving forward. Stay tuned for updates!
