Leading Design and Research at Humble Dot

I joined Humble Dot as an early employee at the pre-seed stage. As a core member of the team with a strong focus on user-centered design, I helped to evolve the product and find product-market-fit.

Today, Humble Dot today is a team collaboration platform for large and distributed companies. Adopted by corporations like Google, Twitter, as well as non-profits like NYC Department of Planning and Stanford University, it is a lightweight means for managers to build stronger and more efficient teams. Through the process, it was invaluable to talk to the leaders and their team members, who were loyal users. One of my favorite statements came from Grace, VP of Engineering at Africa’s Talking: “I went from having a 10 person team to 30. I had no idea how I was going to be able to continue to stay connected and manage all my direct reports without sacrificing quality. Humble Dot saved me.”

Humble Dot is an automated tool that builds visibility, alignment, and camaraderie for remote teams.

Humble Dot is an automated tool that builds visibility, alignment, and camaraderie for remote teams.


As the first and only designer and researcher at the startup, I was fortunate to touch on every aspect of our product and marketing. Some highlights of my experience:

  • Defined the roadmap through strategy, user feedback, and analytical insights with the CEO and CTO.

  • Conceptualized and designed product features based on PMF surveys and user research insights; increasing engagement metrics by 200%-300% and customer satisfaction by 70%.

  • Rebranded the company: created brand guidelines, art-directed a product video, redesigned the website; reducing bounce rates and increasing conversions by 22%.

  • Created and owned the process for user research from usability studies to formative interviews.

  • Developed marketing and email campaigns with the Head of Growth.

The rest of this post explains the thought process behind a big product release: the Home Tab.


DEEP DIVE

Understanding the problem

Humble Dot is a team alignment tool for managers to setup check-ins with their team members. There are public questions for team collaboration and status updates, private questions for one-on-one matters, and social questions for team bonding.

The grid view, shown below, provides a detailed snapshot of all team updates. Here, managers view all the responses at a glance and drill down to priorities and blockers if necessary.

Grid view optimized to see high level updates from each member of the team, with Social, Public and Private questions.

Grid view optimized to see high level updates from each member of the team, with Social, Public and Private questions.


User Stories and Feedback Driving the Process

However, user interviews that we did revealed that the grid can be overwhelming and time-consuming. Our users divided into two groups with distinct use cases: managers and members.

Our power users, managers who care deeply about their teams yet are extremely busy, wanted HD to tell them what they needed to know. At a glance, they wanted to get a high-level update.
User stories as a manager:

  • “I want to see the most recent check-in responses.”

  • “I like to help my team feel heard by giving them Kudos, to acknowledge that I see them!”

  • “I want to know how many people, and who filled out a check-in. ”

Members were busy too, but they enjoyed reading each others’ updates. Some had resistance to add another tool on their plate, so wanted to get to the responses quickly. Others did not mind poking around the tool to see their previous updates and to interact with each other.
User stories as team member:

  • “I want to see the most recent check-in responses from my team-mates. What are they working on?”

  • “I want to know if there is an open check-in I need to fill out.”

  • “I want to quickly see who mentioned me, gave me Kudos (likes), and left comments.”

Analytics to Support Qualitative Findings

We supported the qualitative findings from the user interviews with a deep dive into the analytics. We plotted top user activity for managers and members respectively.

Top Manager Activity

75% of the most frequently taken manager actions, View Responses and Give Kudos, mapped to the first two user stories that came out of the interviews. In addition, we discovered a group of power users, ~20% who replied frequently to responses. This was counter-intuitive to our engineering manager persona; managers who has very little time to interact with direct reports. Finally, we discovered another power user profile, ~5%, who took the "Preview Questions" action before each check-in goes out. This helped us realize how hands-on some managers like to be about the touch points with their direct reports.
 

Top Member Activity

60% of all member activity was completing an open check-in, mapping to our primary user story. Despite the number of members who mentioned the importance about visibility into other team-mates' work, analytics revealed ~22% of users were actually taking this action. This finding helped us de-prioritize this action. Finally giving Kudos and replying to commenting on responses had a total of 18% weight. Overall, user stories successfully captured all activity, and analytics helped clarify the importance of each.

Solution: Home Tab, the mission control center

We decided to balance the complexity of the Grid with a simpler Home tab, that summarized the valuable information for the user. Home would be the new landing page. It would have a list of all the activity (notifications) the managers and members need to know.

The Architecture of a Notification

I worked with our CTO to list all our notification types, and proposed a visual architecture that all notifications would share. Looking at similar platforms, I wanted to lead with the notification type. In The second distinctive quality was the team or the team member the item belonged to, therefore that came second in the visual hierarchy.

Working through this stage together enabled us to synchronously build the front end and the back end of the feature.

Notification types and architecture summarized.

Notification types and architecture summarized.

Notification Types

My first exploration of the notification types followed our user stories, disparate for managers and members. Working with grayscale allowed me to differentiate between check-in related notifications and all others. Since all the SHARED notifications (shown on the third column below) had an inline quote, we initially felt comfortable with this distinction.

First iteration of the notification types for Managers, Members and Shared respectively.

First iteration of the notification types for Managers, Members and Shared respectively.

V1: Reverse-Chronological Timeline

Putting the notifications together, our brute force solution was a reverse-chronological timeline. This was the most cost-efficient solution to build.

However, check-in related notifications got lost in the timeline. Since providing input and viewing responses to the check-ins are at the crux of our application, we needed to change this.

This wireframe of the reverse chronological timeline shows how check-in related notifications get lost in between the secondary notification types.

This wireframe of the reverse chronological timeline shows how check-in related notifications get lost in between the secondary notification types.


V2: Prioritize Check-ins Above All Else

I tackled differentiating check-ins from other notifications from 2 angles.

First, by introducing distinctive action buttons. I used our primary button, with a solid blue background, for primary check-in notifications, and secondary button, with a blue outline and white background, for all secondary notifications. Consequently, I removed the notification icon type indicator. This solution simplified the modules and drew attention to the primary CTAs.

notifsall.png

Second, I introduced a new section on top named “Check-ins”. This module would hold all time-sensitive check-in related notifications including “Preview” for the manager, “Complete” for team members, and “View Responses” for everyone.

checkin prior.png

V3: Granular Structure and Empty States

At this point, we began using the home timeline internally. Additionally, we conducted some user interviews to get feedback from some of our customers. Most of the feedback emphasized the need for more organization.

Specifically when it came to Check-ins, people wanted to know if they had something to do. The check-in notification for viewing responses, was not an urgent one. But seeing this above everything else caused some confusion among some people. Therefore, we ended up creating a dedicated To Do section with primary notifications that require an action. On the side, we had Recent and Upcoming Check-ins modules that displayed the check-ins within a week from now.

Additionally, we added some rewarding and fun empty states. Our users always asked for the number of check-ins they filled out. Knowing the importance of continuity in using the tool, we decided to display the current streak in the empty state of the To Do module.

home - empty states.png

Final Version 🎊

After getting some more feedback, we released the home tab as seen below.

final.png

Some major improvements of the final update:

  • Showing the profile picture of who completed the most recent check-ins. This was one of the user stories for the managers.

  • Removing the buttons from all secondary notifications under the What’s New module. The inline quotes have hover states and serve as buttons.

  • Keeping the primary buttons only under the To Do module. This made the urgency of those items very clear.

Thinking In Code For Designers

I always had an infatuation with coding and product design. Yet, looking at job descriptions, it was hard to fit under one title.

My designer self loved the font Helvetica and doodling in my sketch book with a fountain pen. I was also fascinated with how UX Design had gained prominence in the world. Like Maria Giudice wrote, design leaders were emerging as DEOs along with CEOs. People cared more about how technology was affecting their being. Just as Julie Zhuo predicted, users chose one product over another ‘because of style and how it made them feel rather than pure utility.’

Rise of DEO is an inspiring  book  by Maria Giudice about leadership by design.

Rise of DEO is an inspiring book by Maria Giudice about leadership by design.

Meanwhile, my developer self wanted to understand how the blockchain worked. I loved the practicality, speed and scale that came with software development. The simple recipe of making a website from scratch. The instant gratification of pushing code online. Having reach to 3 billion people on the Internet with one commit. With all this combined, the relative impact of programming was immeasurable.

Here is a secret I learned: You can design technologies and use coding as your superpower. As design and engineering communicates better, your team moves faster, you iterate more, and land creative as well as feasible solutions. So, I started as a software engineer ‘with an eye for design’. Then I took on hybrid roles that combined front-end development and design.Currently, I am a designer who can think like a programmer.

How can designers THINK in Code?

If you are a UX designer, developers will implement your designs in code one day. Your mocks will become parts of programs that reach real users. One thing that helps with this process is thinking in code. That is putting yourselves in the shoes of the developer. Here are two practical ways you can adopt the superpower to think and talk like a developer.

Mix and Mingle

Quickest way to start thinking like a developer is working closely with them.My team, Periscope, sits under Twitter’s Video Org, and we operate like a startup within the larger company. We organize bi-weekly board game nights and pingpong tournaments. We even have a basketball team! Team spirit forming starts at the lunch table, and ranges from making flower arrangements for mother’s day to having team all-hands.

Despite how much us designers like our displays, we make an effort to mingle with engineering. The cross-pollination between engineering also begins at an informal level.We get to know each others’ language through discussing the graphics of the latest video games. Then we have weekly, sometimes daily, project syncs. During these meetings designers, as well as client engineers (iOS, Android, and Web), share their progress on what they are building.Engineers ask for creative guidance if they are working on an unforeseen error state. Likewise, designers get feedback on their designs regarding engineering cost and constraints.

All in all, working closely with engineers is the first way designers will learn the technical lingo and start to think in code. Getting exposed to engineering ideas makes sure you don’t waste time in perfect Design Land. This way you move away from ideas that are impossible to build. So, you have more time to explore the feasible design space. You land elegant as well as workable solutions.

Prototype: Visual Programming

Another way to empathize with developers is to use visual programming for prototyping.

Origami, one of the best visual programming tools for designers.

Origami, one of the best visual programming tools for designers.

What is visual programming?

I am a visual thinker, that means majority of my ideas come in the form of pictures. When a concept gets complex, I reach for the white board to draw it out, to explain it to myself and to others. Similarly, visual programming illustrates how components of a process relate to each other. An easy example that everyone is familiar with is a flow chart. In contrast, text-based programming flows line-by-line. Like the command-line tool; the green and black interface of the Matrix.

Why use visual programming to prototype?

If you are a visual thinker, like many UX designers tend to be, visual programming will come to you naturally. Also, using these tools, you will build an understanding of how each button and screen relate to each other.You will understand what components make up the big picture and how logic flows through the prototype. So this is a great way to build empathy with developers, who live and breath in Number Land.

This is why we call Origami Noodle Soup 🍜

This is why we call Origami Noodle Soup 🍜

On my design team, our go to prototyping tool is Origami Studio, also known as Noodle-soup. There are practical reasons why we prefer this tool. First, you can copy paste designs from Sketch and preview on a device using the iOS app. Second, a vast library of patches is available, including option switches and built-in animations.

Looking to get engineering or stakeholder buy-in? Powered with Origami and similar tools, possibilities of what you can prototype are endless. You can explore a wild range of ideas from building a voice recording tool to a native camera app in a few minutes. Go out to the wild, build your crazy idea, and illustrate how innovative your concept is! If your design fails while you try to put it in numbers and patches, let it evolve or pivot to another.

“If a picture is worth 1000 words, a prototype is worth 1000 meetings.” — saying @IDEO

 

he long-debated question: Should designers code?

he long-debated question: Should designers code?

I used to believe that thinking in code while designing restricts creativity. I wanted my designs to be unprecedented. I knew that conciseness and reusability in programming were important. But I did not see the link between unique designs and the systematic way of code and logic.

As a designer with an understanding of code, the more I bring what I know from programming into my design practice, I am able to move faster and iterate more throughout the process. Through the engineer-designer feedback loop, considering the engineering constraints and designing for edge cases, I grow as a designer.

Here is Part II: Design the Edge Cases.

Prototyping Technical Constraints

In the world of static mocks and flawless prototypes, software bugs and considerations are invisible. They play hide and seek. If you as the designer don’t find them, your users sure will. When design considers developmental limits, constraints won’t get in the way of design. In contrast, when UX is designed around technical limitations, constraints become your strength. 

In this case study, I explain how we turned the technical constraints of live video into design strengths.


dinosaurs.jpg

Technical Constraints of Live Video

Personal broadcasting is built upon empathy. People who need a human connection, who want to share a personal story, start live streaming. Their viewers interact with them by asking questions, making comments, and sending hearts — in real time. This way, the viewers become part of the broadcaster’s narrative. So it’s important that the app does not let the broadcaster feel alone.

Periscope  App Store Preview video that I art directed.

Periscope App Store Preview video that I art directed.

Live video technology has unique challenges, such as video latency. Latency is the time between an event being captured on the broadcaster side and when the viewer sees it. The network speed as well as the device settings could increase the latency. If the time difference is noticeable, a broadcaster and their viewers cannot be on the same page. Interaction and empathy goes out of the window. To solve this, our engineers introduce an ‘artificial delay’ by tying comments to the video stream. This way thousands of people are able to watch the same comment and video stream at once.

While engineering enables realtime interaction, design builds emotional connection between the broadcaster and her viewers. The concurrent viewer number and hearts they send show the presence of watchers. One benefit of the heart animation is that it builds empathy with a wide array of emotions. The floating hearts blend in with a joyful music broadcast as well as a heart-breaking news story. Also, when the broadcaster’s friends join her stream, their avatars appear at the bottom of the UI. This way your friends avatars make eye contact with you as long as they are watching your stream in real time.

Cost-Effective and Scalable

Engineers refer to some software actions as costly or expensive. These functions require a lot of resources to be used such as the CPU, storage and memory. In order to scale well, we need to implement cost-effective solutions.

Sometimes engineering reduces cost of operation, and design integrates costly operations into a seamless experience.

For example, our engineers reduce the cost of serving broadcasts to thousands of viewers at the same time. Let alone downloading multiple video streams simultaneously, even a single video is not loaded all at once. Instead each stream is divided into chunks. As the viewer keeps watching, more pieces of video are requested from the server. This way, the device’s memory is not overloaded with unnecessary information.

Prototype displaying metadata to make up for the time cost of loading a broadcast.

Prototype displaying metadata to make up for the time cost of loading a broadcast.

On the visible user interface, design accommodates for the time cost of expensive operations. For example, to make up for the time of loading a broadcast, we display relevant metadata. Similar to the credits at the beginning of a film, we warm up the audience by introducing the broadcaster, their avatar, location and the title.

Video (true) if { Min(cost) && Max(resources) }

Alternatively, engineering and design work hand in hand to minimize cost of operation. For instance, it’s costly to load and display the chats in the stream. So, when a chat room has many participants, we display one chat bubble per second. This doesn’t only minimize the data used to load the chats, but also makes it easier to engage with the messages. Additionally, we prioritize displaying the chats that are relevant to each viewer through personalizing their stream. So for two viewers with different follow graphs, messages will appear differently. This way, your chat room represents your community while we scale the same broadcast to thousands of watchers.