Final project at general Assembly. Rethinking a professional networking app
One of three UX designers working on the project
Project canvas creation, competitive analysis, task analysis, user survey, user interviews & analysis, contextual inquiry, persona & scenario creation, Jobs to be done framework, user journey creation, experience mapping, affinity mapping, design studio, feature prioritisation, story boarding, wire-framing, hand drawn prototyping, prototyping in Sketch and user testing.
Paper and felt tip, Post its, Sketch and Invision.
Double Diamond process, Morville’s UX Honeycomb, Nielsen Norman rule of 6 tests per round and, Nielsens 10 Usability Heuristics for UI design.
USING THE APP
We had received a brief but before I did anything else I downloaded the app and tested it out a little myself. I used it for about 10 minutes and noticed a few issues. My initial thoughts were that the concept wasn’t clear and that the first time intended user flow wasn’t intuitive or obvious.
WHAT IS CAUSR?
We each took a few minutes to read through the brief individually and then came together to discuss. We figured out that the aim of the application is to aide users in capitalising on missed networking opportunities in everyday settings where they would most likely not engage with others. The idea is that the user would join groups based on interests and then use the app in public when they might have time to spare. The app would show the user who was around them who had also downloaded Causr as well as what groups they have joined. The users could then message each other and either meet on the spot or arrange to meet later, thus making use of their spare time in networking.
The brief challenged us to re-design the on-boarding process which the client believed was causing users to drop off before completing the first time intended user flow:
The brief dictated the core audiences as follows:
Individuals at co-working spaces.
Individuals who signed up to private members clubs
Moreover it posited that those travelling or working remotely would have more to gain from Causr and set out the use case as
When I am "at the airport and my flight is delayed. Are there any useful people [that] I could connect with?"
PROJECT CANVAS & SPSO
The next thing that our team did was create a project canvas in order to define all the variables accurately and create a visual we could refer to when we were bogged down in detail. This followed on nicely to our situation, problem, solution and outcome framework which was also done to further understand the applications’ purpose.
Situation: Networking is an important aspect of most business professional’s working life yet a lot of time is wasted by people when alone where they could instead be networking, learning or even chatting to like-minded people.
Problem: There are too many missed connections between people because they don’t have the confidence or the permission they think they need to approach others.
Solution: Causr prevents business professionals missing out on meaningful connections by allowing them to easily connect and meet with relevant people near them.
Outcome: Professionals can build their existing network and create opportunities for themselves as well as potentially help out the person they connect with.
We then looked at the competitive landscape and split the competitors in to direct and indirect groups.
After a couple of months in the role I began sitting in on the mobile product roadmap management meetings and noticed that none of our upcoming projects had been validated with any sort of user feedback. I mentioned this to the product manager and though there was some resistance to begin with I convinced him to allow me to do some research to see what our users thought .
Shapr, Grip & Weave
Shapr, Grip and Weave all have similar models to that of Causr in that they are all interest based professional networking applications. Causr differentiates itself in that it is made for networking now, meaning its primary use is to message users around you to meet and network now; whereas the rest are about messaging to arrange a meeting later. Moreover Shapr, Grip and Weave all use a swiping feature to match users similar to that found on dating apps like Tinder or Bumble; evoking unprofessional connotations.
We looked at Linkedin because it is the industry leader in the digital professional networking space (500 million users as of April 2017) and because of the vast amount of information it owns on all of its users. Causr already pulls some information from Linkedin on users’ professional history and interests, but we looked into how the API could be further utilised to make Causr more effective.
We also had a look at Meetup which allows individuals to create or sign up to events of interest so that they can network at said events. One thing we noticed about Meetup is that it had an excellent on-boarding process.
We set out all of our analysis and compared the methods and features that each of the competitors had employed.
Armed with a decent understanding of our brief as well as what the competitive landscape looked like we set a meeting with our clients and scripted our questions.
After doing all the necessary introductions, our clients explained why they had created Causr, what hurdles they had overcome; and what hurdles lay ahead of them. This meeting brought a lot interesting things to light and gave us the opportunity to understand the mindset behind the application as well as dive a little deeper by asking questions face to face. For example our brief stated that in the eight months that Causr had been live the app had been downloaded 2,000 times with users exchanging over 500 messages. In the client meeting we discovered that the owners had been responsible for initiating over 60% of these messages.
We sat down post the meeting and discussed our takeaways; then altered our strategy as a result of the new information we had learned.
USER TESTING THE CURRENT FLOW
In order to gain a more in depth understanding of why the application was not working as our clients had intended we took it to for a test drive with users at a networking event for digital professionals.
USER TESTING THE CURRENT FLOW
In order to gain a more in depth understanding of why the application was not working as our clients had intended we took it to for a test drive with users at a networking event for digital professionals. Here are some of the things people we tested with said:
“I don’t get it. How does proximity and location fit together?”
“When people haven’t written anything it looks too empty, there needs to be something to fill up the profile pages. I wouldn’t want to connect without having more details here”
Testers also complained about the order and logic of the flow pointing out that it didn’t make sense to have to connect with someone before you where able to message them especially considering the concept.
“If I were to want to connect I would want to message them first, not wait to be connected with them.”
Finally testers complained about the information displayed when joining groups based on interests.
“What is the benefit of these groups?.. I don’t feel like there is enough description about the groups on the group pages.”
The insights we made at this event were invaluable to us and the process of testing allowed us to really understand what was wrong with the app, and where the experience was lacking.
We mapped the first-time user journey and conducted the task analysis around it, in order to help us further understand the mindset of the user.
As well as the pain points
The most important pain point we discovered was that the app was made to allow people to connect wherever they where at that moment in time, but that because individuals had to request to be friends before they could message the concept became redundant.
Our team then built a short survey designed to efficiently sort responders’ as either relevant or irrelevant to interview. We posted our survey on as many social media platforms as we could (Facebook, Slack, Instagram, Linkedin and Reddit) as well as emailing our personal contacts; hoping to cast as wide a net as possible. The results were somewhat successful garnering us 51 responses from which we were able to pick out 16 candidates whom we thought were appropriate to interview. We made a decision here to spend more time interviewing a smaller number of relevant users rather than interview more irrelevant users. Below is a picture of some of the stats from our survey:
From here we were ready to begin interviewing our vetted users. We conducted 16 user interviews on users of various different age groups who had been filtered through our screener survey. We asked a range of different questions from which we were trying to ascertain.
- Why users networked?
- How they networked both online and in person?
- What they felt about networking online and in person?
- What online networking platforms they used?
- What tips and tricks they could offer other users who wanted to network successfully?
- How networking might be improved both online and offline?
One thing I find helpful is changing the script after every interview because the process of interviewing helps me write better interview scripts.
We found 10 themes that resonated across our users but after some discussion established three as most pertinent
Non professional interests
“I like to know their interests & hobbies like that. It’s a very easy thing to talk about.”
“I like to find common ground that is not related to business really — similar interests or someone who is similar to you.”
“Facebook has a lot of unique groups that I like, I like seeing people that are members of these unique groups and connecting based on stuff like that.”
“I would say the main criteria is that it went smoothly and that it felt natural, and that both parties are aware of the intentions of the opposite party in the conversation.”
“I like to know who the person is and what their motivation is, I don’t want salespeople.”
“If the intent of the meeting was shared or explained in the message, there should have been a prompt in the app to set an intent.”
Informal/ Dated Conventions:
“The best app for me would tell me that I need to meet someone or be part of a greater network rather than me having to search for someone.”
“All apps related to business are ‘cloggy’ they are trying to be too formal and not user friendly.”
“LinkedIn strips away the character. I judge people based on the companies they work for but you can still get interesting people at boring companies.”
Now that we had understood the major themes surrounding networking and who are users were; we were able to create personas to design for. We created three personas initially and then settled on two believing that together they represented a wider variety of our user base. Meet Ollie and lily
After much deliberation over the assumptions we had made in creating our personas we decided to use the ‘Jobs to be Done’ (JTBD) framework alongside the personas to ensure that our design problems were pertinent. The argument is that focusing on the user represents the wrong unit of analysis for the designer to focus on; rather the designer should focus on what the job is that the user is trying to achieve. Find out more about the JTBD framework here.
JTBD helps designers understand that customers don’t buy products but rather rent solutions to solve specific problems.
Writing JTBD statements works as follows
the Job stories we wrote eventually became our design problems.
When I’m at a networking event, I want to see who is around me that may have a similar interest to me; so that I can make sure we meet.
When I’m in a social setting where I want to meet someone in the room, I want to make sure that the person I want to connect with is open to having a discussion with me.
We decided to do some card sorting as a result of the negative comments we received on the organisation and discoverability of the 400+ groups that Causr used. We did this by selecting 100 groups at random and getting users who passed our survey to sort them into categories.
In analysing all the findings from the card sorts we realised that there was two overarching groups; ‘Companies’ on the one hand and ‘Social Communities’ on the other. We then used Linkedin to guide our design for the companies category which was effective because Causr had already been pulling user groups from Linkedin upon sign in. Upon further analysis we decided that in order for the Social Communities category to be effectively organised, Causr should allow users to create and moderate groups.