Planning Models

Overview

The goal of this project was to improve the UX of working with Planning models in Visier. Over a few months, a small team of developers and I shipped:

• a validation workflow for Planning models
• a wizard for creating components of a model
• cleaning up and consolidating settings, inferring automatically where possible
• in-app explanation for every configuration setting
• system-wide error prevention
• terminology improvements
• smart defaults

Introduction

Visier People: Planning started as a way for businesses to plan their headcount & costs. Over time, customers had new ideas for how they wanted to use Planning, and we had new ideas for business problems we could solve with Planning.

To do this, we needed to turn Planning into a platform, and allow people to create custom models for Planning that could be configured to plan anything; from workspaces to FTE. My role was to deliver impactful UX improvements with minimal resources to enable the creation of new Planning models.

Getting started

Before jumping into design, I first made sure everybody was on the same page about what we were trying to accomplish and why. I spoke with product management, development, and my manager to understand how this project contributed to Visier's business goals, which would inform how we should approach the work.

This was a new business area, so we didn't want to go all-in right away. The ideal result would be the ability for our internal Solution Developers to quickly and easily create (and sell) new Planning models. The UX didn't need to be perfect, just good enough.

Research

Part of the work was identifying which problems to address. Only a few people had created or edited models before, so I spent time interviewing them and learning about their workflow to find areas for improvement.

Common themes included:

• lack of guidance
• no visibility into errors or problems
• arcane configuration settings
• no documentation or in-app help

Through this research phase, I documented a set of issues that we then prioritized based on severity and estimated design & development cost.

We kept our minds open to completely recreating the UX from scratch, but ended up building on top of the existing experience for resourcing reasons.

Model validator

The first improvement we made was the model validator. Building a model is all about tweaking and testing, and it used to be a real pain.

Before the validator, working with models felt like punch-card programming; it took forever, and there was no guarantee that your model would even work.

To create the validator, I worked with developers to determine the conditions that would cause a model to fail. The validator would check these conditions, and report whenever something went wrong with a clear description of the problem and a link to where to fix it.

We surfaced warnings on the overall model view, as well as within the sub-view of any problematic model components (e.g. an input or a plan item).

We created this state flow to determine when a model should be considered valid, unvalidated, or invalid.

Guided creation

To create a model, you need to create inputs (the data the model will use) and plan items (the data that will be planned). The app supported this, but didn't support the user very well. When an object was created, it simply popped into the list of existing objects (sometimes users wouldn't even notice something happened).

In addition to this, opening the object would throw you right into the deep end of configuration.

To make creating objects a bit easier, we introduced guided creation workflows that would only ask for the bare minimum required to set up a functional object. This helped creators work faster, going into configuration only when they needed to.

Reworking configuration

Another difficulty in creating Planning models was understanding just what each setting did. Not only was there no documentation, but the setting names themselves were a bit unclear.

I audited every setting and option that could exist within a plan model, and worked to eliminate ones that could be derived from somewhere else or could be determined programmatically.

A good example of this is the rollup & distribution setting; these were distinct settings, but only certain combinations of options were valid. We combined these into a unified setting so users could only pick options that would work.

Help

Another part of the UX that was lacking was help. After pruning the configuration, I wrote descriptive help text for each setting. More complex settings got long-form explanations with examples.

Conclusion

This was a fun project where I got to work on the whole spectrum of UX issues. There's still a lot more work to do, but working closely with users and seeing immediate feedback has been very rewarding.