Design and product management for B2B product at Degreed

Product design, product management

I joined Degreed to lead design for B2B and enterprise product at Degreed, a progressive EdTech company focused on helping people be recognized for all of their learning and skills. After almost two years, I transitioned into the role of Product Manager for the same team to drive our enterprise offerings. As much of my work at Degreed is protected under NDA, I’m focusing this post on how I worked and tracked value across the product development process.

Inclusive product discovery

I find it odd when people think design is this magical skill that happens behind a curtain before the final reveal. Design is the facilitation of ideas and processes, independently or as a group, with the intent of solving a problem.

Product discovery starts as soon as we identify a problem. Working on a B2B product, input flows in constantly from internal and external stakeholders in the form of complaints, ideas, feedback, and research. I use tools like Trello, Dropbox Paper, and Productboard to track these inputs by theme. This helps me organize the firehose so I know who to go back to later for more information, and helps me identify real problems (and who to talk with to dig deeper).

Design by committee only happens when people make assumptions without real input. By working with others, we can firmly identify problems to be solved, test the validity of assumptions, and vet solutions. Our design team took ownership of pushing the process forward, making tough decisions about which path to follow, and keeping solutions in the scope of the problem and design system.

An inclusive discovery process creates inclusive products. It increases ownership of solutions, which empowers stronger product evangelism. At Degreed, we’ve learned that collaboration creates better products.

Designing for real people

By starting product discovery with research from current and prospective users, instead of only a set of assumptions, we kept our design focused on real problems faced by real people. Armed with this information, I can design with compassion for the product’s end users.

At Degreed, I took the lead of collecting our team’s research into 8 personas that represented the different needs and circumstances of our user base. Though personas are not a substitute for validated user studies, they helped kickstart conversation about our product initiatives and goals and how different people would approach our solutions.

Using user and market research, I designated 8 distinct personas to inform our product development process.

Once we’ve identified a new problem to solve, I will often start my design process on paper by writing down all of the questions this poses from a user’s perspective—questions that the person would want to have answered by viewing whatever solution I ultimately create. I also will take note of edge cases I encounter, or different scenarios where someone might use the solution.

It helps me to frame the problem from the perspective of different personas or people I know use the app. I use different approaches to mental modeling, depending on the situation, sometimes deconstructing a full experience map, other times using cartoons to visualize the emotional side of the problem.

Drawing user flows as cartoons is one approach I take to understand a problem. Using this example, I would pay attention to the anxieties the employee feels when designing a solution.

Design flows, not states

Once we’ve established direction, I move into Sketch and begin to lay out what the whole flow would look like, accounting for the edge cases I identified in my initial brainstorming session. I’ll often approach this by creating artboards for each step in the flow before I design anything, so I keep myself focused on the full interactive experience as I work.

At this point I start to break down the stories into interaction flows. I start very lo-fi, and as a result my whiteboard often looks like it has been attacked by my three year old. Eventually, I start to shake out a few directions to explore in higher fidelity that I will take into Sketch, getting feedback from my team and stakeholders where appropriate.

Starting in low fidelity keep me from getting attached to a solution too early, so I can keep my focus on the problem.

I alternate between greyboxing and moving to higher fidelity comps. I find it is easiest to convey options to certain stakeholders when they can invision what something will actually feel like. I also find it’s helpful to move into higher fidelity to test a concept I feel strongly about. This helps me evaluate its weaknesses earlier on in the process.

Building prototypes in Invision and Principle often help to explore concepts as well and get feedback from stakeholders. Few things communicate like a gif.

Exploration for a nested menu in a dropdown. By critiquing the concept using an example, we determined it added too much complexity without enough value.

Tools I use:

Designing for consistency

When I joined Degreed, one of the first projects I took on was to simplify our styleguide and pattern library. We have since gone through a redesign, but the initial work continues to influence how our pattern library is organized and how we track for consistency.

I started by going through the entire app and creating an inventory of the variations of each element. (This approach is outlined by Brad Frost as a step towards Atomic Design.) This helped the team visualize the variance in our patterns and drove conversation to simplify our buttons, color palette, and form library.

I went through the entire site and inventoried the variations of each element and style.

As we narrowed down common styles for each element, I collected those in a structured styleguide that the design team and front-end developers could reference.

I worked with the other designers and the front-end developers to land on consistent styles for each element and organized them in a styleguide.

One area that needed significant improvements was our color palette. Beyond our branded colors, we were using a slew of grays, blues, and greens, with no set rules for what each meant nor what the root color was. Working with the team of designers and front-end developers, we identified semantic meanings for each color.

Since I was working on our reporting charts at the time, I explored the best colors to use for each chart type and what order the colors should be presented in. Using the app Sim Daltonism, I tested each variation against different forms of color blindness to create an accessible pattern that could apply to our entire chart library.

When designing charts for our in-app reporting, I explored several palette alternatives and tested each one for accessibility before landing on the one we use today.

Since most of my work at Degreed is covered under NDA, these two hackathon projects serve to demonstrate how I get to a final design state

Hackathon Project: Slack integration

One goal at Degreed is to make learning a daily habit. Knowing that many of our b2b clients, and even our consumer clients use Slack and other messaging apps on a daily basis, integrating with these platforms seemed like an obvious step towards increasing engagement.

The product manager I was working with at the same shared my enthusiasm for building a Slack integration, so we were psyched when we had the chance to prototype this approach during our first hackathon. He recruited an amazing group for our team who helped us get farther than we had hoped in presenting this idea.

With guidance from Ryan and the developers on our team, I dove into Slack’s API docs to understand how their webhooks process and display data. This helped me understand the universe of what was possible, and Ryan and I started to document use cases for how we could leverage this integration. Sidenote, Slack is incredible, it turns out, and the sky really was the limit.

From there, we figured out which cases we wanted to present to the judges and I began to flesh out the details for each. Working with our incredible developers who were able to quickly draw up the JSON code, I documented what each should look like and how to present it.

Achievement “learn more about JSON than I ever thought I needed” unlocked.

Finally, I prototyped in Invision what the flow of setting up an integration should entail. We were able to demonstrate the full experience, from setup through to sending actually data, live, to the judges’ Slack. Ultimately, we won the hackathon, and our work informed the team that ultimately brought it live into the Degreed. It’s even more powerful to use it daily, and it really has helped me make learning a habit.

Hackathon Project: Profile Widget

A topic that comes up regularly is, “now that I have learned x, how do I show it off?” When the project to creating a profile widget came up in our fall hackathon, it seemed like a great opportunity to explore that problem.

When you’re working on a hack night, you have two sets of constraints - the constraints of the problem itself, and of what is feasible by your team in the time allotted. Our product manager, Reina, did an excellent job of scoping out what we wanted to present as an initial concept, while leaving space to explore long-term possibilities to support our presentation.

To agree on initial concepts, I worked live with my team over a Hangout and whiteboarded some ideas until we were all on the same page. We decided to start by presenting your total points, avatar, and top skills, and to flare the design out for future concepts to include your top three skills, your latest learning, and different embedding options.

You can see a concept of what this would look like over on my About page!

Different variations for how to iterate to a final concept for the widget.
Early exploration of how you could customize the widget on your profile.
Example of various ways you could embed this information, such as a Twitter card.