Project Four

Project four was about executing a passion project. My teammates, Pankhuri, Gigi, and I ran into trouble coming to a consensus for a problem we’re all excited about solving. We attempted to start with an area of interest that we all agreed on “Local Markets”. Although we came up with four potential problems we could solve for brands like Brooklyn Night Bazaar, Queens Night Market, and Union Square Farmer’s Market, we decided to start over from scratch. Pankhuri suggested an interesting mind-mapping technique where we wrote topics we were interested in and randomly paired them to create a problem statement. Some examples were “simplicity and history” which became a photo app that would research the history of architecture a user photographs. Later we came up with “gamifying sustainability” and “creative space reclamation.”. Pankhuri and I discussed the importance of spending time in the ideation phase. Great apps come from ideas that are innovative and fun. They also come from passion and deep desire to create something meaningful. Our biggest roadblock was consensus.

Our whiteboarding attempt at finding inspiration/consensus.

When we finally got the green light to move forward with our project. We decided that we wanted to expand the audience of a popular dating service company by creating a professional networking app with the same branding. We saw an opportunity in this area because our brand was the leading provider of one-on-one relationship matchmaking, but had no solution for users that wanted to climb their professional ranks. We also thought that changing the vibe of professional networking could benefit the users because, their competitors (LinkedIn, and Meetup) are just not fun.

We came up with series of survey and interview questions that asked users about their online dating behaviors and their professional networking behaviors. We sought out information about their experiences and attitudes towards starting conversations on both platforms. Our hunch is that users have a hard time starting conversations in professional networking environments and our could app assist by having a feature that would help spark conversation based on users shared interests. This app would provide relevant talking point which will lower the users inhibitions from speaking in real life. We came up with the concept of conversation “boiler plates”. A feature that gave users a template for engaging in messages based on the info users provided in their bio.

We synthesized our interview data. We created an affinity map out of our in person interview results. There were two popular trends in our results. networking, and people have a hard time making connections on dating apps like Tinder. Users also tend to spend time on both sites browsing through profiles without actually reaching out to users. We decided that we would make two types of personas based on our findings. Our first persona was based on a proactive user. Someone that uses professional networking apps to actually research people in their field, reach out to them, and meet up in person. We decided that this person would benefit from an ability to generate new contacts, and set follow-up emails. Our second persona was someone that we deemed “lurker”. They generally just use these apps to look around at profiles. They join communities without actually posting or commenting.. Our interview results said that they had a hard time starting conversations. We decided that this type of user would benefit the most from the “boilerplate”.

Developing our personas.

We had the opportunity to talk to an engineer about the feasibility of our project. We ran into a huge roadblock with our “boilerplate” idea. Although it is sortof possible, it would require a lot on work to build a product that is able to handle language recognition and creation that would make our “boiler plate work”. We could do a list of key terms manually, but the amount of bandwidth it would consume would take too much from us getting our product out the door. In terms of MVP, our boilerplate would be a feature that could wait for later iterations, after launch. So we have to pivot our focus to chat capabilities, and event creation.

We tested our prototype and discovered that many users had issues with our readability, and clarity of our application. Some folks mentioned that our color scheme needed more contrast. It was a mistake to make buttons the same color as the overall app background. In our synthesis we focused on our apps clarity. We decided that we needed to revamp the way we organized our calls to action. We decided to consistently make actionable interactions the same color, orange. We also decided that we would keep buttons as close as possible to their relevant text.

Testing our first iteration.

One improvement was with our “Set conversation reminder” feature. This feature was implemented so our users could track conversations that they started –and be reminded to return to them later. Since this was a totally new thing, our users didn’t have a mental model for it yet. We thought it would make sense to use a alarm clock reminder, but for something innovative, and no prior context, we needed to make it as direct and to the point as possible. So we changed our visual representation from icon, to word “set reminder”.

On “Set Chat Reminder”: How do we create a feature for which users have no mental model?

Our other features were pretty intuitive since most of our users are used to messaging and joining/creating events on other platforms. We thought we were in the clear but boy were we wrong. When it came time to present our product we found that there were a lot of higher level points that we were missing. For instance our product’s login process requires that users sign up via Match.com or email account. Our “client” pointed out that they would much rather “try before they buy”, meaning that we should give the user a taste of the applications functionality before forcing them to commit to signing up. We had never considered this in our user flow before, and it makes total sense. I’d feel more trusting in a product if I could see the inside before I gave them my data.

Boilerplates: spend more time on the special sauce.

Other takeaways that we received were in our framing our product in a way that was distinctly unique. Our presentation lacked a “special sauce” that readily persuaded our audience of it’s necessity. I think a large of this was in part of pivot. We had completely backlogged the idea of boilerplates in favor of using our time elsewhere. We were told some very wise advice: Sometimes it’s better to spend more time on the feature upfront that will set your product apart from others. Shipping a unique idea should take precedent over a safe/functional product. Reflecting on this, I know that I would center our “boiler plate” idea as the crux of our area of opportunity/pitch and design workflow. Good ideas are totally possible and can be done, but great ideas take a lot of time and work to execute.