Alec Mountain

Alec Mountain is an internet entrepreneur based out of Bellevue, WA. His work specializes in marketing and product development.

Sosha_designProcess.png

 

Introduction

Final designs are fun to look at in a portfolio, but what actually influencers their design? Do we start with the final designs? Any experienced designer or product person today would say no. Instead, whenever I start a new endeavor today, I begin with the end user is mind. I'm not creating for myself, but rather for the customer because they are going to be one who contributes to the success of my product. With that, my definite goal is to create something for them that is useful, usable, and delightful. Otherwise in most ways I can't compete, at least in the midst of the social app craze. In this section, I'll give you an overview of my design process for the Sosha, so you can have a feel for how I approach problems and create solutions through technology. Enjoy! 

 

Starting With the Problem & Creating a Value Proposition

When the idea of Sosha came up, my co-founder and I got extremely excited. Our immediate thoughts consisted of thinking this was the next big thing and that we were going to essentially reinvent the way people hangout and meet each other. Though at this point, it was important for us to initially define the problem that existed, so it could be clear in both of our minds the issue we were trying to solve. This would impact the trajectory of the product roadmap and who we would market to. 

The 'problem' was basically this: There's no decent tools out there that allow you to openly browse fun activities to do and people to hang out with relative to your own location & interests in a way that's very simple and intuitive. Where I grow up (the Seattle area), in my own experience it's generally been difficult to make friends outside of my own social networks. These being real friends who I share common interests with, mostly in the form of doing activities. The idea of creating a tool that allowed me to make new friends relative to my own location who also liked the same stuff I did sounded very appealing to myself and my co-founder. Our initial assumptions about why this was a good idea led to us creating a first-take at a value proposition for our new potential product. 

Our initial value proposition was this: Sosha allows you to openly and easily find new people to hang out with nearby who share common interests and intentions. From the beginning we had ideas about certain features that would bring this value proposition to life, but for now it was important to simply lay out the problem and give an initial hypothesis of what it would look like from a value standpoint. 

 

Identifying Potential Customers

The next question to ask was, "Who specifically resonates with this problem and would find value in our solution?" Everyone obviously! Jokes aside, at this stage it was important for to zero in on who would find interest in our product. At the beginning we did think that most people looking to grow their social networks would resonate with this problem, but after careful consideration it made more sense to identify a more-niche group of people. Who has the most trouble making friends? What period of their life are they in and what are their motivations and needs? 

As a starting point, we thought people aged 18-25 who struggled to expand their social networks made the most sense. These people would most likely fall under the demographic of college student or recent grad. At this point we were really hypothesizing with feature sets and as ideas got traction through research, we could be more specific about our customer at a later date. For now though, this was a good beginning point. 

 

Creating Provisional Personas

The idea of creating provisional (hypothesized) personas is a good idea in our case because it gives an empathetic sense of the end user's needs, goals, and motivations. It would also give us a starting point for the validation process. Below are a couple examples of provisional personas based on our initial assumptions of who Sosha users might be: 

 

matt_persona.png
 
scott_persona.png
 

While creating provisional personas, it became quite obvious that we had intended to create was a broad solution for a diverse amount of people, both in their lifestyle and overall intentions. Matt is an introverted college student who wants to make friends during his first year at college and possibly get a girlfriend in the process. Scott on the other hand is a recent college graduate who has more specific intentions on who he wants to meet. Matt needs a better way to connect with people in general since he's not as outgoing, while Scott is more extroverted and needs a tool to help him find specific people he wants to meet up with. This is by no means negative, but just shows that the solution we hypothesized could potentially attract a user base of very different people who had differing goals and needs. Mike and Scott might not be ideal friends, but as long as each of them find people they're looking for, the solution would be valuable to them. 

 

Initial Customer Interviews & Validating the Problem

After creating those provisional personas, it was now time to prove whether our problem actually existed and if our hypothesized customers actually related to that problem. To do so, we decided that conducting customer interviews would be a lean approach to verifying what we needed regarding our new, potential product. This how a typical UX interview would have gone: 

  • A screener question to see if they would have the slightest potential to be a customer of mine to weed out the wrong people.

  • A few questions outlining the problem I hypothesized and see if my interviewee relates to it. This is to set up context for my solution.

  • Questions regarding their thoughts on my value proposition and what they think of some potential features I had in mind.

As I went through this learning process of conducting proper interviews, my questions would periodically change for the better, but here's an example a series of questions asked in an interview:

  1. Would you use a new app that allowed you the opportunity to meet people nearby who shared the same social interests and intentions as you?

  2. Do you wish there was an easier way to meet like-minded people relative to your own location who liked doing the same things as you?

  3. What current problems are you facing and what solutions are you using to solve those problems? If they were currently using a specific solution, I would ask them what they like and dislike about it.

  4. What do you think of an app that allowed you openly and easily find new people to hang out with who had similar interests and intentions?

  5. How does a feature sound that allows you to openly post what you want to do and have nearby people join?

  6. What about a feature that shows you a feed of people nearby who have the same interests activity wise who you can openly chat with?

  7. Is there anything else that you think we are missing?

This is how a typical conversation went when validating the product initially. If they wouldn't use an app to meet new people, they obviously weren't who we were going for. After they passed that screener question, it was all about seeing if they relate to the problem and if they shared a mutual understanding with us. If they did, then our potential solution was proposed to them with some features we thought of. The reason we proposed features so early is because an app that 'allows you to openly and easily find new people to hang out with' does not sound unique and in order to see if we were on to something, we wanted to propose what would make us different from everything else and get reactions based on that. 

Here is some important feedback we got: 

  • Safety is important. People want to feel safe using the app and not have their exact location exposed with proximity being an important part of our concept and value proposition.

  • Having the app focused on doing real activities was a good idea. Making friends of the same gender online can be awkward (amidst of all the dating apps), so having it focused on doing real activities makes it more inviting.

  • Along with the above point, the openness to browse people and activities made sense. Instead of the typical 'swipe-to-reject' model of most dating apps who's interface makes finding friends awkward because it's so common with dating.

  • The idea of openly posting what you wanted to do not only new people, but your own friends was something new that hadn't previously been thought of. From a marketing standpoint, this would also be beneficial because those not necessarily looking to meet new people could still find value in the app, based on their ability to more easily communicate with just their friends.

  • For organizing activities, scheduling was important and keeping track of everything you're involved in.

From the initial reactions we got from our idea, we knew we were on to something and that this problem was not just unique to us. Even better, our ideas on a solution were well-received, so we decided to keep moving forward. 

 

Competitive Research

While creating Sosha, competitive research was an important part of the design process, since it was important to identify what was already out there, so that way when we brought it to market, it was truly something unique that brought value to users where there was none before. Also, it was just a good idea to see what we were up against in general and see how much opportunity there was amidst of all the other competitors who had similar value propositions or intentions for users. 

Examples of what we analyzed in both our indirect and direct competitors were: 

  • The value proposition

  • The amount of funding the company had

  • How many users the solution had

  • The revenue streams

  • The main features that the solution offered

  • How usable the solutions were in general and how they looked & performed from a UX standpoint

  • The competitive advantage that each company claimed they had or in other words the unique features they advertised

This amount of information that we collected and analyzed here would really identify the landscape of other social apps both in their popularity and what they offered that helped people solve a similar problem to ours. There were other important factors that proved to be important as well since how they were making money (if any) and how much funding these companies were given to compete and win the marketplace. 

Here are some competitors found from our research that would be closely competing with us:

  • Meetup.com: A web and mobile app that allows you to find and meet new people based on being able to search or organize a meet up based around almost any category in your area

  • Tinder Social: Similar to regular Tinder, but Tinder Social allows you to swipe in groups, rather than one-to-one.

  • Bumble BFF: Similar to regular Tinder and Bumble, but you can swipe people of the same gender who also want to make friends

There were other competitors that existed on our list, but none of them proved to be as big of a threat as the above three due to their low user bases and low brand-recognition. Meetup, Tinder, and Bumble are all examples of apps at the time that had large user bases and amounts of funding who wanted to help people nearby make new friends. 

 

Storyboarding Value Innovation & Creating An MVP Feature List  

Where did our value innovation lie? If we launched our product, what would make us the better solution compared to everything else that existed on the market? Our goal with Sosha was really to invent, so we had to look for the benefits in our product that would make it irresistible to users. We needed to point out the big moments as part of the user experience that showed incredible value. Since we already evaluated the marketplace based on the competitive research, we had insights into what we needed to create to stand out from the crowd. 

If anything, the competitive research verified that the unique features we talked about during our customer interviews were unique and didn't exist anywhere else. As a recap, this was the ability to openly post and plan activities you wanted to do and have anyone nearby join, as well as locate people with mutual activity interests with the option to instantly message them. However, the difficult part was identifying what to include in our minimum viable product (MVP) when we initially gave it to users. Having so many ideas, if we would have included everything, version 1.0 might as well been named version 5.0! For creating our MVP feature list, we needed to include the most important things the customer could do with our product that they couldn't do with anything else. We wanted to make a lean list of features, since I believe that more is less and it's important to initially get traction before further investing in a product. 

Here's a storyboard for Sosha that demonstrates the valuable moments of the customer journey that would really demonstrate uniqueness in our product. 

 

sosha_storyboard.png
 

By no means an accurate representation of what the finished product looks like, the main objective of this storyboard would be to capture the seamless experience of start to finish from having an idea of what to do this weekend to actually making it happen with others. The ability to quickly post anything around your area combined with a simple UI to schedule an activity with people was our unique value proposition that didn't exist anywhere else. 

Whether you were a hangout organizer or someone joining, the experience would be very similar, which is why there's not multiple storyboards. The organizer's role is to post the hangout, manage the details of it (if needed), and accept others to join. Those joining a hangout simply browse relevant hangouts in their area and click a button called 'ask to join' for those they are interested in. After the organizer accepts people, they are put in essentially the same UI to communicate back and forth. 

Outside of the ability to organize and join hangouts nearby, we also chose to have the following functions be part of our MVP:

  • A place to keep track of all the hangouts you've either organized or have joined

  • User profiles

  • The ability to add friends

  • Posting and organizing hangouts with just your friends

  • A discovery feature to browse people nearby with similar activity interests

It may seem ironic that I discuss the need to just include the key experiences as part of the MVP and there's a long feature set, but after considerable evaluation with my team, it felt needed to include all of those features to demonstrate the value we wanted with our product. Our budget for the project also permitted it, so we decided to move forward with that spec. 

 

Creating a Sitemap

 Before the wire framing stage began for the app, in our case we decided it was important to know what pages would exist. This would also give a clear picture of the navigational hierarchy and get a glimpse of the overall depth of the app. During the design process, the sitemap changed as our first attempt obviously wasn't final. However, when a final design was agreed upon, we felt really good about the outcome. You can see it below. 

 

Sosha_sitemap.png
 

Though the sitemap may look daunting at first, the intention was to create a very clean and easy-to-use interface from an interaction standpoint. And it achieves that goal since most actions don't take more than three taps, with the majority taking two taps. At the bottom of the phone screen there are five buttons with functionality regarding creating and managing hangouts & people. At the top is the Sosha logo, which presents the option to manage your profile, settings, or your squad members (friends) through a drop down menu. The interaction design should visually make more sense when the wireframes and user flows are presented down below. 

 

Wireframes and User Flows

With a sitemap put together and an idea of the most important features we wanted to include, I designed wireframes and user flows for Sosha. Along with the screens themselves, I also wrote a short description of what each screen does, so the viewer can mentally put all the pieces of the app together. In the user flows, I don't explain every single part of the app (although it may look like it), but rather the most important interactions. And although a particular button may appear several times over the series of screens, I won't showcase what screen it goes to every single time just for simplicity sake. Or else my flows would look like a redundant, giant spiderweb. Instead, it's interaction outcome will only be shown once on most occasions.

Also keep in mind that the bulk of all interactions are made across the five main buttons at the bottom of most screens. Enjoy!  

 

 

sosha_flows2.png

Prototyping

After designing the wireframes user flows, at this stage it made sense to start creating an actual product in the form of a prototype. With most of the wireframes and user flows being finished as shown above, all that was really needed was adding visual aesthetic and linking them together using prototyping software. This was done using industry-standard tools Sketch and Invision. 

Linked below is one of the final design iterations of the Sosha app in the form of a prototype. 

 
 
 

Off-Shore Development and User Testing

To get the product actually built and usable, we outsourced development to Nepal through a connection we had. When Sosha actually became usable with a proper working front-end and back-end, it was put into a beta test with friends and family. This was really great for us because having a group of usability testers was extremely important in making sure we had a functional product that did essentially everything the prototype (above) did. With every new beta release, we would constantly test for new bugs and then I would work with the developers to point out new issues. Though working with developers on the other side of the world was by no means easy, I made it work for the time that it lasted. 

 

Aftermath and Lessons Learned

I'm not going to go into detail, but there was an issue involving one of the parties handling the development process and we were forced to abandon the project. This was around the time that the product was almost fully built and ready to be shipped. It was a shame because we had spent so much time working on a project that was so important to us, only to see it never reach its potential in attracting a user base. 

However, there was a lot of positive that came out the process. I credit Sosha as being responsible for my passion in UX design today and if it weren't for this project, this website probably would not exist. That's because after Sosha ended, I continued to design more & more things because I loved creating apps. And that's what led me to creating a website to showcase my work. And although I'm not going to say the design process of Sosha was perfect, in what I wrote above on this page, there was so much learning involved in the process of understanding who your customer is and trying to create something valuable for them through a killer UX and value proposition. Thanks for taking the time to read about the Sosha design process and hopefully you have a better idea of how I work as a designer.