An enterprise scale redesign

Lizzy Klingen  ::  Product

Hi! Lizzy here, product designer at WorkBoard.

I moved from a large company to WorkBoard, a fast growing startup, the end of last year. There were a lot of different factors that influenced my move, but one of the things I was looking forward to was defining and taking ownership of something that would inspire people.

What are OKRs?

OKRs were something new for me. On previous teams I had been on both big and small, there was some level of goal setting at the beginning of the year or the beginning of the quarter, but things were pretty loose in terms of tracking the success of these. They also were often pretty tactical and more like tasks that I needed to complete instead of outcomes we needed to drive. I often felt like I didn’t understand the mission of my team or how it related to the mission of my company.

I’ll keep it brief, but if you haven’t heard of OKRs, this stands for objectives and key results. At the beginning of a quarter, the leadership team of an organization meets to establish where they want to drive the organization. They define visionary objectives, intended to inspire the people who work for them and to set the direction. These goals then cascade to levels of teams beneath them, defining the missions of each team but still aligning back up to those top-level visionary objectives.

One important piece of all of these objectives is that they have ways of being measured to see if they are actually being achieved, aka key results.

Here are some great pieces of thought leadership on OKRs if you are interested in learning more:

Designing for enterprise

One of my first larger undertakings when joining WorkBoard was to take a look at our existing OKR wizard (how people create and edit OKRs in our system), and reimagine the whole experience from the ground up. I had the benefit of being new to the team and could share the perspective with other first-time users and people who are new to OKRs in general.

We have a very human centric culture here which is extremely important when designing anything for people. The individuals and teams using our platform share their pain points with us not just around our software but around their daily lives and businesses. It goes beyond “I don’t know how to use x feature” and the conversation becomes richer, “I am spending 10+ hours a week preparing for quarterly business reviews instead of on more strategic activities”. You are on a human level with your users about their lives at work and not just about their usage of your software. This drives value for our users.

I find designing for enterprise fun and empowering because most people spend more than half of their waking hours at work. If I can make it easier for someone to do their job, I don’t just benefit the company that has purchased the software, I benefit the end-user. I help them progress in their careers. I help them have better work-life balance. I help them love their jobs.

Qualitative and quantitative

My approach to redesigning the OKR creator/editor/wizard was to first understand where we were. There were many areas in the past OKR wizard that were legacy and built piece by piece as the company was growing.

Ways I collected insights before starting to design:

  • I watched as customers and other WoBo employees created and edited OKRs. Some were very new to WoBo and some were very advanced and seasoned.
  • I read through our support documentation and learned from our customer success teams where they help new and existing users in this process.
  • I sat in on trainings when onboarding new customers and had meetings with customers to talk about their current experiences.
  • I read through tons of OKR content and researched competitors in the space and how they were approaching the same problem.
  • I started to look through past usage data and followed the paths that users were taking. I saw where they were clicking and where they weren’t clicking, and could prioritize areas to get qualitative feedback on.
  • I worked with my PM to understand data about the types of key results (pulling from a data source, manually entering, etc.) users were making and different data points about objectives and key results already in our system (average length of a KR, how many OKRs a user has, average number of key results per objective, etc.).

I did my best to fully immerse myself in OKR creation and editing so that my redesign would be as informed as possible.

A video of the old OKR wizard before my redesign:

A design process

Throughout this process I began to sketch and ideate with the product team on what might be a good framework for the wizard. Aligning with the team on this framework helped me to set the direction before going too far down one path.

Engineering and business decisions we worked through included:

  • Are we keeping this as a pop-up modal or will it be a page of its own? Are we rewriting the entire code base or are we hoping to retain components we are using?
  • Where is performance going to be impacted, how can I balance the user experience with system performance (which ultimately impacts user experience if the experience appears slow)?
  • What are the needs of the business right now as we are expanding and growing? Are there things we need to consider in this redesign that impact our sales cycle or the value that larger enterprise companies are looking to see?

Sketching and ideating transitioned into wireframing different pieces of content and components and where they might live on a page.

My wireframing process as I have grown as a designer and as design systems have become more of a standard device sometimes will include components from our design system rather than only grey boxes, text, and lines like the word wireframe has grown to connote. It has become faster to create what looks more like a mockup and less like a wireframe in the same amount of time.

There are drawbacks to this of course because stakeholders become more fixated on the color of something than the content itself. However, things become easier to talk about and show to users early on because it feels more real and like what they might use, rather than a hypothetical interface.

An early version of the redesign in an Invision prototype:

Walking through the early, light versions of the prototype with customers helped to shape the framework early on to cater to what made sense to people.

Some top user needs discovered included:

  • There was a level of hierarchy between the objective and key results that needed to be present for users and a way to see all of these pieces in one view.
  • There was also a need for quick, easy editing since the beginning of the quarter is when a lot of revising of OKRs happens.
  • In order to set the system up for success in the future, the key results needed to function as separate pieces. This will allow for users to edit their key results without opening the entire OKR editor.

Usability

I think it is super important when creating new design components to be aware of different types of users, different types of devices, and different types of browsers when designing for web.

Examples of things I considered during this process:

  • Testing AA and AAA compliance for all of our fonts. Being careful not to use pure black #000000, but also maintaining at least 54% opacity of black on white backgrounds in order to be AA compliant for contrast (4.5:1)
  • Click areas at least 24px x 24px
  • Prioritizing Chrome, Firefox, Microsoft Edge, Internet Explorer based on our user base — different browsers have different behavior
  • Prioritizing screen responsivity so that someone viewing at 1280px has the same experience as someone viewing at 1920px
  • Clear help hovers and tooltips to help with more complex concepts
  • A red/green colorblind friendly RAG (red, amber, green) rating
  • +more

As the interface was fleshed out, the product team reached out to super users and newer users to gain further insights and course correct along the way. Understanding a person’s behavior, wants, and needs was key to making sure that this new version would be more delightful to use than the previous. I really enjoyed collaborating with customers in this fashion because they become co-designers of the product.

Some insights we incorporated:

A human want and need for control

  • Editing objective and key results names in-line was a big want and need to shift the brainstorming process from a whiteboard to WorkBoard — this way teams can go in and edit on the fly during an OKR brainstorming session without opening any new windows
  • Changing to and from a datasource for a key result was something that got brought up in many conversations, as something might start off manual and be sourced from an integration in the future. An ability to go in and change and control the data source after creation was a big request as well.

Optimizing for the most used case

  • When looking at the existing OKRs in our system and the data we had there, we could see that the majority of them had key results where a user would go in and manually enter updates. Making this flow as easy as possible was a priority so that this most used case was quick and accessible. We optimized for this flow so a user could make 2 clicks instead of 20+ and have created an objective with a manual entry key result.

The paradox of choice

  • For people who are brand new to OKRs, having to choose from many data source options as the very first thing you do is a barrier to key result creation. A high percentage of our users create key results that they manually update or assign others to manually update. Making this flow super easy without getting rid of advanced functionality was a tricky balance but was also key for both user types.
  • We also looked into data on a lot of options we had in the interface that weren’t being used at all. With this data we could make decisions about what to retire or hide away to simplify the experience.
  • + more

A video of V1 of the shipped product:

Final thoughts

A good product is always evolving since the people who use it change themselves. Pushing out this redesign means continuing user testing and constantly looking for insights, but also an expectation that not everything is going to be perfect. A willingness to adapt based on what you observe from people creates a truly human centered product.

We are super excited as we are making improvements to WorkBoard and know our users help us to drive our roadmap, prioritize enhancements, and ultimately help people manage, operationalize, and iterate on their strategy.

I would love feedback as we are growing our product design team here at WorkBoard, so please reach out with any comments or questions.

Happy designing,
Lizzy



Like what you just read? Share it!

Like what you just read? Share it!

More Leadership Development Resources