InRule

Enterprise decision-automation platform. Modernized rule-building, process modeling, and AI-assisted business-app generation.

EnterpriseAIDesign system

InRule — Nexus editor with a loan business process flow

Modernizing a mature decision-automation platform — pulling a long-running desktop product, a web product moving toward retirement, and several acquired tools onto one coherent surface where business logic stays inspectable and AI helps without taking over.

Year: 2023–2024
Role: Senior Product Designer
Company: InRule
Duration: 19-month contract
Team: Product, engineering, partner designer
Tools: Figma
Built with: Product, engineering, and a partner designer

Problem

InRule is an enterprise decision-automation company. Banks, insurers, and operations teams use it to encode the rules and processes that approve a loan, settle a claim, or route a case. By the time I joined as a Senior Product Designer on a 19-month contract, the product surface had fragmented: a mature desktop tool whose patterns long-time authors had internalized, a web product moving toward retirement, and several acquired tools that had never been unified into a single mental model.

The mandate was to bring them onto a single next-generation platform — Nexus — without throwing away the expertise that lived inside the old one. Two harder things sat under that: make complex business logic legible enough that a domain author could trust what they were looking at, and figure out how AI fits inside a product where the wrong rule has financial consequences.

Approach

One platform: Solutions, Workspaces, and what's inside them

Nexus organizes work around two top-level objects. A Solution is a product the customer is building — Loan Products, a claims-processing app, an underwriting workflow. A Workspace is the runtime experience their end users actually touch. Solutions are where authors live; Workspaces are where the business runs.

InRule — Solutions home — The unified home — Solutions, the workspaces inside them, and a stream of recent items. One surface across what used to be three.

InRule — view a Solution — Inside a Solution, every authoring surface lives under one left nav: Overview, Flows, Entities, Data, Forms, RuleSet, Simulations, Workspaces, Settings. The IA is the platform — replace it and everything else has to follow.

Workspaces, in the customer's brand

The Workspace is the boundary between authoring and runtime. Authors build it; operations teams use it. It theme-shifts to the customer's brand so it looks like part of their own product, not InRule's.

InRule — Workspaces list, with Draft and Published states — Workspace list inside a Solution. Draft vs. Published is visible at a glance — the difference between something an author is iterating on and something live customers depend on.

InRule — Workspace branded for the customer — The same Workspace rendered in the customer's brand — green for a Loan Application here. Authors stay in InRule; the people who file the claim never see InRule's chrome.

The app-builder surfaces

Each Solution composes a handful of objects: flows that move work through stages, entities that define the data model, tables that hold reference data, forms the user fills in, and the rule sets that connect them. Each one gets a dedicated editor; the chrome stays consistent so authors stop thinking about which surface they're on.

InRule — business process flow editor — The flow editor. A loan-approval process — eligibility, payment-term branches, manual handling — laid out as a graph with a stage palette on the left and an inspector on the right.

InRule — view a saved flow — A separate read-only mode for the same flow. Authors get one experience for editing and a calmer one for inspection and review.

InRule — edit a structured table — Table editor for reference data — name, type, options. Familiar enough that someone coming from the desktop product doesn't have to relearn what a column is.

InRule — form builder with input/layout palette and field inspector — Form builder. Input and Layout primitives on the left, sections on the canvas, and a Data-Model-Field inspector on the right that binds each field back to the entity it represents. The form is just a view onto the schema.

Schema Assistant: AI that respects business logic

An InRule app is a structured object — entities, fields, types, rules — not a wall of free text. So the AI generator can't just produce paragraphs. The Schema Assistant turns a written description into a real schema the rule application can hold: classes with typed properties, ready to drop into the entity model.

InRule — Schema Assistant empty state, Alfie greets the user — Empty Entities tab. Alfie — the assistant character — greets the user. Manual entry sits in the top-right (Launch Schema Assistant, Import JSON Snippet, New Entity), so the AI path is offered, not forced.

InRule — Schema Assistant intro — The assistant opens in a side panel. It asks for context — "describe the application in as much detail as you can" — and tells the user it can be corrected if it gets things wrong. The frame is collaborative, not authoritative.

InRule — Schema Assistant thinking after the user describes a healthcare payor app — The user types: "I am a healthcare payor. I need an application that will determine if a set of claims should be approved and be paid out." The assistant narrates its status — "thinking…" — instead of an unbounded spinner. The user knows whether to wait or step away.

InRule — Schema Assistant returns a generated schema — The schema comes back as a structured object — Payment and Claim, each with typed fields (Amount: Decimal, PaymentDate: DateTime, AmountApproved: Decimal). "Apply Generated Schema" is now active. The AI doesn't write to the entity model on its own — the author commits, deliberately.

InRule — Entities populated after Apply — After Apply, the assistant collapses out of the way and the Entities table is populated — Client, Work Done, Service Provider, each with a modifier and a timestamp. The author is back to authoring, with structure they didn't have to type.

The whole pattern is the same one I'd carry into Sprig later — narrated status instead of spinners, AI proposes / user commits, no silent edits to the user's source of truth. Decision automation just made the cost of getting it wrong explicit: a hallucinated rule is a wrong loan or a wrong claim.

Process Studio: visual flow design

Some processes are simpler to draw than to write. Process Studio is a BPMN-style canvas for the orchestration side of decision automation — events, gateways, tasks, end states — designed to be reachable by an analyst, not only by a developer.

InRule — Process Studio paper sketches — Paper first. Forms list, template picker, popups, the v2 navigation, a control panel. Sketching is where the IA decisions get made — before any pixel cost is committed.

InRule — Process Studio canvas with BPMN-style nodes — The canvas. Timer start, gateway, user task, send task, end — the BPMN vocabulary, with a palette docked at the bottom so the most-used nodes are one click away.

InRule — Process Studio floating overlays — Floating tool surfaces over the canvas. The author edits a node where the node is — no full-screen mode switch.

The design system underneath

None of the above survives without a foundation. The system covers the primitives — color, typography, tokens, icons — and a library of components the platform actually uses, so each acquired surface stops looking like its own product.

InRule — design system catalog — Catalog page. Styles and tokens at the top, components below — avatars, action bars, badges, buttons, cards, headers, menus, modals, navigation, pagination, pills, selects, tab bars, fields, tables, toggles, tooltips, trees. "In progress" flags are deliberate; the system is honest about what isn't done.

InRule — design system principles and tokens — Spec page for tokens — numbers, corner radii, spacing, icon sizes — each with the variable name, value, pixels, and a visual representation. Documented at the level engineers actually use.

Carrying the desktop forward, not freezing it

The hardest constraint on this kind of modernization isn't visual. It's mental. Long-time authors had spent years building rule applications a specific way, and the design couldn't ask them to relearn the basics. So Nexus inherits the concepts — entities, rule sets, decisions, simulations, the verify/test loop — even where the chrome around them changes.

InRule — predecessor Author Studio: RuleSet editor — The predecessor RuleSet editor — the surface long-time authors knew by muscle memory. Conditional-rule tree on the left, the rule expression on the right, comments threaded inline.

InRule — predecessor Author Studio: inline table editor — And the predecessor table editor. The new Nexus surfaces don't throw these away — they translate them. The vocabulary stays; the chrome modernizes.

Outcome

19 months across design-system, platform, and AI-assisted app-building surfaces. The contract ended before the long arc of adoption was visible, so I keep the outcome honest: the work contributed to the next-generation platform direction, the unified Solution/Workspace model, the Schema Assistant interaction pattern, and the design system foundation underneath them.

What I took with me: the Apply step as a trust mechanic in AI authoring tools, the Workspace as a clean theme boundary between authoring and runtime, and the discipline of carrying expert users' mental models forward when their tool changes underneath them.

Next project

Pendo