Client Project: Causr
In our final project at General Assembly (GA) a group of three of us were tasked with working with our first real-life client; an application called Causr. The application already existed for IOS and was planning to launch for Android later that year.
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:
- Business travellers
- Alumni networks
- 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 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.
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.
Working individually with the app downloaded on each of our phones we managed to conduct 10 user tests based around three testing scripts we had designed. Users highlighted a multitude of issues with the app including but not limited to the on-boarding journey. It was definitely true that users did not understand the purpose of the app as well what the first time user flow was, somewhat indicative of an under par on-boarding process.
“I don’t get it. How does proximity and location fit together?”
User profiles and what information is displayed came up as well:
“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 all 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 very helpful is to change my script as a result of every interview because the process of interviewing allows me to write better interview scripts.
Carefully selecting all the quotes we deemed important from our user interviews we set out to affinity map for themes. We conducted the affinity mapping process three times before we were content with the themes that had emerged.
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 & 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. (http://sloanreview.mit.edu/article/understanding-your-customer-isnt-enough/)
JTBD helps designers understand that customers don’t buy products but rather rent solutions to solve specific problems.
Writing JTBD statements works as follows:
Here are the Job stories we wrote that 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.
We then took the Job Stories that we had created and set off to the clients’ offices to conduct a design studio. We took everything that we had learned from the discover and define phases of the Double Diamond model that we had implemented and presented it to our clients so that they understood what we had learned; and we could ideate for solutions together. We came out of the design studio with plenty of ideas and a renewed sense of purpose. The following day the three of us got together and discussed all the solutions that came out of design studio.
We had a lot of ideas and we needed a way to sort them and so decided to do some content & feature prioritisation to help us decide what would be most useful.
After our feature & content prioritisation and with the solutions from design studio in mind we decided to go with a solution where users would spend a little more time adding to their profile to provide more context around who they were as well as what kind of person they wanted to meet. We did this by designing a system whereby the user would indicate their intent on the app, i.e: ‘here to hire’ or ‘here to get a job’ etc..
We would then have the user answer questions from an unlimited list (used so that the app could constantly learn about them) that they could exit whenever they wished. The format is that the user would answer a question and then input the answer that their ideal networking partner would select. We were left with the inputs from API’s that we had decided to use which were an import of Facebook groups and those from Linkedin. I then designed a simple algorithm to bring this all together and create a match percentage between two users. The visual below explains how it would work:
We knew what our users wanted and what was wrong with the existing app and so where ready to set our design principles. We discussed this and selected the following:
- Inclusive: an app built for everyone.
- Usable: an app that was easy to use.
- Useful: an app that added value to the users life.
Initial User Flow and Wire-framing
We were now finally ready to begin creating our own user flow and wire-frame our solution.
Testing and modelling:
We conducted one round of user testing and then redrew our prototype ironing out any and all issues our testers had highlighted.
We then ran another round of testing which was positive; so allowing us to move to digital prototyping. We tested our first digital prototype but the testing did not go well; our testers were complaining about our flow. At this stage we were feeling pretty disheartened by the feedback. I then decided to try and tackle the problem of our user flow by modelling various different flows in queue cards on the floor of my apartment in order to work through a bunch of flows and find the most appropriate one. For this I attempted to visualise what the user would go through and find the most appropriate one:
I picked two which I thought were the best and wire framed them by hand — then tested them with several people in order to come up with the best possible flow.
We then went through various rounds of testing and redesigning making sure that we ironed out all of our interface and usability issues.
Below are the iterations on our home page:
Below are iterations of the profile page we designed:
We didn’t change much of the visual design of the app as we wanted to maintain the style and brand that the team at Causr had already created. We did however add some colours and change the typography which some of our users felt a little unprofessional:
Finally we created a working prototype which you can check out: here
Thanks for taking the time to read about my first client project and as always please feel free to drop me a line or comment and highlight everywhere and anywhere you might want to.