Designing a Configurable Process Engine
A workflow tool supporting users to efficiently configure, manage, and progress their day-to-day tasks.
The Process Engine is a workflow configuration tool that enables agencies to implement their own processes into the Rex PM platform — supporting users to efficiently manage and progress their day-to-day tasks in line with their unique business processes.
This is a case study of the Process Engine project for Rex Property Management where I was the sole designer working on this project.
Background
The Rex PM platform enables Property Managers to effectively manage their entire property portfolio. At its 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
We had been getting a lot of customer feedback on the task model. Tasks were helping agents keep track of jobs to be done and surface what they need to focus on — 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 the task is at and what needs to be done next to progress it.
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 purpose of this was not to come up with a one-size-fits-all process, but to get a complete 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 engaging with 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 business requirements.
Problem Statement
Agencies are process-driven, and it’s important to their brand identity that they can work to their own processes. Property Managers are always busy, and have any number of tasks on the go simultaneously. They need to be able to pick up a task and understand clearly where it is at and what needs to be done next.
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 default processes to suit their unique requirements
- Allows large–enterprise agencies to implement their own complex processes and business logic
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 that was highly configurable and deeply integrated into the system (it could even execute Javascript in an isolated environment). However, creating a workflow in this tool was overly complex — it was designed as a service for enterprise customers with their own developers, allowing them to implement workflows and essentially create their own bespoke features within our platform.
This time around, I intended to take a different approach and unlock the tool for a broader audience, so I planned upfront to trade off some of the complex features for a more accessible tool that could be used by small and large agencies alike.
Design Approach
Understanding the System
I mapped out the existing system to make sure I properly understood the points of interaction between different records and what areas this project would impact. This diagram shows how the existing tasks configuration as well as the tasks themselves will be enhanced by the new process engine.
There are two key points of interface:
- The tasks configuration where users (mostly high level administrators, managers, or directors) could create a series of subtasks and other actions to define the process for completing each type of task
- The task itself where users (mostly agents or administrators) would be completing subtasks that are defined by the process engine
Requirements Definition
From the process maps created during the research phase, I was able to define a set of functional requirements that our process engine would need in order to meet user expectations. These were prioritised by how often each requirement came up.
Some examples of requirements were:
- 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 a subtask
- Branching to different process paths based on outcomes
- Sending templated messages from subtasks
- Automations allowing templated messages to send automatically, or updating task status or other record information
- Uploading documents as part of subtask completion
- Creating related tasks off a subtask (eg a maintenance task after completing an inspection task)
Process Configuration Design
I started by gathering examples of existing workflow configuration tools to learn from (e.g. Zapier). In general there are two main types of workflow editors; a visual path editor or a flattened nested path editor. I applied both of these approaches to our task model and our functional requirements:
There were a few problems with these approaches that were resulting in a misalignment of the mental model our users had for their processes. The step-by-step workflow configuration represented the process diagrams I had created, but they didn’t represent how our users were currently managing there processes — almost always in a flat spreadsheet:
The second problem with this style of configuration was it also didn’t align with the output of a to-do style checklist. For example — subtasks in a checklist can be completed in any order (or left incomplete), but the workflow configuration presents every subtask as if it is a required step in the process.
I took a different approach and instead tried to present each subtask in a way that more closely aligned with the mental model of a checklist:
The subtasks had further configuration options based on the functional requirements, allowing them to cater for simple to-do items through to complex automated actions:
I then tested this framework by using it to build the mapped out processes from earlier in the project. At this stage I sought technical input from the engineering team to gather their feedback and ensure it was feasible to build. It was iterated on until it met the functional requirements as well as the project goals.
Task Interface
On the front end is the task interface where agents and administrators will complete the subtasks defined by the process engine. The approach for this was relatively straightforward — the task record already existed in the system and so this only required the checklist functionality to be upgraded to support the process engine working behind the scenes.
I focused on keeping the experience simple and close to checking off a to-do list—while also making sure information and actions were displayed clearly so the user had contextual cues on when automated actions would happen or when the process might branch down a different path.
Design Validation
These designs went through several rounds of prototype feedback and testing. I built several high-fidelity interactive prototypes focusing on the configuration and completion of several key processes. These were tested across different user groups—for example a typical agent completing a maintenance task vs an administrator configuring a move-out process for their office.
Some gaps were identified (such as different use cases for automated messaging that weren’t anticipated) and the designs were iterated on to address these.
Scoping it Down for an Incremental Release
This is a large project, and it was important that we could ship it in stages to make sure we were on the right track. Based on feedback and the prioritisation of the functional requirements, I hypothesised that we could get a lot of value by starting with a smaller scope that supported automated messaging.
Good communication in an agency is business-critical, and by supporting automated and scheduled messaging in our tasks we would solve for a huge pain point in our system. This would also significantly reduce the scope of the process engine, while still allowing us to build it out in the future.
I reduced the scope of the designs to the minimum requirements to allow for automated messaging, and validated these against a few key processes that were communication heavy (such as rent arrears followup).
This project is currently undergoing a technical spike aimed at releasing automated messaging and a framework for building towards the fully fledged process engine.
