Published on | Prototyping: From UX to Front End — Medium Svilen

InGo is a social third-party platform that organically grows events by empowering attendees to invite their friends and colleagues while lowering the attendee acquisition costs for event organizers.

I joined InGo as the the lead UX designer and the 6th employee in December of 2013, and departed in January of 2015. I was in charge of the product and user experience but as most early stage startups, I designed UIs, websites, reports, social media content, and other graphic collateral.

InGo’s offering comes in the form of widgets which provides value to attendees by:

Enabling fast and easy event registration.
Displaying other attendees, including contacts who are attending.
Suggesting contacts that may be interested in attending.

The Problem

The state of the widgets were slightly above proof of concept and were not ready to be scaled due to poor experience and usability. The widgets lived on registration companies’ websites, which posed a big challenge as we didn’t have full control of the experience.

The Goals

Design the attendee experience (widgets)
Show results and insights to organizers about their event and audience (analytics platform)

1. Design the Attendee Experience

The Login Widget

The Social Sign On Problem

InGo’s value is predicated on attendees signing on socially and authorizing access to their contacts before it can make smart recommendations. However, very few users were doing so at the time, which was a huge problem, as not just the attendee experience, but the very business model of the company was based on social sign ons.

The Process

Although there were many external factors, I started by analyzing the widget itself, which looked like this before I joined:

Legacy Login Widget

I placed myself in the attendee’s shoes, it became clear there were no stated benefits as to why register socially. How am I supposed to know that it will save me time or that I could find out if any of my friends are attending? All the persuasive copy was hidden behind the “Tell me more” button.

With my hypothesis in mind, I made the following decisions:

Removed the “Tell me more” button and added copy explaining the benefits of social registration up front.
Addressed privacy concerns by providing the option to opt out of sharing your attendance publicly and auto-posting on your behalf
Visually de-emphasized the manual registration- moving button to bottom (version A, B) or signaling hassle up front in hopes of swaying people away (version C)

As I kept incorporating customer feedback, the copy become more succinct, and the widget was refined stylistically, we saw social adoption take off instantly.

Login Widget on an event page

Levering Psychology

I started experimenting with applying psychology principles to further entice attendees to register socially. I featured the top 5 most influential attendees of the week on the Login Widget not just for social proof but as a clever growth catalyst; those featured would get an email congratulating them, with a call to action to share their accomplishment and thus increasing awareness. Unfortunately, I wasn’t able to test this iteration’s performance live during my stay.

Social Widget

Once an attendee has socially signed on and completed the registration process, they encounter the Social Widget which provides 3 functionalities:

Invite– allows the attendee to invite relevant contacts
Who’s In– shows if attendee’s contacts are attending, along with everyone who registered through InGo and chose to be discoverable.
Share– allows attendees to share their attendance on social networks.

Challenges

The widget wasn’t fully built, but there were legacy designs in place which were confusing.:

Given that the width of the widget couldn’t exceed 300px, it was very busy visually, avatars were small, text was crammed, and there were too many calls to action.

The Process

Each functionality was complicated as is, let alone all 3 living under the same widget. I separated each functionality into its own tab in order to simplify a user’s mental model, and to add flexibility when implementing.

I made the following design decisions:

I enlarged the images of the attendees as they are the most attention grabbing elements
spaced out the elements to give them some breathing room
reduced the functionality to by shifting suggestion up top
reduced visual pollution: there were way too many horizontal lines which made it hard to visually grasp elements

Many iterations later, a more refined and simplified design began emerging that was stylistically in synch with the Login Widget:

Testing

I created prototypes as I went along and ran mini-workshops where I asked members to perform certain tasks and collected feedback.

I eventually also got around to designing an expanded version of the social widget, since confirmation pages provided more screen real estate:

Asking for Permission

When attendees registered manually, we still needed to obtain permission to their social network before InGo could work its magic.

In order to make sense of it all, I mapped out the logic behind permissions:

Timing was critical- ask for permission out of context and a user will likely decline it. The legacy interaction asked for all 3 permissions initially which resulted in poor conversions. Using strategic timing, I was able to obtain much higher acceptance rates: for example, asking permission to post on a user’s timeline only when they’re at the share screen, as any other time wouldn’t make sense contextually and might scare off the user.

I mapped out the permission prompts on a user journey to determine the best time to ask users for each permission:

I also mapped out the process behind the major registration platforms to inform my decisions:

InGo’s Platform

The platform is a way to show InGo’s value to event organizers by providing them with realtime, actionable social analytics, and insight to their event and audience. It could also provide exhibitors with the ability to capture and analyze sales leads.

The Problem

As InGo evolved, so did the reporting needs from its clients. We were collecting great info on attendees and event performance, but didn’t have a rich way of serving it to our customers. I designed a PDF report which was generated manually after every event, but it was time that we increased the reporting fidelity and automation.

Design Process

I started working from the top down- first I designed an “event snapshot” which nicely summarizes the results of the event in a way that is easy to digest:

Organizers could also learn about their most influential attendees with metrics like: number of contacts, impressions served, invites sent, posts shared and converts.

I sketched out the initial product features with wireframes, ran internal workshops for feedback before arriving at initial designs:

Social Emails

We used emails for notifications and to trigger further social interaction outside of InGo’s widgets. Once again, I tried to use principles like social proof to entice attendees to participate socially. I tried to keep it minimal by emphasized the event banner, the profile pictures of the attendees and calls to action buttons. Here are some designs:

Results

“You can’t improve that which you can’t measure”

One of my biggest mistakes was not quantifying results often, as the blatantly obvious success made me content . InGo saw obvious improvements across the board, from social sign on conversions, to invites and posts, which I wish I would’ve kept track of since day 1. Here are the KPIs we measured internally the month before my departure.

11.88% Advocates (attendees who signed on socially / total attendees)

9.8% Acquisitions (attendees acquired through InGo / total attendees)

248.14% Invitations (sent through InGo / Advocates)

40.84% Posts (posted through InGo / Advocates)

By very conservative measures, every single metric has at least doubled, in some cases tripled during my stay at InGo.

Lessons & Mistakes

InGo was one of the biggest learning experience in my career. Perhaps the biggest lesson was the value of planning and pre-planning. Many so called mistakes were due to lack of experience, underdeveloped design sensibility and lack of fore planning. Here are my top 3:

Not testing often– there was a Social Widget iteration I shipped without running it by users. The number of complaints skyrocketed due to the lack of button affordability. It was a valuable lesson which led me to form a select customer group to test designs before releasing.
Not enough research early on– “If I had 6 hours to cut down a tree, I’d spend the first 4 sharpening my axe” -the quote sums up my newfound stance on research very early in the process.
Poor interaction of “Who’s In”– It burdens the users to work for information, by hovering from photo to photo as they learn who’s attending. Photos by themselves don’t tell users important info like name, role or company, which should’ve been always visible.

Other Work

A methodology document explaining InGo’s integration with Facebook’s API:

Testimonials

Case Study: InGo —Social Event Marketing was originally published in Prototyping: From UX to Front End on Medium, where people are continuing the conversation by highlighting and responding to this story.

Case Study: InGo —Social Event Marketing

Cool stuff, every week

More Articles