Over the last two years at Twitter I’ve helped develop the Revenue Design team across multiple product surfaces. I’ve managed and supported remote teams, helped develop our Design Sprints program, advocated and grown our Design Systems team, and played a role in evolving our career ladder.

I’ve been lucky enough to help designers build exceptional products in a variety of distinct problem areas ranging from Developer Experience to Sales Productivity to Publisher Analytics to name a few.

Design @ Twitter was originally published in Ryan Kirkman Portfolio on Medium, where people are continuing the conversation by highlighting and responding to this story.

MixBit lets you record, edit, collaborate and publish videos from the palm of your hand.

The Story

Mixbit was the love-child of Youtube co-founder Chad Hurley. It was spun out of the startup AVOS he founded with Steve Chen after they both had left Google. I worked on many projects while with them, but most of my effort was spent as a design lead, working on both the web and mobile experience for Mixbit.

MixBit was originally designed to help mobile videographers quickly edit and collaborate on videos. Clips were treated as individual components that could be rearranged, shared with others, or swapped out. No other app had done it this way.

Our Approach

We aimed to stay focused on the collaboration aspects of the platform. Since it is difficult for many of us to get together after an event and spend time editing, we built features around groups and asynchronous collaboration. Think of it like Google Photos shared albums, but for video editing. We focused on allowing users to engage each other with comments, activity feeds, and notifications.

YouTube Founders Introduce MixBit To Crack The Code Of Video Editing On Mobile

Web Discovery

Web Player & Editor

Storyboarding

MixBit was originally published in Ryan Kirkman Portfolio on Medium, where people are continuing the conversation by highlighting and responding to this story.

One of the first projects I worked on at Talkdesk. Our supervisors were lacking a way to track the overall performance of their contact center outside of scheduled reports. Scheduled reports are great for summarizing historical performance, but lack the timeliness and granularity of a live dashboard.

Responsive

Module types in two sizes

Drill-down Modal

Talkdesk LIVE was originally published in Ryan Kirkman Portfolio on Medium, where people are continuing the conversation by highlighting and responding to this story.

A software phone (and more) for contact center agents

The Early Days and the CTI (Computer Telephony Integration)

When I joined Talkdesk as the first product designer, some of my responsibilities were to upscale existing design debt. The first of those was the CTI which lived not only in the Talkdesk main interface, but also in 3rd party platforms like Salesforce and Zendesk. What is a CTI? As wikipedia would explain its:

“…a common name for any technology that allows interactions on a telephone and a computer to be integrated or coordinated… predominantly used to describe desktop-based interaction for helping users be more efficient…”

There was no real vision or north-star for the CTI. It existing primarily as a call and transfer utility for support agents. As features were piled on, the tiny footprint became bloated and usability suffered greatly. Additionally the biggest pain point was that it was embedded into the page as an iframe. This meant the user could potentially have multiple tabs open with multiple instances of the CTI open. Imagine receiving a call on 7 tabs simultaneously.

CTI -> Callbar 1.0

At around the same time, I began working with one of the PMs who wanted to convert the CTI into a Google Chrome App. This would allow us to present it as a desktop application that sat on top of your browser, not in it. At the same time this presented us with an opportunity to rethink the interface and experience and to design with scale in mind.

Feature Parity

The initial MVP was scoped to meet feature parity with the CTI. This meant accounting for things such as Outbound Caller ID, Call Recording, Call Queue, Warm Transfer, and Blind Transfer.

Research

In order to really understand how agents worked with our product and how our product integrated with their CRMs, I started visiting customers and shadowing agents, throughly defined out user personas by working with cross-functional teams, and created an empathy map to help us align around the needs, wants, and frustrations of our users. I also spent time listening to call recordings to get an idea of what the experience could be like for callers.

A new focus

It didn’t take long for our customers (or our leadership) to recognize that Callbar was a vastly improved experience. With that in mind, we began to expand the scope of the product to start addressing experience gaps and sales gaps. Later I would discover how much this would test the designs and scalability of the Callbar.

“Without a solid vision of where the product was going — a true north star — the experience and footprint became bloated and burdened…”

Voicemail

Voicemails in a contact center can be very tricky. Often times there is a need for a shared inbox with features like, Resolved/Open, Assigned to, Ring group, Transcripts, Advanced Filtering, etc.

For the Callbar version we discovered the best experience would be a much simpler one. Here we only display the voicemails that were left directly on that agent’s line and/or was assigned to that agent.

Designing for Scale

Eventually we got to the point where many “feature centric” products go. Without a solid vision of where the product was going — a true north star — the experience and footprint became bloated and burdened. It became difficult for the design team to accommodate new feature requests without compromising the experience in some way. We needed a new vision.

With feature requests piling up and nowhere for us to go, we had to start thinking from a systems point of view. How could we fix the scalability issue? How do we convince the product team and leadership that now is the time to step back and think about the vision — to find our north star? We couldn’t just go to them with this problem, we also had to come up with a potential solution. How do you design for scale when you don’t know what that scale is going to look like? How do you optimize for customization without compromising ease of use?

Callbar as a Platform

Eventually we were able to align the organization around four principles for the product:

1. Context: Provide the right context at the right time.
2. Non-linear: Allow for simultaneous non-linear workflows.
3. Customization: True customization designed for ease of use.
4. Platform: Plan for 3rd party extensibility.

With these principles in mind we began the process of abstracting the Callbar into its basic components. At the same time we attempted to tackle many of pitfalls and complaints existing in the product. Things such as window management, inbound call notification, customization vs personalization, desktop footprint, and multitasking.

Callbar 2.0

Today we are still working on designing, testing, and building Callbar as a platform. We are constantly talking with customers to discover what is important to them and how we can cater to their varied needs, while still consider our agents and callers.

Talkdesk Callbar was originally published in Ryan Kirkman Portfolio on Medium, where people are continuing the conversation by highlighting and responding to this story.

Design Sprint

A Design Sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers. Over the span of one business week, we gathered and worked together on how to solve a specific problem from a variety of angles. Who was involved:

• Product (2)
• Engineering (2)
• Design (2)
• Customer Success (2)
• Agile practices (1)

The Problem

Call routing is core to Talkdesk, and currently it’s defined through a series of settings. Our customers encounter a variety of problems today from finding it hard to visualize and test their settings, troubleshoot what went wrong on a call, or understand what settings to change to improve their metrics.

The Goal: Empower admins /supervisors to personalize their customer experience.

Monday: Make a map and choose a target

What we know from speaking with customers is that a call center is like a microclimate. It has its own seasons, its ebbs and flows, high tides and low tides. To be able to manage a call center, supervisors must have insight into the volumes and patterns of their callers. This allows them to determine appropriate staffing, which in turn allows them to configure appropriate routing. Not only determine, but test and measure to optimize for their KPIs.

Design sprints are great for rapid ideation and testing, but not great for testing large systems. So part of the process of a design sprint is to choose a “target”, or prototype-able section of a map. For this sprint, we choose to focus on Configure & Validate because without it none of the other steps would make much sense.

“How Might We” Questions

HMWs are probably one of my favorite tools in the UX toolbox. They’re a great way to quickly scope and/or frame a problem without being confrontational to existing perspectives. HMWs position observations, problems, or concerns as questions that describe the general mise-en-scène, but doesn’t prescribe a solution. Examples of HMWs from our session:

• HMW: Collect as much information about a caller without creating friction?
• HWM: We route calls based on context about the caller?
• HMW: Arm agents with the information they need at the correct time?
• HMW: Visualize complicated flow logic in a simple, understandable way?
• HWM: Reduce fear associate with changing the flow?

Tuesday: Sketch Competing Solutions

The first half of the day everyone spends finding inspiration from other industries, prints it out, and takes a few minutes to present to the group. For us there were a few examples of Sankey diagrams, existing IVR tree designs, as well as some interesting script related solutions. We all take notes as the others present, and then spend the rest of the day on low fidelity sketches — boxes, wireframes, stick figures, etc.

Wednesday: Vote & Storyboard

1. Art Museum: Put the solution sketches on the wall with masking tape.
2. Heat Map: Look at all the solutions in silence, and use dot stickers to mark interesting parts.
3. Speed Critique: Quickly discuss the highlights of each solution, and use sticky notes to capture big ideas.
4. Straw Poll: Each person gets to choose one solution, and votet for it with a dot sticker.
5. Supervote: The decider makes the final decision, with more stickers.
6. Storyboard: We take the winning scenes from our sketches and weave them into a storyboard: a step-by-step plan for our prototype.

Use Case: Connect contact with their case owner

To make testing easier, we decided to design for a very common use case that would be familiar to most admin/supervisor personas. If you’re familiar with the contact center space you’ll understand the terms used here. Contact in this context refers to a caller who may or may not be recognized in the CMS of record — which can differ from customer to customer. In this case we are using Salesforce. A case owner is a representative who is responsible for the case, which here is likely a support request since the call is coming in from the Lisbon Support Line. So the challenge is to set up a flow that will automatically route the caller to the correct corresponding case owner, if one exists. If one does not exist, or cannot be found, then define where the call should be routed.

Thursday: Prototype

Now its elbow grease time. Today day we turn that storyboard into a prototype. We decided to go with a click-through prototype using InVision, since all we want is a realistic façade to test with customers. We’ll also make sure everything is ready for Friday’s test by confirming the schedule, reviewing the prototype, and writing an interview script. Since having too many cooks in the kitchen can slow things down at this point, we assign roles. My infinitely talented designer Daniel Chae was given the role of Maker — aka pixel pusher, vector jockey, hey you, etc. I took Asset Collector as well as Advisor, which I shared with the ever gracious Diana Tobey, who also interviewed customers.

Friday: User Testing

For this day we lined up 5 of our customers who had expressed some interest or concern in the way they wanted to handle call flows. We set this up through google hangouts where the customer would only be able to see the interviewer, but the rest of the team could watch and listen through screen share. There was a set script, and clearly a flow we had in mind, but we made sure to lead or direct the customer as little as possible. While this was going on everyone on the team was writing down notes about the experience.

Below you can see a linear view of the flow we built. As you might notice, the admin starts of with a pre-existing flow with three basic components: Trigger, Context, and Outcome. Without being given any direction, the user is encouraged to audibly describe what they are looking at as they explore the UI. They are then given the goal to change the flow so that context about the caller (case number in this example) can be gathered automatically, before reaching the agent.

“…change the flow so that context about the caller (case number in this example) can be gathered automatically, before reaching the agent.”

Results and Learnings

No matter how much you might think you know about your hypothesis and your customers, it is always illuminating to observe them together naturally. In the image below we have collected and collated all the notes taken during the interviews. Notes with green ink are positive, black ink neutral, and red ink negative or friction causing. As you can see, there is a lot of red.

Prototype fidelity

One of the biggest and most obvious friction points had to do with the level of prototype fidelity and the flow we chose. Users were dropped off in the middle of an editor which is very much not linear — there are many different things you might be able to do at once. But because of the limitations of the click-through prototype, users could only click where we had designed the flow to allow. This created a cognitive disconnect; because some things were clickable but others that looked clickable were not, our users stopped using the mouse cursor to explore the designs. Hence, even when something was apparent to them they wouldn’t advance to the next screen without our input.

In the future I would probably use a prototyping tool that allows for more live and dynamic interactions. At the time of this writing, I really like Principle.

Roleplaying

One of the other unexpected problems we ran into was that our customers had a hard time thinking outside their own, specific use cases. That is, when they were asked generic questions like “What would you do here?”, they would answer by explaining something that was outside the scope of the prototype. One of the challenges with enterprise software is that your customer’s needs are specific and often vastly different from one another. We attempted to address this with a use case we thought would be a common denominator, but even then they would often ignore the goals they were given and revert to their own situational problems.

Keep it simple(r)

During the storyboarding process we added in some advanced “optional” functionality. Rather than simply allowing admins to craft the call flow from their own experience, we added in “recommendations” from our little AI bot. We thought this would make the experience more seamless, but when admins didn’t like the recommendation (again because of specific use cases), there was no way for them to continue without selecting it.

I think in the future, if we have time to include things like recommendations we should do so as a completely optional parallel track. This way we don’t put a wall for those whose needs are different from what we expected. But really, if we did have that extra time I think it would be better spent making the prototype more interactive than varied in flow.

Design Sprint: Visual Routing Designer was originally published in Ryan Kirkman Portfolio on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR

AppConnect is an enterprise class marketplace of 3rd-party apps made specifically to augment and extend the functionality of Talkdesk classic. There were several simultaneous efforts (marketplace, dev portal, marketing, etc) that required my role to manage several UX designers, each working on separate effort, facilitate with stakeholders and de-risk potential roadblocks, oversee the holistic experience, and participate as an individual contributor.

Background

Company and Market

Talkdesk provides enterprise class, cloud-based software for running contact centers (think support lines, outbound sales, etc). This is an old industry with 90% of the market still running on-premise hardware systems. However, as varied as the companies are that need support centers (pretty much everyone), are as many varied needs for custom features and workflows. This creates one of the classic UX problems of enterprise software; finding the magic balance between customization, ease of use, and scalability.

Project Overview

In an effort to solve part of the customization vs ease of use problem, the company decided the best way to move forward was to build a marketplace of 3rd party apps on top of our platform. The goal was two-fold: scalability through third party development, and address sales gaps through plug-in features. This would make Talkdesk more attractive to potential and existing customers who demanded specific feature sets, which tends to happen in enterprise. And as a business incentive, developers would have access to a new revenue channel that Talkdesk symbiotically would earn a commission from.

Roles

We had two PMs (one for Marketplace through in-app experience, the other for Developer portal) 2–3 UX designers (including myself as lead/manager), one front-end developer, and two engineers.

Throughout many projects at Talkdesk, my role was a combination of hands-on individual contributor, design manager, and ux strategist. On this project I had the help of three extremely talented designers who helped define new design patterns and solve complicated flows. I facilitated by providing art direction, ux feedback, making sure we included the appropriate stakeholders at the right times, as well as keeping the project on a strict iteration/checkpoint cycle.

The Design Challenge

Process and timeline

We were given 3 months to complete the project so that it could be announced and marketed at one of our big annual conferences. Not a lot of time for such an involved project, which meant parallel tracking some of the design work. We decided to design the marketplace listing page and install flow simultaneously since the two didn’t overlap much, but dovetailed nicely.

To begin projects of medium to large scope, we like to start with a “kickoff” meeting which includes representatives from product, design, and engineering. These are high-level meetings where project timelines and goals are discussed but specifications are not yet developed. This gives all parties a chance to discuss and inform the direction of the project from their given perspectives.

This is usually followed up with a design charrette, on which initial user flows are built.

Requirements

The marketplace would need four surfaces:

1. The Marketplace
   The store itself — where our user personas would browse or search through the directory of available apps
2. Install flow
   A functional UI for installing / provisioning / managing apps
3. Developer portal
   All the necessary materials and services needed work with our API
4. Marketing pages
   Ways for customers and partners to learn about our program

The Marketplace

Competition

Doing a bit of competitive research by looking at examples of other enterprise level marketplaces, we see some common design patterns but varying levels of information density on the homepage vs the listing detail page. Notably, homepage designs focus on app branding over marketplace branding with Heroku being the exception (however the use of negative space brings it back to the apps).

Homepage design

Our goal with the homepage was to make it familiar, easy to visually parse, and sortable by category. With each revision, we fine tuned the ux to fit the real content we would have. How many partners would we be launching with vs planned to sign up in the next six months? Which categories were important to our customers? Etc.

Listing Detail Page

The number one thing we thought all other marketplace listings missed, was the ability to tell a story, quickly. Utilizing some editorial design patterns, we were able to strike a balance between the marketing needs of the partner, and the need of the end user to grasp the application concept quickly. Here you can see we tested out several variations.

In the end we had to craft content guidelines for partners in order to help them provide the right type and quantity of content. Each section adopted the practice of progressive granularity: This is a concept similar to progressive disclosure, but instead of deferring advanced or rarely used features to a secondary screen, here we are deferring more granular levels of content through the use of visual hierarchy. With a quick scroll and glance at the page, one can garner the essentials; app name, title, main screenshot, and primary pricing level. However, upon further inspection, more granular details are easily available.

Install Flow

After browsing the marketplace, the admin or supervisor would click the install button which would take them through a login flow. Once authenticated, we need to determine if the app is already installed. If it is already installed we take the user to the app subscription and provisioning settings panel. Otherwise they continue through the install flow.

Subscription model
One of the key selling points for 3rd-party app partners, is the integrated “one-click” subscription model. Customers can select from a list of subscriptions plans provided by the partner, of which they are given a 30-day free trail.

User provisioning
One of the more challenging interactions on the project was user provisioning. Which of your agents do you want to install the app for? What if you want to install by role? What if you have 10+, 100+, or 1000+ agents? What if you want to install for one specific agent? Each of these problems required specific UI to solve. Search bar, number of selected agents out of all possible agents, ability to filter out unselected agents, ability to select by role, ability to selectively remove from role, etc

Authorization & TOS
Some apps would require certain features and APIs in Talkdesk to be made accessible. Similar in model to OAuth for Google or LinkedIn.

Installed Apps & Mangement
Once installed, the supervisor and agents provisioned will be able to access the apps from the “My Apps” dropdown. Depending on the functionality the launched app will present as either an iframe within the Talkdesk experience, or as a module elsewhere in experience, depending on persona.

Error and Zero States

Developer Portal

The developer portal UX and visual was lead by the talented Francisca V. We worked together along with the Director of Platform to establish core requirements, an MVP, as well as long term vision. This part of the experience was geared developers with clearly defined documentation, as well as an easy to use approval and deploy process. These are not the final designs, but give a good idea of the detail involved in this part of the project

Marketing Page

Finally, a landing page was needed to direct potential partner developers towards to learn more about the marketplace. Visual design and layout here was done by Luis N. Many of the design language decisions we made were difficult as the company had a considerable amount of design debt and to this day lacks the foundation of a solid brand. That said, Im extremely proud of the results and everyone involved from PM to UX to Eng.

AppConnect — An Enterprise App Store was originally published in Ryan Kirkman Portfolio on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is temporary placeholder.

Video Player UX was originally published in Ryan Kirkman Portfolio on Medium, where people are continuing the conversation by highlighting and responding to this story.

Background

Discovery Digital Networks was a short format video production company creating web shows for niche markets. It originally started as Revision3 by Jay Adelson, Kevin Rose of Digg.com fame, before being acquired by Discovery Communications in 2012.

Project Goals

How do you judge the success of a YouTube channel? Views, shares, and social media mentions. Usually over the span of some time. The producers at DDN had a pretty terrible set of tools for uploading videos to multiple platforms, choosing thumbnails, and tracking the metrics of their videos and shows. This project’s goal were to improve the efficiency and understanding of how our content performed in the wild.

Video Publishing & Insights Dashboard was originally published in Ryan Kirkman Portfolio on Medium, where people are continuing the conversation by highlighting and responding to this story.