Case study

Designing a Configurable Process Engine

This is a case study of the Process Engine project for Rex Property Management (Rex PM). The Process Engine is a workflow configuration tool that enables agencies to implement their own processes into the platform — and supporting users to efficiently manage and progress their day-to-day tasks.

---

Team: Product Designer (myself), Product Manager, CTO as technical advisor.

Background

The Rex PM platform enables Property Managers to a simple experience to manage their entire property portfolio. At it’s core is a task model which is used to drive action and improve the day-to-day workflows of users — ensuring tasks are logged and surfaced at the correct times. Tasks cover a range of core activities for a property manager — for example routine inspections, maintenance requests, compliance checks, lease reviews, and more.

The Problem

Tasks help agents to keep track of jobs to be done, and surface what they need to do today — but only at a high level. For example, an agent can ascertain that a maintenance request is in progress, but it’s not clear at what stage that request is at and what needs to be done next to progress the task. Agencies are process-driven, and our system is lacking in a method to support these processes.

Research and Discovery

The primary research goal was to learn more about these agency processes. I ran discovery sessions with agencies of varying sizes and structures and walked through their internal processes for various tasks — what happened at each stage of progressing a task and what roles within the agency were involved.

From this I was able to build out a set of user journey maps covering different tasks for a broad range of agencies. The goal of this was not to come up with a one-size-fits-all process, but to get a full understanding of the varying ways agencies operate.

Insights and Opportunities

The key insight from the research conducted was that agencies are process-driven, and while processes across different agencies are similar at a high level, it’s the low level distinctions that are important — and are often a core part of the brand identity of the agency.

Trying to create a one-size-fits-all process for each type of task would not solve for the entire problem, and may even drive some agencies away from using it. We needed a more flexible approach that could still provide some general processes as a starting point, but give agencies the power to customise them to suit their own individual requirements.

The Goal

Design a new task process architecture that:

• Supports users in managing and progressing their day-to-day tasks
• Gives a unified experience across all types of tasks
• Allows small–medium agencies to tweak system processes to suit their unique requirements
• Allows large–enterprise agencies to implement their own complex processes

Some History & Learnings

This isn’t the first time we have built a tool like this. In our sales and lettings CRM, I designed an “if-this-then-that” workflow engine for an enterprise customer that was highly configurable and deeply integrated into the CRM (it could even execute Javascript in an isolated environment). Building a workflow in this tool was extremely complex — it was built for the sole use of an enterprise customer with their own IT team who could write and implement workflows to essentially create their own bespoke features in our platform.

This time around, we intended to take a different approach and unlock the tool for a broader audience, so we planned upfront to trade off some of the complex features for a more accessible tool that could be used be small and large agencies alike.

Requirements Definition

From the set of process maps, I was able to define an initial set of functional requirements that our process engine would need in order to meet the market requirements. This set could also be prioritised based on how often each requirement came up.

The framework of a task is the task object itself, with a checklist of subtasks which define the process for completion of the task (as well as other related data). The functional requirements for the process engine fit around the subtasks and the configuration of the process defining those subtasks. For example:

• Assigning a subtask to a particular user or role
• Setting a relative due date on a subtask based on record fields or task creation
• Collecting input from the user of the outcome of the subtask
• Branching to different process paths based on subtask outcomes
• Setting templated messages that can be sent from subtasks
• Scheduling subtasks with templated messages to complete (send) automatically
• Triggering actions (such as sending a message or updating task status) on subtask completion
• Uploading documents as part of subtask completion
• Creating related tasks off a subtask (eg booking in an exit inspection as part of a move out task)

Design Approach

This project had two key points of interface:

1. The task itself where users (mostly agents or administrators) would be working through the defined process by completing subtasks
2. The configuration of the process where users (mostly high level administrators, managers, or directors) could modify or create the series of subtasks and behaviours

There are plenty of workflow configuration tools out there, and so I spent some time gathering examples to learn from. This gave me some different approaches to try out, but ultimately the solution would also need to fit into the existing patterns and design system of the Rex PM platform.

My approach was to wireframe out both sides, building out the framework and testing it by applying it to different process maps. Technical input was also gathered from developers to ensure feasibility. This iteration continued until I had a solution that could achieve the identified requirements as well as the project goals.

Testing and Validation

A high-fidelity interactive prototype was built focusing on the configuration and completion of several key processes. Through further calls with agencies the new process engine was tested — both the interface as well as the core functionality was validated. Feedback was synthesised during this process and further iterations were made to the prototype.

Implementation and Next Steps

At time of writing, this project is at the early implementation stage. With a validated design for the Process Engine, the next step is to work with the technical team to plan an approach for incremental release.

---

---