No-code Applications
With BRYTER, I worked on tools and problems that enable businesses' legal teams, compliance departments and procurement experts to automate their workflows, build applications, and, digitise contracting.
Quick Check
Quick Check runs while the developer works. A node with a problem shows a badge in its corner: a red count for errors, an amber count for warnings, or both.
A condition on a path gets the same mark when it refers to something that no longer exists. The Quick Check button at the bottom of the canvas shows the number of errors in the module, which tells the developer whether it can be published yet.
The module with Quick Check closed.
The Quick Check pane
The button opens a pane from the bottom of the canvas. The diagram stays where it was above it, so the developer does not lose their place.
Issues are grouped by node, with errors first. Each issue says what is wrong in one line and where in the node it sits, such as the content field or one path of a condition.
The header holds everything that acts on the whole list: filters for errors and warnings with their counts, ignore all warnings, a pager to step through issues one at a time, a switch to show ignored issues, and close.
Opening Quick Check
The list opens from the bottom of the canvas and groups the issues by node, with the errors first. Nodes with nothing to fix fade back.
Selecting an issue
Selecting an issue outlines its node on the diagram and opens the node's settings on the right. The field with the problem is marked there too, with the same message.
The same problem is shown in the list, on the diagram and in the settings. Nodes without problems are dimmed while the pane is open.
Moving through the issues
Previous and next step through the list. The diagram pans so the node sits just above the pane, and the node heading stays pinned at the top of the list while its issues scroll under it.
This lets a developer work through a module from top to bottom without moving the diagram by hand.
Errors and warnings
Errors stop a module from being published and warnings do not. Warnings point at things that are likely to be mistakes, such as an email with no subject.
Because the two carry different weight, each can be shown or hidden on its own, and the badges on the diagram follow the same choice. If the selected issue is hidden by a filter, the selection clears rather than pointing at something that is no longer in the list.
Brand Centre & Theming
Theming in BRYTER had grown with the product. Base styling and two code editors sat in the Admin Console, an appearance form in service settings, navigation in the module panel and page templates on the node. The settings were placed according to how the product was built rather than how its users think about a brand.
I proposed a re-organisation into four levels: organisation, service, module and node. Each setting now sits at the level where its owner thinks about it, and each owner has one place to go.
From five places to four levels
The diagram maps every theming setting from where it used to live to where it lives now. Every setting keeps its owner. The admin owns the brand, and the developer owns the service, the module and the node. Each of them now finds their settings in one place. The page that the end user sees does not change.
Brand Centre
Theme Library became Brand Centre, the one place where an organisation's brand themes live. A theme holds the logo, typography, colours and any custom code for one brand, so an organisation that builds applications for its clients can keep a theme for each of them.
Every theme card shows the brand, its primary colour, whether it is the default and how many services use it. An admin can see what a change will reach before making it.
Editing a theme is the main action. The less frequent ones, edit code, duplicate, set as default and delete, sit together in one Actions menu, with a preview of the selected theme alongside.
One theme. Styling and code sit in two tabs, and Used by lists the services a change will reach.
Custom code, in the same place
The CSS and HTML editors used to be two more places to look. They are now one Code tab on the theme, next to Styling, with the same preview beside it.
A developer sees the base styling and the code that sits on top of it together, and the preview updates as they type.
Who can change the brand
A change to a theme reaches every service that uses it. For that reason Brand Centre is a permission of its own, and it sits with the other organisation-wide permissions when an admin edits a user.
Module: navigation
Navigation moved out of the theme and into the module, where the developer decides it. The toggles are grouped, and placement is picked from a picture rather than a word.
Node templates
A node chooses how its page is laid out. I kept Questionnaire as the default, so existing modules do not change.
The other three templates are for pages that need a different layout. Data entry shows inputs as a table, so people can add many rows on one page. Document view places the form beside the document it refers to. Confirmation marks the end of a flow.
Node: columns
A multi-input node can lay its inputs in one, two or three columns. Wide screens get the columns; narrow screens stack them.
Editor Navigation
The editor is where BRYTER developers build modules: they draw the diagram and set up each node. I reworked its navigation around two rows.
The top bar shows where the developer is: the project, the module and the save status. The row beneath it holds what they can do: find, build, inspect, history, preview and publish. Every feature below lives in one of those two rows.
Module overview
The node map shows the structure of a module. The list view shows its content, with every node as a row: type, label, content and fields. One toggle at the bottom left of the canvas switches between the two.
The list filters by node type, so a long module can be reviewed quickly, for example by checking every single-select question at once. Selecting a row opens the node's settings on the right, exactly as it would on the canvas.
Selecting a row opens the node’s settings on the right, exactly as on the canvas.
Quick find
Large modules have hundreds of nodes. Quick find sits at the top left of every screen, and recent nodes are one keystroke away.
Typing a few letters finds nodes, functions and values, and marks every match on the canvas. The developer can step through the matches, and Enter jumps to the first one with its settings open.
History
Every save is a version, and published versions are marked. Picking a version shows it on the canvas, read-only, with a banner saying so, and the bar steps to older or newer versions.
Restoring asks once and explains what will happen to the current draft. The draft becomes a version too, so a restore can always be undone.
Inspect
Inspect works like developer tools for a module. A test session walks through the module one step at a time.
The canvas marks the path taken so far, the panel shows each step as the end user sees it, and the session data lists every value the module holds. When the session ends, the data can be copied and kept as a test case.
Session started. Two nodes visited; the first input awaits an answer.
“Yes” was chosen: the condition lights up and the next step appears.
Session complete, with the full session data ready to copy as a test case.
I followed the same few rules across the three projects:
Show a problem where it happens.
Quick Check marks the node on the diagram, the issue in the list and the field in the node's settings.
Put each setting where its owner looks for it.
Theming moved from five places into four levels, and navigation moved into the module panel.
Keep the defaults safe.
Existing modules keep the Questionnaire template, new services take the organisation's default theme, and restoring an old version keeps the current draft as a version.
Use plain words for status.
Saving uses three words, and each issue says what is wrong and where it is.
Build with what already exists.
The screens use BRYTER's own component library and icons, with colour, type and spacing set as variables in Figma.