How we used design to understand, inform and experiment within the Rules as Code space

For the past six months, Ram, Yuguang and I have been doing a Fellowship with the New South Wales Department of Planning, Industry and Environment. We’ve been exploring and bringing to life a concept known as Rules as Code. Check out our last blog post describing what Rules as Code is and a little more about our project below.

Having the opportunity to work on a project as innovative and interesting as Rules as Code has been incredible, but has also come with a lot of uncertainty and a lot of questions. As the designer of the group, a lot of my questions have been around what value and what insights I can bring to a project that is quite technical in nature.

What I quickly realised was that the value of design in this project is the same as in any other project. It provides a way to understand and make sense of complex problems, and to envision the future of the product or service.

As this Fellowship was quite exploratory and experimental in nature, we didn’t have one defined project to build. Instead, we had a number of objectives that we wanted to achieve including:

• Building prototypes to evaluate Rules as Code and how they can be applied
• Exploring the ‘Better Rules’ processes
• Providing recommendations for future work

What I’d like to spend some time doing here is going through how design has worked in two different streams related to the outcomes above. The first stream is building prototypes and services, and the second, building processes for both Rules as Code and the Better Rules Processes.

Building prototypes and services

The most important thing for us was to use the Human-centred Design process to ensure that what we were building would be solving key user problems and addressing needs.

In the Rules as Code space especially, there are so many products that can be built off of digital rules. As a new, fairly experimental and unknown space to be working in, we had a lot of flexibility when it came to what we’d like to spend time on, and what we built. Finding out what would provide value, and what to invest time in really was one of the most difficult parts!

What did we want to build?

During our six months at the Department, we were tasked with building a number of prototypes to explore the possibilities of Rules as Code. As the term ‘prototypes’ is quite vague and we were somewhat constrained on time, we narrowed it down immediately to be a ‘Dashboard’ that could ingest a complete ruleset and then display this information in some way. While still an open and customisable prototype based on user needs, putting some constraints around what we were building was incredibly useful!

What did we do?

In design, talking to people and understanding their pain points is one of the best ways to find out what value we can provide. To uncover what this prototype would actually do, we looked into the needs of the users that were available to us — policy makers and those within the team.

We spoke with them to understand more about how rules are made and changed, asking questions about:

1. What they do day to day
2. How they approach rule creation or rule changes
3. What the rule creation process involves
4. What the rule change process involves
5. Other processes they found important in their work
6. What a ‘dashboard’ could mean to them

We then built out personas and journey maps to get a better understanding of who we were building for and what specific problems we could address.

All of this helped us get a good understanding of our user type, their problems and their needs.

Specifically, we found that policy makers and those within the team had requirements around:

• Finding out about parts of the rule they’re not as familiar with
• Making rules as simple as possible
• Simplifying the rule development process through added visibility of relationships between concepts and methods
• Validated and easy to use calculators and other services

With this information, we were able to ideate and experiment with our prototype.

What was our first prototype?

Our first prototype was a Policy Makers Dashboard, that could be used to assist in understanding, making and changing the rules.

As a first pass, we kept it simple — only creating features such as searching a ‘variable’ that existed in our code base containing the rules, and displaying the purpose of the variable and where it is used.

We continuously tested!

To ensure that we were always making a prototype that would be useful, we tested every Sprint with policy makers and those within the team. We kept it really short and simple and set up half hour meetings to ask them some questions. Specifically, we asked them to assess when, how and why they would use these features, and asked them to note what they liked and what they disliked.

As sprints went on, we iterated and discovered more and more features that would be useful to our users. If only time permitted us to create and test all of them! Instead, what we did was build the foundations for some of these new features, including calculation and comparing activities across different methods and different schemes.

What now?

While there’s more work to be done to build a useful and implemented product, what we have found is that using a Human-centred Design approach to build our prototype means that we are able to continuously evaluate and validate current designs, as well as inform all of our new ideas.

Building the rules and the Better Rules process

The second ‘stream’ of design work in this project focussed on actually building the rules and the processes around that. Specifically, this meant coming up with methods of visualising and mapping rules, as well as participating and iterating on the Better Rules process.

What is the Better Rules process?

The Better Rules process is all about bringing together multidisciplinary groups to develop policy and rules. It’s an important step in Rules as Code, ensuring that different roles and expertise are involved in creating the logic and definitions around rules. This process helps make sure that rules are defined well enough, and that products or services can be built from them.

So where does design come in?

As this is quite a complex process, design is certainly something that can provide a lot of value in simplifying and making sense of these ideas. Specifically, it ensures that the artefacts produced make sense for the specific question they’re trying to answer, and that user needs and use cases can be considered at every stage of rule creation.

There are many different processes and artefacts that have been really valuable in helping us create and interpret the rule. From concept mapping, to decision modelling and user flows — all these artefacts have given us a different frame of reference when it comes to understanding and revising the rule.

One incredibly valuable artefact we’ve developed over the course of the Fellowship is a type of visualisation and mapping that we’re calling ‘Variable Mapping’.

What is Variable Mapping?

Variable Mapping is something completely new that our Fellowship team created! It’s a method of mapping that essentially acts as a middle ground between the rules and code.

What it allows us to do is look at a part of the rule from the perspective of Inputs, through some Logic or Calculation, to Outputs (which is essentially how the rules would work in code).

This helps us understand what elements and variables would be necessary from a code perspective, as well as allow us to really frame the rule from a development point of view.

We also made sure to test it with more complex versions of the rule to ensure that it could be used across the entire ruleset. While some maps would get undeniably complex, we found that Variable Mapping was still a valuable and necessary method that could be used for these larger, difficult parts of the rule as well.

Basically, Variable Mapping would be an incredibly useful tool for all Rules as Code projects!

How did we come up with Variable Mapping?

The Safeguard Rules are extraordinarily complex, with a lot of different calculations and eligibility requirements.

The very first time we saw part of the rule set and started coming up with ways of visualising it was when our Government host gave us an example Rules as Code task to experiment with. Even at this early stage, when we had no other experience with Rules as Code, we were already visualising and working with the rule in this very specific way.

From the outset, we were already trying to imagine what would be inputted, what would be required for the calculations or the logic processes, and what the final outputs of this process would be.

We found that Variable Mapping was incredibly useful, and really brought to light a visualisation need that was not currently being addressed. Once we realised that there needs to be some middle ground between rule text and code, we decided that variable mapping could fill this need.

How did we use it?

Basically, variable mapping was our method of visualising how the code should work.

It lets us understand what would be the inputs (and within that, which variables would require user input or which were constants or parameters), as well as what the outputs would be (and in a lot of cases, this would be the outcome that is presented back to a user).

Having this information earlier in the development process allowed us to ask important questions and for clarifications before actually coding rules.

Takeaways

Our Rules as Code Fellowship with the Department has been incredibly interesting and successful! We’ve done a lot of discovery research to understand the space a little better and created a lot of products, processes and tools that are really useful and will help guide the work of the Department in the future.

Here’s a couple of key takeaways from our work:

• The Human-centred Design process was an incredibly valuable and useful tool for us to test and iterate on what we were building. We should definitely take the time to research, and understand what products will be useful and why before building anything.
• The way that we initially made sense of very complex concepts (Variable Mapping) became a great tool to share and teach to others, to help them make sense of it too. As there are no other tools that allow for the same thing, Variable Mapping really will become an important part of Rules as Code processes.
• Design is incredibly important in validating the current state and ideating the future of Rules as Code products. It’s important to take stock of what we’ve already built, and what the future of a product or service is. Design definitely helps us do this by promoting testing and validation as an important part of the process!

Rules as Code is still a mostly uncharted space to work in and there’s still a lot to learn, but its clear that design will definitely play an important role in its future!