Cohort — From Nothing to Something.
Brendan Hastings leads Product Design at Cohort. This is his account of designing Cohort over many months and how we, as a product team, adapted it along our journey.
Designing a new product is hard, you have to keep your eyes on a distant horizon, whilst dealing with the details of an immediate problem or insight.
Cohort started with the simple idea that people meet each new day with all their skills, experience and passions, but leave behind the power and potential of their network. We believe that each person’s potential is not only what they can achieve as an individual, but also what they, in combination with their trusted relationships, are capable of.
Their network is a fractal pattern, leading out through pathways of trust, each one capable of a different outcome. We wanted to help people discover the potential of this trusted network and give them the tools to act upon it.
To tease out this concept and test our initial assumptions, we spoke to people who rely on their network everyday to create value. We asked them about the people they know, to identify their important relationships, why they are important, and how they relate to their professional lives. We looked for moments when these people attempted to use their network for help and asked about their process of searching. We examined the tools that already exist for allowing people to discover the power of their networks, such as Twitter and LinkedIn, browsing through friend lists, phone contacts, or sending out group emails and messages.
We tested some of our own ideas about network discovery in these situations by showing people that we had discovered within an individuals network, that might help solve a particular problem. We looked at how networking loops were closed through introductions and how social capital flowed between these individuals. This helped us map out the detail of an initial need, all the way out to its completion within the network.
We created Task Models, Flows and Forces Diagrams, here are some examples:
Research outcomes
From our research, we discovered that when people need help with something that they cannot solve themselves, they quickly begin to think about how their network might help them. However, they often find it difficult to remember who they know that could help, and find it almost impossible to discover how friends of friends can help. People are clearly not using their full network potential.
It’s also clear that people have deeply subjective ways of thinking about their personal networks. They categorise people depending on context and relationship, and this directly influences whether they would request help from or give help to an individual in their network. For this reason we had to discover a stable ground from which to work. Human relationships are incredibly complex, so our goal was to find a simple way to solve this problem.
From our observation of networking moments, we saw that there are three roles: an Asker, a Broker and a Helper. The Asker is the person that needs help. The Broker is the person who knows someone else in the network who can help. The Helper is the person who can help with the initial need.
The Broker is not always necessary for completion of a network request if the Helper is known directly. These three roles could be applied to any networking situation or problem. We created some hybrid persona/empathy maps to help guide our thinking. Here they are in their provisional state:
Because the impetus of a networking moment is generally on the Asker, we needed to offer a way for them, as a single user, to discover Brokers and Helpers that could help them. We cannot rely on their friends using Cohort, nor can we define the exact problem that they need to solve. This means we have to offer a broad base of concepts (or interests) and apply them to a large group of people in relationships, in order to allow people to resolve any problem through their network.
It is difficult to know exactly what concept a person will search their network for, however the problems they face are of a similar ilk, and can be grouped under various user types, such as: founders, VC’s, people looking for jobs, team leaders looking for hires, and sales people, and general networking.
Much of our initial research was done on founders and VC’s working in technology-oriented contexts because they are avid networkers who need to create value with their networks everyday, and often are early adopters of new products. The problems they face, such as finding hires, customers, partners, and investment, are issues we knew we could help with, and so they became our focus.
Turning our research into a product
The observations and findings from this research helped us map out a clearer idea of what Cohort would become. To help us validate our product decisions during this process, we set out a provisional set of design principles that would help us keep the design within the bounds of our research and what we wanted Cohort to be:
- Keep it simple.
- Be grounded in real word human social dynamics.
- Make it useful to even a single user with no friends using Cohort.
- Allow for “give” and “take” actions within a network.
- Transformational interactions over transactional ones.
We spent the early design phase iterating through low-fidelity, sketched-out wireframes and system diagrams. Once we were happy with these, we moved directly to high-fidelity designs and, framer prototypes. The overarching goal was to get to HTML/CSS so that the design could be implemented in the hybrid development framework, Ionic, hooked up to the data, and then tested. We knew we had to test our ideas for Cohort in real world situations as much as possible to find the simple, universal middle-ground within the subjective world of networking.
This process enabled us to diverge in many different ways from our base understanding of Cohort and the space it inhabits, moving between how someone organises their relationships and the opportunity that gave rise to a querying of their network.
We tested Cohort as a chat bot, a contextual recommendation system, machine interpretable free-text entry recommendations, need publishing, and workplace skill discovery system, amongst others. Starting down one line of reasoning helped us to see how it might play out and whether we thought it was worth progressing further.
Some examples of the early stage directions:
The first versions of Cohort
As we iterated our prototype, we slowly zeroed-in on the first version of Cohort. Our aim was to release the prototype as our 1.0 to get real-world feedback in a wider context. Our prototype had to be robust, as did all the behind-the-scenes development work, such as how people were signed up and how their networks were discovered and analysed.
Even though some of this work was a little haphazard and, in some cases, Ionic wasn’t quite up to the task, this process really helped us get a feel for Cohort as a product, without having to jump into a full-on production version.
When Cohort was released as a limited private alpha, it looked like this:
This first version was based around the idea of creating an opportunity (later termed “an Ask”), which was a tweet-sized piece of text describing what you needed help with. We would then analyse the text and make recommendations of Brokers and Helpers in your network, based on who we had discovered within your friend-of-a-friend network and their interests. These relationships were categorised either as “close” or “acquaintance”.
This meant that opportunities were both machine- and human-interpreted. This helped people to discover relationships that they would never have been privy to, as well as tap into the serendipity of human relationships that Cohort could not have known about.
From the base of close relationships, interest analysis and opportunities, we iterated through various releases and features. Some of the bigger features we tested were:
Teams: This allowed users to analyse their team’s friend-of-a-friend network and ask for introductions.
Introductions: This helped people go through a formal opt-in introduction process.
Feedback: This allowed people to give feedback on the appropriateness of a recommendation.
Thank Yous: This was a way of thanking people for help, which allowed us to keep track of reputation and completion.
Comments: Allowed for discussion of an opportunity and the people involved.
Organisation view: We did some early experiments on what Cohort might look like if it was deployed across an organisation. There’s likely a version of this in Cohort’s future.
Observations and Cohort 2.0
Cohort 1.0 and its iterations helped us see that the double mechanism of machine- and human-interpreted opportunities, caused a cognitive dissonance for our users. We got to the broadcast part too quickly. There needed to be a gestation period, a more in-depth exploration of the network, a greater control over what was being returned and who was seeing it.
We also discovered that our categories of “close” and “acquaintance” were confusing. In our attempt to show the possibilities of Cohort, we had overstepped the need to do things simply.
We knew we needed to strip Cohort back to its bones. This meant finding people who could help with a specific problem, either directly or through their network.
So, we removed the opportunities/asks and focused just on searching, which allowed the user to look through their network in a slower, more exploratory way. One issue with this is that it made Cohort a little less social (in a broadcast sense) and open to random input, but we knew we could add this back in once we had nailed the experience around discovery of people and their interests / skills.
Cohort 2.0, which was built in React Native, looked like this:
Through the observation of people using this new version, we saw multiple areas in which we could help our users resolve their networking needs and we iterated by adding the following features:
Shareable profile: This feature helps users share the profiles of people who can help with other interested parties. They can also share their own profile to show how they and their network can help.
Messaging: This feature makes resolving a need much easier as you can discuss it within Cohort.
Community Cohorts: This feature is similar to the teams feature, as it allows us to group people in contextual relationships, which is useful for communities and organisations who need to search over many individuals networks. This is the main focus of the latest version of Cohort, as we recently announced.
What happens next
This is the latest version of Cohort and we are excited to see how people use it and how they tap into the full power of their network. We have already started to plan Cohort’s next steps, such as allowing users to save people to a personal list for further research, allowing searches to be shared across cohorts, and enabling threaded Community Cohort messaging.
We can also now revisit some of the minutiae that we had to avert our eyes from as we discovered the true shape of Cohort.
Personally speaking, as a product designer, this process has been a whirlwind of trade-offs and discovery. Attempting to find a place in the tumultuous world of human relationships and professional action has been difficult but rewarding, and we can’t wait to see how Cohort will develop as it grows.
In a follow-up post I’ll go into some of the trade-offs we faced; like how focusing on system-level details is more important than tiny visual details, and how designing features in their simplest form allows you to quickly adapt as you observe use.
Cohort is available to download on iOS and Android. If you’d like to use Cohort for your community, business or organisation, let us know here.
