This case study is password protected due to the recency of this information. All of the other case studies are public.
To read this case study, enter the password.
If you don't have a password, please return to the menu or contact Mattthew to request it.
Clover Health is an insurer for the Medicare population. The Medicare system rates insurers based on the number of patients in each insurer's population who have chronic conditions and based on whether the insurers can prove that their patients don't experience any "gaps in care" for those chronic conditions. This rating system is a strong incentive because it directly impacts an insurer's bottom-line. To improve their ratings, insurers rely on the healthcare providers within their networks to carefully document the constant and consistent care of of their patients who have chronic conditions.
My task at Clover was to design a tool to be used at doctors' offices to achieve this documentation goal. The tool would surface administrative tasks generated by Clover's back-end systems (tasks such as ordering tests for a chronic conditions and checking if patients are correctly taking medication for those conditions). The tool would then allow administrate staff members at doctors' offices to prioritize, manage, and complete those tasks. Completed tasks would then automatically create the documentation necessary to prove constant care to Medicare and thereby meet Clover's business goals of increasing their rating and maintaining healthy patients.
If we could get doctors' offices to use the tool, the bottom-line business benefit to Clover was clear. But what were the incentives for doctors' offices to actually use the tool? My first strategic challenge was to ensure that Clover's executive stakeholders understood the paramount importance of motivating — not just the owners and managers of doctors' offices — but also the end-users, the administrative staff members who I would be building interfaces for. As the advocate for the end-user and expert in their needs, it was essential for me to communicate the difficulties of getting end-users to remember to engage with our tool and to understand the "what's in it for me" of using our tool.
I conducted many qualitative interviews with these administrative staff members, including visiting their offices during working hours to understand the unique environment in which they would use the tool. It's all too easy for product managers and designers to assume that software will be used in an environment similar to that in which they were created: a quiet office, state-of-the-art equipment, and perhaps with snacks and beverages close at hand! Through visiting these offices, I found a very different story: a hectic and distracting environment filled with patients calling out in distress and multiple ringing phones, old and slow computers running Internet Explorer browsers, and rapidly changing priorities issued from office managers.
It's also easy for business stakeholders and designers to forget that, while their product is the most important thing in their lives, their product must fight to even be remembered by the end-users. In considering my users' environment and their incentives, I needed to remember that Clover's patients often made up a small percentage of all the patients that a doctor's office encounters in a given week. I needed to consider the users' offline activities and daily workflow, and what might trigger them to re-engage with our online product when they were not staring it their screens.
Using interviews and prototypes, I explored several avenues for potentially incentivizing the use of our tool. One seemingly potent avenue, initially favored by business stakeholders, was a financial incentive. Why not use a portion of the revenue generated by the tool to pay end-users directly for using it? However, this idea proved thorny. Paying administrative staff directly would add new operational overhead for Clover. More importantly, I found that the doctors' offices' owners and managers I interviewed considered this idea an interference with their own delicate systems of incentivizing their office staff. I also explored the minimum payment amount that would be effective, whether staff wanted to understand their earnings per-task, per day, etc., and whether earnings should be pooled and evenly distributed to all staff members or indeed if staff members should compete with one another over the payment pool.
Additionally, I generated many alternative ideas for potential incentives, including non-financial gifts, creating an emotional understanding of how task completion improved patient lives, incentivizing patients to send thank-you messages to staff members, and online gamification techniques. I also tested my ideas for smartphone notifications about new and critical tasks, incentivizing Clover patients to deliver personal notifications to staff members during visits, and more long-term concepts such as an electronic badge that could follow Clover patients from room to room within the office, triggering our applications.
Before starting to architecture concept designs, I first conducted extensive comparative analysis. Direct competitive analysis wasn't possible because Clover's tool was the first of its kind in its industry. I studied and documented many task management tools, including common consumer tools, and the tools of software creation task management, such as Jira & Asana! However, those tools all differ from Clover's tool in a significant way: users of Clover's tool would not generate their own tasks. Therefore, I further identified non-task-management tools to study, based on criteria such as shown in the sample slide.
Presenting these findings to business stakeholders and subject matter experts allowed me to proceed with prototyping the first iteration of the tool. My UX and visual designs made use of our existing design system as well as the look & feel guidance provided by user interviews. For example, our end-users — administrative staff — were most familiar with the cumbersome and byzantine UX of electronic medical record software. However, I was able to document these users dislike of poor UX, and make the case that modern style choices would result in better task completion. That might seem like a no-brainer, but it was a deviation from industry standards.
After validating low-fidelity prototypes with internal users, I decided to create a high-fidelity prototype in order to conduct usability tests. This would allow users to experience end-to-end interaction patterns. Additionally, I needed to prove to stake holders that animated transitions were necessary to convey meaning and guide the users' eyes from step to step.
I conducted usability interviews with four users, asking them to complete usability goals such as choosing a task and marking it as complete within the tool. As usual, user feedback led to significant changes to the initial designs as well as a deeper understanding of the users' motivations and workflow. For example, while it's often better to show all available options rather than to collapse them into a drop-down menu, the single call to action "we can't or won't renew" proved more readable due to the high information density of the page.
In addition to the tasks project, I helped to develop Clover's design system. Specifically, I created a tool to help the design team maintain WCAG 2.0 accessibility standards. Clover's marketing team had created a palette of brand colors, ranging from light to dark for seven hues (shown here in the middle horizontal row). However, saturation levels were inconsistent as each hue moved from light to dark. Additionally, the palette contained gaps for some hues, leading designers to make inconsistent choices for the lighter and darker values of some hues. I solved these issues by creating a palette that respected the brand hues while making saturation consistent and filling all of the gaps.
My palette also has a very unique property: any hue can be swapped with any other hue while maintaining the WCAG 2.0 contrast rating (ensuring that text is still readable by users with diminished vision). This property allows designers to know, for example, that fully-saturated brand-green text on a light-wash brand-green background will have the same readability if brand-green is swapped for brand-purple. Creating a palette with this property required writing code that allowed me to carefully calibrate the value steps from light to dark (show here as the columns in the grid). It was not simply a matter of changing the hue number of the HSL color-code because the human eye perceives different hues as having lightness values. For example, we perceive blue at 50% lightness as "darker" than yellow at 50% lightness.
My palette system also makes the CSS code of the design system more efficient. The color of each part of any component may be specified with it's number of steps lighter or darker from the base color. For example, if "0" equals the base color, then "+3" equals the lightest wash of the base color before it becomes pure white. With this in mind, an alert box component can be coded such that the alert text uses color code "0" while the alert background uses color code "+3". A variable can be passed into the alert box component to specify its hue. For example, red might indicate to the user that action is required, while blue might indicate an "FYI" message. Regardless of the hue value passed by the variable, the component's text is guaranteed to have the same contrast from its background, and therefore the same accessibility rating.
I joined Siempo in late 2017 just as it was making a major pivot away from creating a hardware phone and towards building software solutions for screen addiction. As Lead Product Designer, I was responsible for the full product stack. The Siempo Beta app for Android that I designed launched in April 2018.
Because of the pivot, the future of the product was wide open when I joined. My first priority was to understand our potential users. I knew that Siempo could be useful to and needed to reach a wider range of users than just those who would describe themselves as “addicts”. After conducting several interviews with the founders and alpha testers, I identified three usability personas that each had very different needs from the product.
As the venn diagram shows, users have many reasons for reducing their phone usage, or simply for using their phones more mindfully. These range from a desire for a healthier lifestyle to a desire for focus and productivity to a desire for support during moments of temptation.
I also identified the top-level KPI for measuring the success of all of the products to be built: time spent in apps that users have flagged as problematic for them. This single metric would drive consensus within the team as well as provide powerful proof of Siempo's value to its users.
While the personas resonated intuitively with all of the founders, I knew it was necessary to validate them quantitatively, given their long-term implications for the product road-map and the business priorities.
To do so, I designed a quantitative survey which I launched to a representative sample of the US adult population. The survey asked respondents several multiple-choice questions about their phone habits and their feelings about their phone use that could be used to bucket them into one or more of the usability personas. At the end of the survey, I also described the personas, plus a fourth persona as a control, and asked them to self-identify as one of the four.
The survey results strongly validated the personas as distinct and showed that all of the personas (except the control group) had some desire for Siempo's feature set. That information gave Siempo an accurate prediction of its serviceable available market size. Additionally, by dissecting the data I found a strong correlation between a respondent's self-reported persona and the frequency of their feelings of guilt about their phone use as shown in the chart.
I designed an end-to-end prototype of the mobile app that I could place in people's hands for usability interviews. I conducted several interviews, giving each participant tasks to validate if our features were discoverable, accessible, and effective for all three usability personas. These interviews revealed many improvements that I was able to implement into the design before the start of engineering. Play the video for a 38 second overview of the beta app's feature set.
Siempo is the first app of its kind that helps curb unwanted phone habits from the moment of unlock. I researched other habit-breaking apps, addiction literature, and inverted the theories of behavior that are typically by product designers to keep users glued to their screens. I helped ideate features that eschew cold-turkey for gentle nudging while reducing the behavioral triggers that encourage unconscious app usage.
Siempo is a home app or launcher that replaces the default method of paging through third-party apps in order to launch them. Because Siempo's purpose is to help users reduce their screen time, my visual design of the app needed to walk a tightrope between appealing and distancing. My style for that app is spartan yet buoyant and generic yet accessible.
The alpha app was entirely shades of gray because research shows that removing colors helps reduce phone use. However, I introduced one accent color to indicate tappable and important screen elements.
I designed Siempo's marketing website for emotional impact by visually representing the feelings of being overwhelmed & constricted that users reported before using Siempo. I then used an animated transition to the idyllic landscape to represent the feelings of freedom & health that Siempo offers.
Prototyping doesn't always need to be digital! Siempo considered a feature to deter overuse of apps by blocking a small portion of the user's screen after a period of time. To test this idea, I could have created a software prototype, but I wanted to see test users respond in a real-world scenario such as browsing through one of their actual social-media accounts.
I crafted this physical prototype in just a few hours, and made it able to stretch to fit any device. With "Siempo Cardboard" I was able to swap in different sizes of screen blocking and to get user feedback faster and more accurately than with a digital mockup.
Of course, when appropriate, I have also created high-fidelity prototypes. You can tap on this example prototype of Siempo's feature that allows users to type a personal "intention" for themselves. Here, it was important to prototype the full visual experience including animations because the UX design of saving an intention needed to have emotional impact. I watched test users interact with the prototype and asked them if they felt that impact.
Despite being an MVP, Siempo Beta debuted in the Google Play Store to strongly positive reviews: “I have tried tons of ‘minimalist’ launchers, this is the only one that has lived up to it's claim.”
Cardpool is a dual-sided consumer market place where customers can sell unwanted plastic gift cards for cash and purchase pre-owned gift cards at a discount. As the sole UX designer, I created its first Cardpool mobile app, moving from sketchpad to app store in 7 months. The app earned a 4.5 star rating in the app store, was an Appy Awards finalist, and won PayBefore's "Best Mobile App" in the payments technology category.
I also designed the complete overhaul of the Cardpool.com website, making it responsive to mobile devices, and I designed the interface of Cardpool's kiosks, in-store stand-alone machines that allow customers to exchange plastic gift cards for cash vouchers.
My assignment was to increase sales and revenue by making Cardpool services available on mobile phones via native app and responsive web. I not only optimized and modernized the existing features for mobile-sized screens, I also created new features for mobile consumers that could deliver discounted gift cards, ready for immediate use, while they were waiting in the checkout line.
My first step to guide internal stakeholders was a thorough competitive analysis of the gift card space as well as an analysis of best practices from ecommerce apps. Cardpool’s top competitor had the advantage of being first to market with their mobile app. However, that gave me the advantage of being able to dissected their app for ideas and flaws, and to read through public reviews to avoid pitfalls.
My research surfaced the fact that the competitor had a strong checkout flow but lacked the strong security features that users required. Gift cards are inherently insecure and prone to fraud (you can think of them as "branded cash"). Protecting users and the company required guiding buyers and sellers through several security hurdles including an SMS verified phone number. This led to researching the UX of banking and online wallet apps for approaches that made these hurdles more palatable, including a progress meter.
Before engineering began, I personally devised and conducted a week-long set of 90 minute usability interviews with 10 live subjects. I repeated this process for the redesign of the website. I modeled the entire mobile app and website as fully interactive prototypes that contained real inventory data with branding and prices. While we used a testing firm to provide facilities and moderation, I developed the tasks for the testing subjects, observed the interviews on-site, and wrote the report of findings. I conducted interviews by day, and by night I iterated the prototypes based on the feedback I observed.
Taking the time to use high-fidelity prototypes and real inventory data proved to be worth the expense. I discovered crucial insights such as how to better handle out-of-stock brands and the need to improve readability & accessibility with higher color-contrast.
One of my most effective UX innovations was introducing a slider tool that allowed users to select a total purchase amount. The slider was a brave choice because it was not used by specific competitors, nor is it common in ecommerce. But thorough usability testing proved that it would be popular. While its lack of accuracy as compared to typing in an amount generated some friction, it was successful because it gamified price selection and loosened users' preconceptions about their desired price.
When I moved to the website redesign project, I knew that the needs of desktop users at home or work were different from mobile users on-the-go. I prototyped a website version using slider as well as several other UX methods for filtering gift card inventory. The website usability testing revealed that, unlike mobile users, desktop users preferred to manually scroll though a long list of options than to use filters. Operating the slider with a mouse and track-pad didn't feel as fun as using their fingers, and desktop users found the inaccuracy unacceptable. Physical keyboards made typing a price easier, and our users at home were psychologically less flexible on price than our users in-store.
My review of our internal metrics for the original website revealed that although many customers accessed the website from mobile devices, those devices had poor conversion to sales during the checkout funnel. I found specific pain-points in the funnel, which allowed me to make the case to the stakeholders for the need to budget for overhauling and standardizing our form fields and form validation.
I devised and documented a detailed interaction model to handle form presentation that served to reduce the user error rate, boost user retries, and ultimately increase conversion to sales during checkout. Using the new "float label" standard employed by Material Design, these best-in-class form elements feature unique color states and animated transitions for hover, focus, valid, and error states. I also re-wrote micro-copy such as for errors to sound friendlier and provide more detail.
The launch of the mobile app and website coincided with a new visual design tailored to attract a wider audience. My design process began with the creation of marketing personas. These personas helped achieve consensus with stakeholders and allowed me to proceed with creating the visual style guide.
An internal marketing demographic survey revealed that 50% of the legacy user base was 45 and older, revealing the need to attracting younger consumers. I made recommendations for the use of lifestyle photography that exhibited a diverse set of models, use of currently fashionable website design elements, and moving away from the old-fashioned skeuomorphic design.
Because we used an off-shore engineering team, I also delivered pixel-perfect mockups and extensive UX documentation including the details of micro-interactions, transitions & animations, error states, and micro-copy. The complete style guide also included typography, color, and layout details.
Where budget allowed, I argued for the live site to incorporate transitions & animations to add to user delight. Even subtle animations such as 50 millisecond hover effects produce the unconscious sensation of polish and modernity. I also created more dramatic transitions, such as with the presentation of the gift card inventory list. The cards slide from off-screen to their resting position using a staggered animation effect, and in usability testing of this effect, users reported excitement and increased attention.
CouchSurfing.com was one of the pioneer “sharing economy” services. It preceded AirBnb, TaskRabbit, and Lyft, and it has sometimes been called "the free AirBnb" or "the platonic dating site". I helped create many of the tools for rating the trust between sharing-community members, and those tools were later duplicated and improved by those websites.
I joined CouchSurfing three years after its public launch in 2004 and was hired by its founder as the 2nd full-time employee. I helped select and hire almost every employee who followed me, growing the company by 45 more people, and building the product department from the ground up as its Head of Product Design. I co-designed the first CouchSurfing mobile app, and my product initiatives helped the company acquire $21 million in venture capital funding.
In collaboration with my talented team members, I product managed and launched CouchSurfing's first iOS mobile app, optimized the purchase funnel to greatly increase revenue, created the product design and UX for the casual mobile meet-ups tool, created new strategies for our user matching algorithm, oversaw our first re-branding effort, and designed internal tools for user safety and customer support.
CouchSurfing is a dual sided "marketplace", with times of unequal supply and demand in different parts of the world and in different seasons. I studied multiple solutions to improve our matching algorithm taking into account these market dynamics and user behavior. Unlike AirBnb, a host's location and amenities were not driving factors for matching. Also, unlike romantic dating sites which are optimized for worse matches due to the fact the successful matches lead to lower revenue, successful matches on CouchSurfing led to higher revenue. CouchSurfing was, and still is, a one-of-a-kind laboratory for quantifying human interaction.
The "couch" was just one of the potential venues for face-to-face experiences between to members. CouchSuring.com initially launched with only this one venue, which was also its name-sake. It then expanded to organized formal events. I led the creation of our third venue: our casual mobile meet-ups product suite. This expansion allowed any number of members to spontaneously gather around any place of interest or any activity. It has yet to be duplicated successfully on any other website.
I helped optimize CouchSurfing for the greatest number of face-to-face meetings between members. By expanding the venues for such meetings beyond the "couch" and from 2-people to groups, I increased active users, user retention, and the network effect that those create in turn.
One of the many initiatives I led over the years was the overhaul of the search results list that members used to search for other members to meet. This page represented the start of the funnel that led to a face-to-face interaction. In order to improve this page, I conducted several individual user interviews, analyzed the page's heat-map for thousands of users, and conducted quantitative research.
I conducted quantitative research continuously to optimize product funnels and measure the success of each iteration. By wading through vast amounts of data, I discovered that the greatest driver of active users and therefore the most vital KPI for generating network-effect was when a member met another member face-to-face for the first time.
That first face-to-face interaction predicted a valuable member who would go on to propagate many further face-to-face interactions with other members via hosting or staying with them. With this knowledge, I was able to evaluate the success of every product iteration by its impact on that single KPI or by a faster proxy for that KPI.
Through interviews and heat-map analysis, I uncovered the criteria that traveling members used to narrow down the search results before clicking through to view an individual host's profile. I used that research to visual restructure the information within each search result.
The most important factor was a host's availability & likelihood to host. We used this primary factor to sort the search results, placing our prediction for most-likely-to-host at the top. The 2nd-most important factor for narrowing the results was basic identity as determined by the host's as age, gender, and photo. The 3rd ranking factor was reputation rating, and the final factor was personality details including common interests. We designed the new visual layout of search results to accommodate this ranking.
Knowing that travelers essentially used a three-step process to select one host to to view in more detail, I reorganized the information for each search result into three columns. I conducted further usability tests with this prototype layout, which confirmed that members could easily visually scan the left and right columns for the information they most valued in order to narrow down the results.
The restructuring and new information architecture allowed travelers to move from the search results list to the host's profile pages with greater speed and accuracy. This in turn resulted in travelers sending messages to members who were more likely to host, which in turn led to an increase in our primary KPI: a successful face-to-face meeting between members. I was able to track results across this funnel via A/B testing the product roll-out.
Rotten Tomatoes is a well known yet untapped treasure chest of data about movies. My project began with a desire to explore that data in an open-ended fashion to see where it could lead. This exploration eventually evolved into an extension for Chrome that creates for its users bespoke rating prediction for each movie. It's a personal project that is not solicited nor endorsed by Rotten Tomatoes.
Try it yourself! Download the Rotten Tomatoes Extension at the Chrome Web Store.
While I hoped that to eventually discover a marketable product, this project began as open-ended research to explore movie ratings data and determine which professional film critic most closely shared my own taste in movies. I wrote a script to screen-scrape the star-ratings of each critic who had rated a list of films that I had also rated. This allowed me to give each critic a similarity score.
I then tried comparing every film critic to every other film critic to find out who had the most and least similar tastes, based on 150 films in a range of genres. I compiled the raw data into a scatter-plot in which each dot represents a vector between a pair of unique film critics. The pair's similarity score is an average of - for each film that both in the pair rated - the distance between their two ratings of that film.
If both critics in a pair gave a random rating for each film, their similarity would be 50%. The plot shows that around 50 films in common are needed to narrow similarity down to an accuracy range of 15%. Also, as the count of films in common grows, similarity trends toward ~65%. It would be better for a taste-prediction product if the findings showed much higher levels of similarity overall. On the other hand, each critic might enjoy knowing that the are a likely a unique snowflake in terms of movie taste.
I knew there was much more that I could do with this kind of data, so I set out to create a purely functional MVP that I could share with the public to generate feedback and new ideas. I asked a few friends to install my MVP prototype, and I interviewed them about their experiences.
I discovered that people who aren’t as obsessed with film as I am wanted something more practical that would improve the Rotten Tomatoes website whenever they visited. These open-ended conversations surfaced the ideas of personalizing the Tomatometer, adding a histogram of critic ratings, and ranking the critic review-blurbs based on each critic’s similarity to the user. As I added these new features, I also tackled the app’s UX, providing an interface that seamlessly blends into the existing Rotten Tomatoes website.
The app has a small base of around 500 users who all found it only via organic searching. These users occasionally send me bug reports and suggestions. The app is still in development, and the code is open source. Most recently, I created on on-boarding experience for new users including a tool for importing existing star-ratings saved to their Rotten Tomatoes accounts.
I eventually developed and tested a hypothesis for how user rating systems such as those used by Rotten Tomatoes, Yelp, and Amazon could be improved with bespoke predictions using similar techniques to my app. I've written a short essay about online ratings systems that describes their flaws and my hypothesis for how they can be improved.
My Font Finder website allows people explore, filter, and select fee Google Fonts based on the visual attributes of the fonts. I conceived, designed, and coded this tool as a passion project.
The app was included in Product Hunt's Best Products of 2017 book, I got a shout-out from Google's design team.
I created a user interface that doesn't include any font terminology or jargon. It uses icons to encourage a visual exploration of the typography. By tapping on the various “I” and “O” icons, the font set is filtered to show fonts that match the selected shapes.
I designed it in part to help non-designers understand the sometimes subtle differences between various fonts, but it's also a powerful tool for designers to select a great font for any project because it allows the sorted fonts to be compared at a fixed width.
Font Finder is a companion to the Google Fonts website, so I designed its visual style and color scheme to match.
This personal project also served as an opportunity for me to express my passion for website motion design. Every interactive element has a subtle transition during hover and after tap. Filtering the fonts causes an elegant cascading animation.
My Tactile Synthesizr web app for mobile allows product designers and developers to create complex custom vibration patterns and to discover how the patterns actually feel in their hands. The tool allows precise control of vibration, much like a sound-wave synthesizer. I conceived, designed, and coded this tool as a passion project.
The Tactile Synthesizr works on the browser you are using right now, but requires an mobile device. does not work on the browser you are using right now. As of 2017, you'll need Chrome browser on an Android device to feel the good vibration.
Tactile or “haptic” feedback is used by mobile phones, gaming controllers, Apple track-pads, and many other devices. While it's typically used to signal a warning or alert, more subtle vibrations can be used to provide many other signals and emotions.
Chrome for Android gives websites access to the device's vibration motor. This means that product designers are free to utilize haptic feedback to communicate to users in creative new ways, however, the vibrations must be coded numerically. My web app is the only tool I know of that allows tactile patterns to be graphically synthesized.
I wanted to explore when and what type of haptic feedback is appropriate within the browser setting. The challenge was that, unlike audible sounds, the vibration API can't directly control the frequency nor “volume” of the device's vibration motor. It only allows the motor to be turned on at full strength for a specified duration.
However, I discovered that nuanced vibrations – such as fading in and out – could be created by very rapidly cycling the vibration motor on & off. By changing the duration of the on & off periods in a similar way to Morse code, I could control the vibration in the same way that a synthesizer would control the “attack” & “decay” of a very low frequency sound wave.
Tactile Synthesizr is the result of my experimentation. It was coded entirely by me and is open sourced.