Trevor Jon Waldorf

VR & Product

Exposing Networks

Upknown: Interaction Design

Table of contents



Talented people struggle to find roles at companies and companies struggle to find talented people.

My Role

I joined Upknown to help establish an initial UI, design email-to-app interactions, develop a visual brand for raising a seed round, and help with onboarding.


We made good progress solving user pains and providing value, but there are more stakeholders involved in products than just users. This case study focuses on three areas: new user onboarding, understanding user-to-candidate relationships, and email interactions.

Read on below. ⤵

The Problem

Talented people struggle to find roles at companies and companies struggle to find talented people. Highly-networked individuals across all industries meet talented people and know companies searching for talent. Although these individuals do their best to make matches, the process is time-consuming, inefficient, and subject to a recency effect.

A Satisficing Solution

Interviews revealed a common manual system for making matches between companies and talent. Highly-networked people maintain a list of candidates in their network which they hopefully remember to update every time they receive an intro email. As opportunities flow in through email, Linkedin, network job listings, and private recruiting newsletters, they hopefully find something that matches a recent spreadsheet cell of talent.

Figure 1: Core Upknown Use Case

The Upknown Solution

A web app that allows highly-networked individuals to index candidates in a searchable stream without leaving their inbox. The stream is distributed through regular emails to anyone who follows the individual. Candidate profiles include the attached resume, automagically generated tags like #ios #mobile #dev, and information pulled from FullContact and Linkedin, including a profile image, current title, role, etc.

The Team

Luke and Danny headed the company with Alex and I working on product. Luke is a seasoned entrepreneur with deep experience building Ecoproducts. Danny and Alex were and are good friends and are now at Pana and Twitter, respectively (as of 2017).

Diagnostic Research

We had a constant supply of user feedback and potential users at our fingertips thanks to Luke’s interviews, making it easier to evaluate which user problems were being solved and where our solutions were falling flat.

By talking with users, we determined that there was confusion around the nature of adding candidates to Upknown. Was it an endorsement of the candidate’s skills? Or just a resume blast? What about people they want to keep track of but don’t know personally?

By looking at user behavior, we saw that most people didn't take the time to log into the app every time they forward a candidate into the system. We needed to re-think the email forwarding flow, and beef up the way that people interact with Upknown in their inboxes.

Design Process

After user interviews we discussed and prioritized user needs as a team, brainstormed flows and collected use cases, then settled on a single flow to build out. Based on those activities I built a clickable prototype in InVision, made tweaks based on feedback, and did a rough implementation. Danny came through afterwards to unscramble my implementation and ship the branch.

I would have jammed in a week to focus on testing the onboarding–it would have made the product significantly better despite other sacrifices. However, the reality of early-stage software is that money and target users reward some activities (shipping ASAP) over others (testing work). Looking back, the best design strategy would have been to use small artifacts representative of what we were building to test our most dangerous assumptions. Hindsight is 20/20.

Focus: Onboarding Users

Upknown is a complex application that interacts with the user both through emails and through a web application interface. The switch between app and inbox is jarring: When people are in their inbox, they are trying as hard as possible to stay in their inbox.

Onboarding was a thorn in our sides because we were constantly iterating on the core user flow and shipping large changes to the product. After building a few approaches over a few months, we decided it was best to keep people in the app through the onboarding and recreate the experience of adding a candidate to Upknown.

Figure 2: The onboarding flow mimics the inbox-to-web app interaction to introduce the uncommon pattern.

Unfortunately, there was a lot of guesswork and hypotheses we never tested. Here are a few of the flows we played with, before settling on the Walkthrough flow based on feedback.

Focus: Describing User-to-Candidate Relationships

Universally, early users felt it was unclear what it meant socially when they added a candidate to Upknown from their inboxes. Were they endorsing this person? Even the users who used the system more for indexing candidates as opposed to sharing their candidates said they would like to indicate the strength of a connection.

Figure 3: Establishing relationship strength using the wifi signal

The Wi-fi symbol does just that–indicate the strength of a connection. At the time we were looking at Conspire’s product (which we felt did a lot right and but also maybe did some things wrong) and copied a move from their design playbook: using the wi-fi signal to indicate the strength of a connection between people. When you pair it with a prompt like “how well do you know this person?” it lends significant context to auxiliary testimonials that further describe the nature of the user-to-candidate relationship.

Figure 4: Relationship Strength in full effect

Focus: Rethinking Emails

Problem: Users weren’t confirming their candidates in the app or fixing glaring problems with the way Upknown scraped candidate information.

Figure 5.1: Confirmation emails allow users to populate their stream without leaving their inbox

For example, if Upknown thought a candidate’s name was the first two words of the subject line of the email, the user should know before it is added to their stream and be prompted to fix any errors. It needed to be easier to confirm candidates and correct information from the inbox.

In order to test as soon as possible, Danny built out a barebones version of the email system, I added some css margins, and we collected feedback around the unstyled emails. I then pushed the emails to their final state.

Figure 5.2: Email as an interface in action

Side note: coding emails is 4x time intensive as other front-end work due to the security risks involved in viewing emails. Email clients display a small, varying set of style rules and toss the rest while mangling your code. We used a Ruby mailcatcher to preview emails as they are sent, an inline css compiler with some custom tweaks, and I used an Etsy email template to make Gmail viewing awesome, along with Mailchimp templates for responsiveness on the iOS mail app, and a bunch of custom work for Outlook + Yahoo + Gmail mobile app. Testing takes a lot of patience, even with EmailOnAcid or Litmus.

What I Learned

In the end, the product was sidelined the product after six months of work. Sometimes economics and timelines don’t work out despite having solutions to clear user pain points. You take what you learn from the experience to build better next time.

I learned a lot about organizing and prioritizing product design work. There is a constant interplay between making big-picture decisions and designing critical details, and balancing those two modes takes intentionality.

Working closely with Danny and Luke also made me question what values I bring to the table when designing products. What is best for the users isn’t always best for the product overall due to the needs of other stakeholders. Just because Danny is a badass and we could ship features every day doesn’t mean we should, but at the same time, nimble design and development is a valuable asset.

A handful of users still use Upknown to track candidates and match them with jobs in their network (tracking jobs manually). But on the development side, the project is private on Github, closed to new user accounts.

Trevor Jon Waldorf

VR & Product