Planning Models

Turning Visier's people planning app into a top-tier ERP platform.

Headcount planHeadcount planHeadcount plan


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


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.

Presentation slides showing my approach to the project

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.


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.

Screenshot of feedback in Dovetail

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.

A list of issues that I identified during research & interviews

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

Feedback from a colleague on the validator which reads: as a plan modeler I really appreciate the validation features and the warnings as I am customizing my first planning model for a customer - thank you!  It is easy to forget when adjusting all of the plan items so this really makes life easier!

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.

Diagram of the old vs. new model validation workflow

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.

Screenshot of the validator in action

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).

Screenshot of the validator in action

Screenshot of the validator in action

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.

What a plan item looks like

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.

Configuration options of Planning models

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.



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.



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.