Hans van de Bruggen

Product Design // NYC

LinkedIn Endorsements

Overview

When I joined LinkedIn, we had a number of good data-driven products, but relatively poor MAU. For many of these products, their value was directly related to user engagement. A "One-click Endorsements" feature was proposed to help increase engagement for the site. For Endorsements to be successful, we knew we had to create a viral loop where one user could easily re-engage other users, who could in turn do the same.

To seed the viral flow, we looked for an entry point that had a lot of traffic. The user profile of a 1st-degree connection was a good bet, both in terms of user intent and traffic volume. We created a callout at the top of the page with suggested endorsements and the ability for the user to type in their own. At the time, fewer than 1 in 10 users had added a Skills section to their profile, so it was important to be able to endorse users who had not yet taken the initiative. Ultimately, the connection would be given full control over whether or not they wanted to add a skill to their profile.

After endorsing their connection, the user is offered four other connections they can endorse. By allowing a user to continue their momentum, one engaged user was able to increase engagement for multiple users.

After an endorsement has been made, the connection receives an email. As the MAU for the site was low, this would be the first point of contact with Endorsements for most users. The email was designed to be direct—someone you know has endorsed you—and provide a clear CTA.

A number of variations of this email were A/B tested to maximize clickthrough rates. Ultimately, all of the variants we tested performed much better than average for the site. In general, qualitative data later confirmed, users liked getting these emails.

After clicking through from the email, one of two things happens. If there is an endorsement for a skill area not yet listed on their profile, the user is first asked if they would like to add it. Otherwise, they move forward and are prompted to endorse other connections. This closes the viral loop—an endorsed user receives an email, clicks to endorse other users, and the cycle continues.

The click rate for this feature was very high, with early numbers showing users endorsing 14 connections on average. People enjoyed reciprocating, and passing it on. Later, it was determined that Endorsements were directly responsible for increasing the usage of every other product on the site. It remains the fastest growing product in company history.

“…Endorsements allow members to easily recognize the skills of their colleagues. In just over four months since the launch of the service our members have generated nearly 1 billion endorsements.”

LinkedIn CEO Jeff Weiner (Q4 2012 Earnings Call)

Cureatr

Overview

When I joined Cureatr, the first question I was asked was how to improve the readability of the “Active” status. The status itself was lime green, and with a contrast ratio of 1.76:1, it was a far cry from the 4.5:1 recommended for WCAG 2.0 Level AA accessibility. Our users skewed older, with less-than-perfect eyesight, so meeting this standard became a top priority.

User feedback on a color had revealed a deeper usability problem. As sole designer for the company, I created a new style guide (nicknamed “Cascadia”), and established a set of design principles centered around clarity, verifiability, ergonomic speed, and privacy based on user feedback. This laid the foundation for full redesigns of our iOS, Android, Windows Phone, and Web apps.

These were exemplified in our Quick Messages feature. The existing version required 4 taps to send a message—one to open the options tray, one to choose the Quick Messages option, one to select a message, and one to send. The new redesign reduced this process to two taps—one to open Quick Messages, and one tap on the message to send. The list of Quick Messages could be scrolled so that the top message sits below the vertical halfway point, making it easier to use with one hand. These changes greatly improved the ergonomic speed of the feature.

HIPAA compliance meant that to protect a patient’s privacy, we could not reveal any message content to an unauthenticated user. This meant that any push notification would have only the sender’s name, but no information from the message itself. With the Quick Messages redesign, we added four new emoji replies at the start of the list: Okay, No, I’m not sure, and On my way. As these messages could not be modified by the user, they would never contain any private information. This allowed us to show previews for these Quick Messages on the lock screen, eliminating the need to unlock the device and enter a Cureatr passcode beforehand. This is an industry where seconds matter.

For the web app, we were faced with the additional challenge of supporting IE 8 on Windows XP at 1024x768 resolution. This meant putting a heavy focus on maximizing space for content, as well as keeping page performance as snappy as possible for the sake of older equipment. As our target user for the web app was desk-bound, we worked to make the product fully accessible via the keyboard, to reduce the friction of switching to the mouse mid-task. We also extended the app from a model that allowed for one task at a time (such as browsing a message list, viewing a conversation, or composing a new message) to one that allowed for multiple tasks to be performed simultaneously, which proved a better fit for users in a busy hospital environment.

“The product has come farther in the past 6 months than in the year before.”

Cureatr CEO Joseph Mayer

Pypestream

Overview

When I joined Pypestream, the existing information architecture model was hugely problematic. The model organized content via a system of “Pypes” (categories) and “Streams” (subcategories). Unfortunately, browsing all updates meant the user would have to navigate between each Stream one at a time, pogoing between them.

I introduced an updates feed to show content from all channels in one place. Updates across all Streams were aggregated onto one screen, which eliminated pogoing entirely. The feed also created a central location to feature more important messages, collect user satisfaction data, and cross-promote other app features and content.

Another high priority was improving discoverability of Pypes and content. In the existing model, the Explore tab provided a short list of hand-selected Pypes for users to connect with. To view any other Pypes, the user either had to encounter a link outside the app, or use search to look it up manually. My team knew we could do better.

We realized there would be a small handful of well-known brands that most people would recognize, and a long tail of content that needed to be easier to find. It struck me that the "app store" model was designed to solve exactly this problem. Furthermore, styling the feature as an app store aligned with our desire to position Pypestream as a provider of app-like functionality to businesses lacking the resources to build their own app.

Featured Pypes were still given high visibility, while the rest of the catalog was divided into categories to make discovery easier. We also introduced a “Pypes near you” feature which would show users Pypes in their area.

In parallel with the improvements to the Explore tab, we also increased discoverability by adding Pype recommendations to the main Updates feed, so that users would continue to encounter new content without needing to actively seek it out. All told, we offered substantially more avenues for discovery than with the existing approach.

With customer service as a central focus of Pypestream, I began to consider ways to better stratify and manage a high volume of incoming requests. There were early plans to let AI “handle it” with NLP, which to me seemed problematic. If Amazon, Apple, Google, and Facebook still struggle with getting AI right, what made us any different?

One of our greatest strengths was that each of our Pypes had a human operator. What if these human operators could trigger an automated flow that walks a user through the problem? Large enterprise customers would be able to translate their existing call center scripts into automated flows. Instead of relying on AI to route users correctly, we could use AI to augment the human operator's experience by suggesting the automated flow it believes is correct. Over time, this could be used to build training data—so that if the AI guessed correctly the vast majority of the time, it could be allowed to start the flow automatically.

Lastly, there was the problem of user reach. A broadcast sent to 500 people would be limited to those 500, as any content sent out would only be seen by people already electing to receive it. Instead, I proposed opening the walled garden to allow public sharing of Broadcast content, with each Broadcast having a sharable landing page. This increased the potential reach for content and allowed for virality. These pages would also be cataloged and categorized to improve SEO across the site.

From conversations with our users, we knew the big “A-ha!” moment came from their first conversation with a company over text. Compared to popular products like Facebook Messenger (which users likely had installed already), our product required the user to download the app and set up an account, which was a major friction point.

I proposed bringing this basic chat functionality to the mobile web. As installation was no longer required, users could have their first chat with the same amount of friction as competing tools, and removing the signup requirement meant we could expect a boost in MAU. The web chat would provide a user's first “A-ha!” moment with our product, and our app would further enhance their experience with push notifications, a user profile, and updates feed.

Making broadcasts public greatly extends their reach, improving discovery, and making basic chat available without requiring an account means many more users can quickly try our core feature.

“Yes—I want this yesterday!”

Pypestream EVP of Product and Technology Jatin Patel

Contact Hans

Let's build something great together.

Hans van de Bruggen
571-348-8192
 
View LinkedIn Profile
Hans van de Bruggen // Product Design Portfolio
Hans van de Bruggen

Product Design // NYC

LinkedIn Endorsements

Overview

When I joined LinkedIn, we had a number of good data-driven products, but relatively poor MAU. For many of these products, their value was directly related to user engagement. A "One-click Endorsements" feature was proposed to help increase engagement for the site. For Endorsements to be successful, we knew we had to create a viral loop where one user could easily re-engage other users, who could in turn do the same.

To seed the viral flow, we looked for an entry point that had a lot of traffic. The user profile of a 1st-degree connection was a good bet, both in terms of user intent and traffic volume. We created a callout at the top of the page with suggested endorsements and the ability for the user to type in their own. At the time, fewer than 1 in 10 users had added a Skills section to their profile, so it was important to be able to endorse users who had not yet taken the initiative. Ultimately, the connection would be given full control over whether or not they wanted to add a skill to their profile.

After endorsing their connection, the user is offered four other connections they can endorse. By allowing a user to continue their momentum, one engaged user was able to increase engagement for multiple users.

After an endorsement has been made, the connection receives an email. As the MAU for the site was low, this would be the first point of contact with Endorsements for most users. The email was designed to be direct—someone you know has endorsed you—and provide a clear CTA.

A number of variations of this email were A/B tested to maximize clickthrough rates. Ultimately, all of the variants we tested performed much better than average for the site. In general, qualitative data later confirmed, users liked getting these emails.

After clicking through from the email, one of two things happens. If there is an endorsement for a skill area not yet listed on their profile, the user is first asked if they would like to add it. Otherwise, they move forward and are prompted to endorse other connections. This closes the viral loop—an endorsed user receives an email, clicks to endorse other users, and the cycle continues.

The click rate for this feature was very high, with early numbers showing users endorsing 14 connections on average. People enjoyed reciprocating, and passing it on. Later, it was determined that Endorsements were directly responsible for increasing the usage of every other product on the site. It remains the fastest growing product in company history.

“…Endorsements allow members to easily recognize the skills of their colleagues. In just over four months since the launch of the service our members have generated nearly 1 billion endorsements.”

LinkedIn CEO Jeff Weiner (Q4 2012 Earnings Call)

Cureatr

Overview

When I joined Cureatr, the first question I was asked was how to improve the readability of the “Active” status. The status itself was lime green, and with a contrast ratio of 1.76:1, it was a far cry from the 4.5:1 recommended for WCAG 2.0 Level AA accessibility. Our users skewed older, with less-than-perfect eyesight, so meeting this standard became a top priority.

User feedback on a color had revealed a deeper usability problem. As sole designer for the company, I created a new style guide (nicknamed “Cascadia”), and established a set of design principles centered around clarity, verifiability, ergonomic speed, and privacy based on user feedback. This laid the foundation for full redesigns of our iOS, Android, Windows Phone, and Web apps.

These were exemplified in our Quick Messages feature. The existing version required 4 taps to send a message—one to open the options tray, one to choose the Quick Messages option, one to select a message, and one to send. The new redesign reduced this process to two taps—one to open Quick Messages, and one tap on the message to send. The list of Quick Messages could be scrolled so that the top message sits below the vertical halfway point, making it easier to use with one hand. These changes greatly improved the ergonomic speed of the feature.

HIPAA compliance meant that to protect a patient’s privacy, we could not reveal any message content to an unauthenticated user. This meant that any push notification would have only the sender’s name, but no information from the message itself. With the Quick Messages redesign, we added four new emoji replies at the start of the list: Okay, No, I’m not sure, and On my way. As these messages could not be modified by the user, they would never contain any private information. This allowed us to show previews for these Quick Messages on the lock screen, eliminating the need to unlock the device and enter a Cureatr passcode beforehand. This is an industry where seconds matter.

For the web app, we were faced with the additional challenge of supporting IE 8 on Windows XP at 1024x768 resolution. This meant putting a heavy focus on maximizing space for content, as well as keeping page performance as snappy as possible for the sake of older equipment. As our target user for the web app was desk-bound, we worked to make the product fully accessible via the keyboard, to reduce the friction of switching to the mouse mid-task. We also extended the app from a model that allowed for one task at a time (such as browsing a message list, viewing a conversation, or composing a new message) to one that allowed for multiple tasks to be performed simultaneously, which proved a better fit for users in a busy hospital environment.

“The product has come farther in the past 6 months than in the year before.”

Cureatr CEO Joseph Mayer

Pypestream

Overview

When I joined Pypestream, the existing information architecture model was hugely problematic. The model organized content via a system of “Pypes” (categories) and “Streams” (subcategories). Unfortunately, browsing all updates meant the user would have to navigate between each Stream one at a time, pogoing between them.

I introduced an updates feed to show content from all channels in one place. Updates across all Streams were aggregated onto one screen, which eliminated pogoing entirely. The feed also created a central location to feature more important messages, collect user satisfaction data, and cross-promote other app features and content.

Another high priority was improving discoverability of Pypes and content. In the existing model, the Explore tab provided a short list of hand-selected Pypes for users to connect with. To view any other Pypes, the user either had to encounter a link outside the app, or use search to look it up manually. My team knew we could do better.

We realized there would be a small handful of well-known brands that most people would recognize, and a long tail of content that needed to be easier to find. It struck me that the "app store" model was designed to solve exactly this problem. Furthermore, styling the feature as an app store aligned with our desire to position Pypestream as a provider of app-like functionality to businesses lacking the resources to build their own app.

Featured Pypes were still given high visibility, while the rest of the catalog was divided into categories to make discovery easier. We also introduced a “Pypes near you” feature which would show users Pypes in their area.

In parallel with the improvements to the Explore tab, we also increased discoverability by adding Pype recommendations to the main Updates feed, so that users would continue to encounter new content without needing to actively seek it out. All told, we offered substantially more avenues for discovery than with the existing approach.

With customer service as a central focus of Pypestream, I began to consider ways to better stratify and manage a high volume of incoming requests. There were early plans to let AI “handle it” with NLP, which to me seemed problematic. If Amazon, Apple, Google, and Facebook still struggle with getting AI right, what made us any different?

One of our greatest strengths was that each of our Pypes had a human operator. What if these human operators could trigger an automated flow that walks a user through the problem? Large enterprise customers would be able to translate their existing call center scripts into automated flows. Instead of relying on AI to route users correctly, we could use AI to augment the human operator's experience by suggesting the automated flow it believes is correct. Over time, this could be used to build training data—so that if the AI guessed correctly the vast majority of the time, it could be allowed to start the flow automatically.

Lastly, there was the problem of user reach. A broadcast sent to 500 people would be limited to those 500, as any content sent out would only be seen by people already electing to receive it. Instead, I proposed opening the walled garden to allow public sharing of Broadcast content, with each Broadcast having a sharable landing page. This increased the potential reach for content and allowed for virality. These pages would also be cataloged and categorized to improve SEO across the site.

From conversations with our users, we knew the big “A-ha!” moment came from their first conversation with a company over text. Compared to popular products like Facebook Messenger (which users likely had installed already), our product required the user to download the app and set up an account, which was a major friction point.

I proposed bringing this basic chat functionality to the mobile web. As installation was no longer required, users could have their first chat with the same amount of friction as competing tools, and removing the signup requirement meant we could expect a boost in MAU. The web chat would provide a user's first “A-ha!” moment with our product, and our app would further enhance their experience with push notifications, a user profile, and updates feed.

Making broadcasts public greatly extends their reach, improving discovery, and making basic chat available without requiring an account means many more users can quickly try our core feature.

“Yes—I want this yesterday!”

Pypestream EVP of Product and Technology Jatin Patel

Contact Hans

Let's build something great together.

Hans van de Bruggen
571-348-8192
 
View LinkedIn Profile