LOXON Parametrisation tool
Low-code/No-code configurability for complex financial products
COMPANY
Loxon Solutions
ROLE
Senior Product Designer
EXPERTISE
Product Design
YEAR
2022–2026
What is Phoenix?
3x time faster configuration vs coding
3x time faster configuration vs coding
GUI for 10 types of parameters
GUI for 10 types of parameters
Loxon Collection built in Phoenix
Loxon Collection built in Phoenix
All Collection projects implementation
All Collection projects implementation
All Collection projectd implementation
Phoenix is Loxon's low-code configuration tool.
Every bank implementation used to be a development project: the same product rebuilt in code for each client's roles, data-set and environment, and again for every change after go-live. Loxon wanted that work to move into flexibility and configuration.
But the parameters are JSON, and the people who understood the bank's requirements are analysts, not developers.
Main objective: let business analysts build the system without writing code.
Team and my role in it
I joined the Phoenix team as a product designer, alongside developers and another senior designer. Soon after, I became its sole designer, working with six developers who shipped continuously.
I designed many parts of it, such as Graphical and Data-Event editors, the Strategy builder and Business status configuration. Along the way I learned to configure the product myself, and mentored business analysts on information architecture and layout.
Every bank implementation is a development project. The same product, rebuilt in code for each client's roles, thresholds and escalation rules — then rebuilt again for every change after go-live. Loxon needed that variation to move out of engineering and into configuration: something the team could configure during a project, then hand over for the client to maintain.
The parameters were JSON. The people who understood the bank's policy were analysts, not developers — and configuration only pays off if the person with the knowledge can act on it directly.
That was the design problem: give a code layer a form a non-developer can build in.
Team and my role in it
I joined the Phoenix team as a product designer, alongside developers and another senior designer. Soon after, I became its sole designer, working with six developers who shipped continuously.
I designed many parts of it, such as Graphical and Data-Event editors, the Strategy builder and Business status configuration. Along the way I learned to configure the product myself, and mentored business analysts on information architecture and layout.
Every bank implementation is a development project. The same product, rebuilt in code for each client's roles, thresholds and escalation rules — then rebuilt again for every change after go-live. Loxon needed that variation to move out of engineering and into configuration: something the team could configure during a project, then hand over for the client to maintain.
The parameters were JSON. The people who understood the bank's policy were analysts, not developers — and configuration only pays off if the person with the knowledge can act on it directly.
That was the design problem: give a code layer a form a non-developer can build in.
Team and my role in it
I joined the Phoenix team as a product designer, alongside developers and another senior designer. Soon after, I became its sole designer, working with six developers who shipped continuously.
I designed many parts of it, such as Graphical and Data-Event editors, the Strategy builder and Business status configuration. Along the way I learned to configure the product myself, and mentored business analysts on information architecture and layout.
Customer 360 in Loxon CollectionCustomer 360 in PhoenixEvery panel, field and label on the left is configured on the right.
Every panel, field and label on the left is configured on the right.
User research
Our business analysts were also our users. After some training I started configuring alongside them, building pages myself and mentoring them on information architecture and layout. It also meant I could test each module with them at every stage of the design process.
Three things came out of working that closely:
1. Analysts think in banking requirements. Property panels are grouped by what the analyst is deciding, in the order they need it.
2. Configuring alongside them exposed Information Architecture problems I couldn't see from outside. That led to clearer cards and a restructured Graphical editor.
3. Real client scope revealed things the demo system never did. The old mapping view became a bottleneck at real scale, and every new pattern had to hold up past the demo case.
Our business analysts were also our users. After some training I started configuring alongside them, building pages myself and mentoring them on information architecture and layout. It also meant I could test each module with them at every stage of the design process.
Three things came out of working that closely:
1. Analysts think in banking requirements. Property panels are grouped by what the analyst is deciding, in the order they need it.
2. Configuring alongside them exposed Information Architecture problems I couldn't see from outside. That led to clearer cards and a restructured Graphical editor.
3. Real client scope revealed things the demo system never did. The old mapping view became a bottleneck at real scale, and every new pattern had to hold up past the demo case.
Our business analysts were also our users. After some training I started configuring alongside them, building pages myself and mentoring them on information architecture and layout. It also meant I could test each module with them at every stage of the design process.
Three things came out of working that closely:
1. Analysts think in banking requirements. Property panels are grouped by what the analyst is deciding, in the order they need it.
2. Configuring alongside them exposed Information Architecture problems I couldn't see from outside. That led to clearer cards and a restructured Graphical editor.
3. Real client scope revealed things the demo system never did. The old mapping view became a bottleneck at real scale, and every new pattern had to hold up past the demo case.
Who we designed for, and the problems that defined the product
Laying the foundation
The tool was built on these principles, and every screen I designed had to follow them:
The canvas is a sandbox. Every page starts blank and is built directly on it.
Everything is dropped in. One gesture to add any element: pick it from the library and drop it where it belongs.
Controls live around the canvas. The toolbar handles page-level actions and the property panel configures whatever is selected, so the page stays readable while you build it.
Conceptual low-fi animation of a core interaction
Laying the foundation
Principles we defined from the start:
1. Canvas is a sandbox. Every page starts blank and gets built directly on the canvas.
2. Elements are droppable. Everything is added by the same gesture: pick it from the library, drop it where it belongs.
3. Controls live around the canvas. The canvas holds the structure; the toolbar carries page-level actions and the property panel configures whatever is selected, so the page stays readable while you build it.
The tool was built on these principles, and every screen I designed had to follow them:
The canvas is a sandbox. Every page starts blank and is built directly on it.
Everything is dropped in. One gesture to add any element: pick it from the library and drop it where it belongs.
Controls live around the canvas. The toolbar handles page-level actions and the property panel configures whatever is selected, so the page stays readable while you build it.
The tool was built on these principles, and every screen I designed had to follow them:
The canvas is a sandbox. Every page starts blank and is built directly on it.
Everything is dropped in. One gesture to add any element: pick it from the library and drop it where it belongs.
Controls live around the canvas. The toolbar handles page-level actions and the property panel configures whatever is selected, so the page stays readable while you build it.
Conceptual low-fi animation of a core interaction
Conceptual low-fi animation of a core interaction
UI anatomy
UI anatomy
Core product features
Core product features
Core product features
Graphical, Data-Event and JSON editors
Graphical, Data-Event and JSON editors
How might analysts build what developers used to code, without losing precision?
The foundation principles were laid before I joined a team: three views of the same page, switchable at any time, each answering a different question. My part was designing two of them.
In the Graphical editor, I restructured the Information Architecture, made the cards readable, and introduced saving status, content categorisation for droppable elements, language selection and other features and modifications.
I also gave the Data-Event editor clearer emphasis and designed how the two entities connect.
How might analysts build what developers used to code, without losing precision?
The foundation principles were laid before I joined a team: three views of the same page, switchable at any time, each answering a different question. My part was designing two of them.
In the Graphical editor, I restructured the Information Architecture, made the cards readable, and introduced saving status, content categorisation for droppable elements, language selection and other features and modifications.
I also gave the Data-Event editor clearer emphasis and designed how the two entities connect.
How might analysts build what developers used to code, without losing precision?
The foundation principles were laid before I joined a team: three views of the same page, switchable at any time, each answering a different question. My part was designing two of them.
In the Graphical editor, I restructured the Information Architecture, made the cards readable, and introduced saving status, content categorisation for droppable elements, language selection and other features and modifications.
I also gave the Data-Event editor clearer emphasis and designed how the two entities connect.
Graphical editor
Graphical editor
Data-Event editor
Data-Event editor
JSON code editor
JSON code editor
Graphical editor — What's on the page?
Build the page: drop panels and elements onto a canvas, name them, format them, and decide relevant properties based on requirements.
Data-Event editor — How does it behave?
Mapping: connect panels to their data sources and define the events they send each other, so clicking an element opens the right panel or links to the right database.
JSON editor
Edit the source: the underlying code itself, for the cases the visual layers can't express, and for developers debugging what they produced.
Graphical editor — What's on the page?
Build the page: drop panels and elements onto a canvas, name them, format them, and decide relevant properties based on requirements.
Data-Event editor — How does it behave?
Mapping: connect panels to their data sources and define the events they send each other, so clicking an element opens the right panel or links to the right database.
JSON editor
Edit the source: the underlying code itself, for the cases the visual layers can't express, and for developers debugging what they produced.
Inside the Graphical editor
Wireframes for the Table UI element
Wireframes for the Table UI element
Table UI element
Every element starts as a wireframe: its states, its behaviour, and everything an analyst needs to set. On the canvas it looks simple. Underneath, it carries dozens of decisions: data source, selection method, pagination, orderable columns, sort direction. The goal was to group them in the order an analyst decides, not the order the JSON file uses.
The same approach applied to every element in the library.
Table UI element
Every element starts as a wireframe: its states, its behaviour, and everything an analyst needs to set. On the canvas it looks simple. Underneath, it carries dozens of decisions: data source, selection method, pagination, orderable columns, sort direction. The goal was to group them in the order an analyst decides, not the order the JSON file uses.
The same approach applied to every element in the library.
Table UI element and property panels
Every element starts as a wireframe: its states, its behaviour, and everything an analyst needs to set. On the canvas it looks simple. Underneath, it carries dozens of decisions: data source, selection method, pagination, orderable columns, sort direction. The goal was to group them in the order an analyst decides, not the order the JSON file uses.
The same approach applied to every element in the library.
Table states on the canvas, with its property panels.
Data-Event editor
Data-Event editor
Data-Event editor
Previous version of mapping a connection
Previous version of mapping a connection
Mapping a connection between data entries
The previous version drew mappings as lines between two lists: readable with a few attributes, but a problem in volume. The redesign makes each connection a pair instead: aligned rows, labelled direction, unused sockets hidden, and the mapping listed in the property panel.
Mapping a connection between data entries
The previous version drew mappings as lines between two lists: readable with a few attributes, but a problem in volume. The redesign makes each connection a pair instead: aligned rows, labelled direction, unused sockets hidden, and the mapping listed in the property panel.
Mapping a connection in the Data-Event editor.
Mapping a connection in the Data-Event editor.
With this solution analysts build the page and map its behaviour visually, which writes to the common JSON file.
With this solution analysts build the page and map its behaviour visually, which writes to the common JSON file.
Strategy builder
Strategy builder
A collection strategy is a set of rules: if a case is in this state — follow that plan. Strategy builder is where business analysts define those plans and the states that trigger them, and change them as the project evolves.
How might analysts configure dozens of action plans and business statuses, and keep adjusting them throughout the project?
A collection strategy is a set of rules: if a case is in this state — follow that plan. Strategy builder is where business analysts define those plans and the states that trigger them, and change them as the project evolves.
How might analysts configure dozens of action plans and business statuses, and keep adjusting them throughout the project?
Action plan list
Action plan list
Action plan list
iPad sketches
Sketches and drawings
The matrix came out of a sketch: action plans down the side, business status dimensions across the top, conditions in the cells. Everything after that was a test of whether each assumption worked
Early prototype for the idea
Early prototype to test
A draft prototype to check whether analysts read the layout the way it was drawn — and whether it still worked with a few action plans
iPad sketches
Sketches and drawings
The matrix came out of a sketch: action plans down the side, business status dimensions across the top, conditions in the cells. Everything after that was a test of whether each assumption worked
Early prototype for the idea
Early prototype to test
A draft prototype to check whether analysts read the layout the way it was drawn — and whether it still worked with a few action plans
iPad sketches
Sketches and drawings
The matrix came out of a sketch: action plans down the side, business status dimensions across the top, conditions in the cells. Everything after that was a test of whether each assumption worked
Early prototype for the idea
Early prototype to test
A draft prototype to check whether analysts read the layout the way it was drawn — and whether it still worked with a few action plans
As the result: analysts can handle the layout without explanation, and it held up with up to 50 action plans, which is an edge case. At that scale one addition feature proved to be essential: hiding unused columns, so each analyst sees only the dimensions they're working with.
As the result: analysts can handle the layout without explanation, and it held up with up to 50 action plans, which is an edge case. At that scale one addition feature proved to be essential: hiding unused columns, so each analyst sees only the dimensions they're working with.
Final design of Action Plan list and its configuration
Final design of Action Plan list and its configuration
Business status configuration
Business status configuration
Business status configuration defines the states a case can hold, and the routes between them.
Business status configuration defines the states a case can hold, and the routes between them.
The analysts' own spreadsheet
The idea already existed
Analysts were mapping status transitions in a spreadsheet, starting status down the side, target status across the top, conditions in the cells.
Early prototype
Early prototype to test it
A draft version to check the layout with real statuses, and to find where conditions belonged.
The analysts' own spreadsheet
The idea already existed
Analysts were mapping status transitions in a spreadsheet, starting status down the side, target status across the top, conditions in the cells.
Early prototype
Early prototype to test it
A draft version to check the layout with real statuses, and to find where conditions belonged.
The analysts' own spreadsheet
The idea already existed
Analysts were mapping status transitions in a spreadsheet, starting status down the side, target status across the top, conditions in the cells.
Early prototype
Early prototype to test it
A draft version to check the layout with real statuses, and to find where conditions belonged.
The layout can handle up to 10 real status transitions, and conditions moved behind a cell click, so the matrix stayed readable at a glance.
The layout can handle up to 10 real status transitions, and conditions moved behind a cell click, so the matrix stayed readable at a glance.
Final design of Business Status configuration
Final design of Business Status configuration
Built for real-scale projects
Built for real-scale projects
Built for real-scale projects
Action plan configuration. Laying out what happens and when: each task placed on a timeline measured from the start date or days past due, with its channels and conditions.
Content localisation. Each label translated on the canvas, with its reuse visible before it's changed and missing translations flagged.
Communication templates. Every message the bank sends, per language, with the data that fills it, in one place.
Advanced search. Parameter can be found in seconds, even inside the JSON, with the matching line highlighted in place.
How might analysts stay in control of a configuration this large?
How might analysts stay in control of a configuration this large?
Communication templates. Every message the bank sends, per language, with the data that fills it, in one place.
Content localisation. Each label translated on the canvas, with its reuse visible before it's changed and missing translations flagged.
Advanced search. Parameter can be found in seconds, even inside the JSON, with the matching line highlighted in place.
Communication templates. Every message the bank sends, per language, with the data that fills it, in one place.
Content localisation. Each label translated on the canvas, with its reuse visible before it's changed and missing translations flagged.
Advanced search. Parameter can be found in seconds, even inside the JSON, with the matching line highlighted in place.
With these solutions, however large the configuration, nothing is out of reach: any parameter found in seconds, every label's reuse visible before it changes, and each bank's languages and messages managed without leaving the tool.
With these solutions, however large the configuration, nothing is out of reach: any parameter found in seconds, every label's reuse visible before it changes, and each bank's languages and messages managed without leaving the tool.
Results and Learnings
Results and Learnings
Results and Learnings
Avg. configuration time vs hand-written coding
3x faster
Loxon product built in Phoenix
Loxon Collection
Parameter types with a visual editor
10 types
Nr of implementations
7 projects
Avg. configuration time
vs hand-written coding
3x faster
Parameter types with a visual editor
10 types
Loxon product built in Phoenix
Loxon Collection
Nr of implementations
7 projects
Avg. configuration time vs hand-written coding
3x faster
Parameter types with a visual editor
10 types
Loxon product built in Phoenix
Loxon Collection
Nr of implementations
7 projects
Each parameter needs its own abstraction
Each parameter needs its own abstraction
I expected to find one level of abstraction that worked everywhere. Instead, every parameter type needed its own. Consistency came from the principles underneath, like always showing what a change affects and what's still unfinished.
I expected to find one level of abstraction that worked everywhere. Instead, every parameter type needed its own. Consistency came from the principles underneath, like always showing what a change affects and what's still unfinished.
Use the tool you design
Use the tool you design
Configuring pages myself, alongside the analysts, taught me more than any interview could. While parametrising the Customer 360 panel, I saw that moving it would work better, the kind of thing you only notice when you use the tool you're designing.
Configuring pages myself, alongside the analysts, taught me more than any interview could. While parametrising the Customer 360 panel, I saw that moving it would work better, the kind of thing you only notice when you use the tool you're designing.
Configuring pages myself, alongside the analysts, taught me more than any interview could. While parametrising the Customer 360 panel, I saw that moving it would work better. the kind of thing you only notice when you use the tool you're designing.
Case Study 3 - Field Collector: Loxon first business product with AI-assisted development
Case Study 3 - Field Collector: Loxon first business product with AI-assisted development
Useful links
Useful links
Useful links