The screens people actually need
- An employee portal - the page opened every morning: news, policies, the canteen menu if that is what your company cares about, and next to it the things that are theirs: open tasks, requests awaiting them, their own figures.
- Application screens - the register, the record card, the board, the form. The working surface of whatever the application is for.
- Dashboards - the numbers, cross-filtering each other, next to the work they describe instead of in a separate tool. See Analytics.
- Customer- and partner-facing pages - a supplier portal, a client account page, a form somebody outside fills in.
- Role screens - the operator's tablet view with four large buttons; the director's one screen with everything summarised; the analyst's dense table.
The catalogue
Well over a hundred and fifty widgets, and the number keeps going up. Grouped by what they are for, not by what they are made of:
- Text and media - headings, rich text, quotes, images, galleries, video, file lists, logos
- Front-page furniture - hero sections with a cover and a call to action, feature grids, number tiles for the figures you want people to see, staff cards, contact cards, testimonials, pricing tables, logo strips
- Data and charts - every chart type, data tables, the exploration table, a collaborative sheet, a calendar, a schedule, a Gantt, workload, a map, a filter bar
- Records - a record form, a record card, a single field, a status picker, a save button, a feed of records
- Process - a board by status, a task list, the steps of a route
- Input - every field type: text, number, date and range, time, select, type-ahead, tags, file, slider, toggle, colour, and the submit button
- Polls and discussion - polls, comment threads, comments on a record, reactions, an inbox
- AI - a chat with an AI employee, an action button that runs one, a command palette
- Navigation - top and side menus, tabs, breadcrumbs, dropdowns, an outline, pagination, a footer, a user menu, an app switcher, a notification centre
- Layout and state - sections, containers, cards, columns, dividers, banners, empty states, loading indicators, progress bars, badges, tooltips, modals
Two things about that list are worth more than its length.
Every widget is described by properties you can read: a declared set of inputs with names and types, not a component with a hidden contract. So the editor can show you what a widget accepts, and an agent can configure one correctly without guessing.
And half of it is not decoration. A board is the board the process runs on. A chart is the same query as the report. A record form writes to the actual record. The catalogue is mostly a way of putting the platform's real behaviour on a screen, not a set of pictures of it.
And yes - an actual website
That "front-page furniture" group is not there by accident. The same catalogue builds public pages, not only internal ones:
- A marketing site - hero, features, testimonials, pricing, a contact form that files a real request into a real process rather than sending an email nobody owns.
- A product or service page, with the specifications coming from your catalogue rather than being retyped whenever a price changes.
- A landing page for a campaign, published in an afternoon and taken down when the campaign ends.
- A partner or client portal - the public face and the logged-in area on the same stack, so signing in is a change of content rather than a change of world.
That has a consequence worth naming: your public site and your internal screens can finally look like the same company. They share a theme, a type scale and a component set, so the careful brand on the website and the grey form the same customer meets after signing in stop being two different organisations.
And the practical version: the marketing page that needs the current price list, the careers page that needs the open vacancies, the partner page that needs their own numbers - those stop being integration work. The data is already here.
Bound to real things
A widget is not filled in by hand. It is bound:
- to a dataset or a model, so a table or a chart shows live data through the engine;
- to a process, so a board shows the actual tasks and moving a card moves the work;
- to a record type, so a form is the form of that record with its fields and its rules;
- to a catalogue, so a menu of product categories is the category list, not a copy of it. See Master data.
Who sees what
Two mechanisms, and they answer different questions.
Audiences decide who a page or a block is for - this section for managers, that one for the warehouse, this banner only for the sales department. One portal serving different people instead of four portals maintained in parallel.
Conditional visibility decides when a block appears at all: show the escalation panel only when the request is overdue, show the approve button only to whoever may approve. The condition is evaluated by the same predicate engine that decides process transitions - so "when is this shown" and "when may this happen" are answered by one mechanism, not two that drift.
Underneath both, the platform's ordinary access rules still apply: a widget cannot show somebody data they may not see, whatever the page says.
The application shell
Navigation, the switcher between applications, the notification centre, the user menu, breadcrumbs - the frame around the pages and not the pages themselves. It is configurable in the same way, so an application can present itself as part of your portal or as its own product.
Next
Design - how all of it is kept looking like one product.