What good UI and UX look like in an EPM solution

2026-07-12 · EPM

A good solution opens a report in under 3 seconds and gets a planner typing in a few clicks. If it does not, something is broken underneath - usually in the model, not the front end.

You can tell a lot about a planning solution from one number: how long a report takes to open.

Most EPM front-end discussions go straight to layout and colours. Those matter, and I have written about them in the Jedox Design System post. But before any of that, a good solution has to pass two much simpler tests: every report opens in about 3 seconds or less, and a planner gets from login to typing their first number in a few clicks. If either test fails, the design work on top does not matter, because the tool will not get used. It shall be fast and easy - everything else is secondary.

The 3-second budget

The 3-second figure is not arbitrary. Response-time research has been stable for decades: Nielsen's classic thresholds put the limit for an uninterrupted flow of thought at about 1 second, and the limit for keeping attention on the task at about 10 seconds. Google's web research found half of users abandon pages that take longer than 3 seconds. Planners do not get different brains at the office; inside a company, abandonment just looks different - the user exports to Excel once, builds their own version, and never opens the report again.

So the budget I work to has three tiers:

• Cell entry and recalculation of the visible area: well under a second, so the grid never sets the pace of the person's thinking.
• Opening a report or input form: under 3 seconds.
• Anything genuinely heavier (a consolidation run, a copy-actuals job, a large export): an explicit named action with a progress indicator, run as a background job. Never an ordinary report open that happens to take 20 seconds.

And a corollary: a frozen screen is worse than a slow one. Any action that can take more than a second gets a visible busy state. A screen that locks up with no feedback trains users to double-click and re-submit, which is where duplicate postings and phantom jobs come from.

Slow reports are a design symptom

Here is the part that connects to the cube design post: when a report takes 15 seconds, the cause is almost never the server. Decompose the 3-second budget and it is generous - rendering and network take maybe half a second, which leaves over 2 seconds for the OLAP layer, and an in-memory engine like Jedox answers a well-scoped query against a sanely designed cube in tens to hundreds of milliseconds. A slow report is doing orders of magnitude more work at read time than the screen requires. That gap is a design defect, and it usually has one of a few causes:

• On-read rules evaluated across dense consolidated areas, so one visible subtotal triggers thousands of calculations. These belong precalculated in an Integrator job, as stored values in a reporting cube.
• Oversized cubes, where every extra dimension multiplies aggregation work - the same reason I suggest keeping cubes small in the first place.
• Reports that fetch far more cells than they display: whole-dimension subsets to fill selectors, dozens of separate data calls per sheet, drill-through fired on open.
• Opening on the widest possible view instead of a small default slice - current month, the user's own entity - with drill on demand.

The fixes are design decisions, not hardware. Split input from reporting cubes, materialise calculated results, restrict rule areas, open on a narrow default, paginate long lists. A useful check: count the cells a report actually displays; if the queries behind it touch a hundred times that number, stop tuning and start redesigning. Buying a bigger server hides the problem for a quarter or two, until data growth uncovers it again.

Treat render time as a measurement of model health. If the same cube keeps producing slow reports, the cube is telling you something.

Few clicks to first number

The second test: how many clicks, and how many seconds, from login to the first number entered. In a well-built solution this is three to five clicks and under half a minute. In a bad one it is fifteen clicks through a folder tree, six empty dropdowns, and a slow report before the planner can type anything. Every extra click is paid hundreds of times per cycle across the whole planner population, so this is a cost line, not a nicety.

The way to get there is mostly about defaults:

• Role-based landing pages. A planner should not land on a library of 80 reports. The landing page should read the workflow and show their open tasks, their entity, the deadline, and one click into the input form. The folder tree stays for power users, as navigation of last resort.
• Deep links that carry context. When a workflow task says "plan cost centre 4711 for FC3", the link must open the form with cost centre 4711 and FC3 already selected. Forcing the user to re-select context the system already knows is the most common avoidable click waste in EPM.
• Remembered context. If a planner worked on Norway, Budget 2027 yesterday, the form should open there today. Last-used selections, persisted per user, remove the daily ritual of rebuilding context.
• Defaults instead of selector walls. Almost every selection is predictable: the version is whatever the workflow has open, the period is the current cycle, the entity comes from the user's rights. Each dropdown on a form is a decision the designer outsourced to a user who has less context than the designer did. A user with exactly one entity should never see an entity selector at all.

Worth noting: a wall of selectors is often a downstream symptom of too many dimensions in the cube. The click problem and the speed problem frequently share the same root cause, and the same fix.

My test is simple: log in as a real planner account, not admin, and count clicks and seconds to the first committed cell. More than five clicks means fix the defaults, not the training material.

The input form itself

Once the planner is in the form, a few things decide whether the work is fast and easy or a fight:

• The grid must feel like a spreadsheet. Planners are Excel users. Arrow keys, Tab and Enter moving predictably, type-to-overwrite, multi-cell selection. My acceptance test: enter twelve months of values for ten accounts using only the keyboard. If that is awkward, the form fails, regardless of how it looks.
• Copy-paste from Excel is a requirement, not a feature. A large share of input is prepared in Excel first, whatever we might prefer. Pasting a block must land values in the right cells, skip read-only ones cleanly, and be undoable in one step.
• Spreading exposed as usable actions. Jedox splashing turns hours of leaf-level entry into single actions, but raw syntax is expert knowledge. Offer the common operations - distribute like last year, even split, percentage change - as a small menu on aggregated cells, and keep the syntax for power users.
• Validation at the cell, in business language. "Travel cost exceeds the approved limit of 50,000 for this cost centre" beats "Error 4022: constraint violation". Distinguish hard stops from soft warnings, because real planning has legitimate exceptions.
• Save behaviour that never loses work. Nothing destroys trust faster than losing half an hour of entries to a session timeout. The user should always be able to tell whether a number is saved or pending, without thinking about it.
• Workflow status inside the form. What is still open for me, what have I submitted, and what happens when I press submit - answered by a one-line status strip and a submit button that explains what it locks before it locks it.

And keep reports and forms separate. A report optimises for scanning; a form optimises for typing. Hybrid screens that try to be both usually fail at both - too heavy to load fast as a form, too cluttered to read as a report. When someone asks for "one screen where I can see everything and also type", the better answer is a lean input form with a one-click link to the full report. Two fast artifacts beat one slow one.

The parts that usually get forgotten

A few things separate a solution that survives close week from one that generates support tickets:

• Empty and error states. Reports get designed against a full demo dataset, and nobody specifies what the user sees when a cost centre legitimately has no data, when the selection is invalid, or when a load failed. Those are three different situations and should be three different messages - not a wall of zeros where the planner cannot tell "nothing here" from "system broke".
• Measure it in production. Log report render times server-side from day one, and watch the 95th percentile during close week, not the average on an idle server - close-week p95 is routinely five to ten times the demo-day median, and it is the experience users remember. Put "under 3 seconds at p95 under close-week load" in the acceptance criteria. Clicks-to-input and login-to-first-number need nothing more than a stopwatch and a walkthrough.
• Design for the deadline day. Everything is fast with one user. The real test is forty planners on the same input cube on deadline day, splashing while a batch job runs. That is a design target, and it ties straight back to the concurrency testing I described in the cube design post.
• Language and colour. International rollouts mean planners working in their second or third language; labels like "FC3+9 vs PY ACT" are compression for the team that built the model, not for someone who touches the tool four times a year. And pair every colour signal with a sign or text - red/green alone excludes colour-blind users and fails on grayscale printouts.
• Saying no to one more column. Every added column or live KPI is paid for by every user on every open, forever. Requests arrive one at a time, each reasonable, and that is how a 3-second report becomes a 20-second report. The move is not to refuse but to price it: what does it cost in load time, and what decision changes because of it? Most requests fail the second question, and the ones that pass usually belong on a separate drill-through report, not on the screen everyone must load.

To sum up

In general it is simple: reports shall open fast, be easy to use, and look good. Most companies bring in an EPM tool to escape the Excel madness - so do not introduce a system madness in its place, with slow reports, endless selectors and forms that fight the user. And when a screen is slow or clumsy, look underneath first; the cube design is usually where the answer lives. The screen is just where the quality of the model becomes visible.