Case Study: Pirum Schedule Builder

Introducing Schedule Builder

There’s always something about rules. Hard enough to follow and adhere to let alone design. The story of Pirum’s Schedule Builder began with a requirement to take a complex process of inputting rules and make it as easy as possible, in mind that the scale of entry could be both fast and vast in scale. Likely completed by a single user under time pressure, then shared between disparate groups and therefore requiring understanding without a great deal of context. Schedules forming a crucial anchor point for lending relationships within the industry.

Not if, and, and else and other stories.

In working with Pirum, Onomatic first sat with product and tech teams to understand the exact requirements of building a schedule; a form of legal document governing the management of assets.

The natural instinct when building a rule constructor is to follow existing design patterns – taking advantage of a potentially immediate solution. However, trialling this approach clearly illustrated in the first instance that this was neither a desirable nor practicable solution due to the inherent complexity and subsequent lack of user understanding.

Rule builders are mechanical structures relying on a one dimensional interface that does not reinforce associations between parent and child blocks; crucial to building a schedule.

It was therefore a simple choice to progress and find a new solution.

Lean UX

We opted for a lean approach with rapid, prototyping, group feedback and mockups. This helped early alignment and assisted in answering some of the more intricate elements of rule building quite early on in the process. Albeit obvious; simplicity was the key component of the task – no mean feat given the complexity of the output.

Simple can be harder than complex. You have to work hard to get your thinking clean to make it simple.

Steve Jobs

Developing the idea

For such a complex issue, simple distillation is never simple. That said, we defined some of the initial experience requirements as follows:

Simplifying the journey.

We determined that the surrounding process around rule management needed to be quite one dimensional and therefore reduced the steps to be the absolute minimum for day one. You see an admin view, enter some outlining legal information, then the builder takes up the slack through a smart, see-as-you-need interface.

The key is in the board.

A common factor in every user is obvious; a keyboard. We found that many were particularly using the keyboard only in other operational applications. The additional hook being that if a user were able to input via keys only, the requirement for speedy entry could be met.

Building blocks.

A concomitant structure that would provide a means to navigate obviously with keyboard arrows made itself obvious in a grid; also leaving no ambiguity for parent child relationships. This posed some challenges particularly around multi-line input but nothing that couldn’t be overcome. It was, in fact, an opportunity for smart design solutions, driven by the user’s behaviour.

The concept also provided a means to pre-determine options to a degree that might be required in setting the next rule.

Four colours bad, two colours good.

Taking advantage of the rigid structure, and reverting to the essential and/or etc structural elements associated with rule building, colour coding was then added to clearly delineate between types.

The subsidiary benefit this added was to highlight, in crude terms, what might make good and bad rule execution. An excess of colours, ie more than two, means that the rule is unnecessarily complex and should be revised.

Nimble, simple and flexible.

Ultimately, the minimum product/version one, was a lightweight and easy to digest rules controller. The next step was to quickly augment the experience with sophisticated interactions around smaller components such as margin and limit control.

This first iteration took approximately 4 weeks from pen to code.