One app instead of nine

Most organisations do not have an HR problem. They have a where is it problem. Leave sits in one tool, tasks in another, the policy nobody can find is a PDF in a shared drive, the job you are hiring for is on a portal only recruitment logs into, and your own goals are in a document your manager wrote in January and neither of you has opened since. Every one of those tools works. The cost is in the seams between them.

This is a concept for closing those seams: a single signed-in place holding performance, tasks, the HR portal, an internal wiki, careers, and the record of who does what. It was designed for one organisation, but nothing in it is specific to that one, which is why the marks are off the screens here. It could be yours.

Starting with the map, not the screens. The first four boards are not interface at all. They are the architecture argued out: a matrix of phases against verticals, then a site map exploration, then the same map deliberately converged and diverged, then the final one. That order matters. Every all-in-one product fails the same way, by becoming a drawer of unrelated tools behind one login, and the only defence is deciding early what belongs together and what merely arrived together.

The converging and diverging board is the one that did the work. Work management, workflow references, employee management, about the organisation, contacts, all fanned out into their real contents and then pulled back to a single home. What came out of it was six doors rather than a menu of thirty items.

The problem with a home screen for everything. A landing page for an all-in-one product has to answer a question no single-purpose tool ever faces: what am I here for today? A list of thirty links answers it badly, because the person scanning it is not browsing, they are on their way somewhere and being slowed down.

So the home is an illustrated field of the work itself, with six tiles under it: About Us, HR portal, Career, Wiki, Performance, Task Management. Six is small enough to take in without reading. The illustration is doing real work too, not decoration: it is the reason the screen does not feel like an intranet, and it buys the tiles enough visual quiet to be scanned in one pass.

Performance, shown as a shape rather than a score. Appraisal interfaces usually fail by being honest only once a year and hostile the rest of the time. The performance view answers a different question, the one people actually ask: am I on track this week? A ring for progress, a weekly line for work against timing, and four plain counts, total, done, doing, open. The month view repeats it as twelve rings so a year reads as a rhythm and a bad March is visible as a shape, not buried in a spreadsheet.

Nothing here needs a number to be interpreted before it means something. That is the point. The instant a metric needs explaining, people stop looking at it, and an unlooked-at dashboard is worse than none because it still gets cited in reviews.

The wiki, and refusing to be clever. The internal knowledge base opens on a line that sets the tone: we are not into rocket science, everyone is capable. Then a search field and faceted filters by phase, category and space. The UX problem in every company wiki is not storage, it is that people do not believe the answer is in there, so they ask a colleague instead and the wiki decays further. The fix is not more documents. It is search that returns something on the first try and filters that match how work is actually grouped, which is why the facets are phases and spaces rather than departments.

Hiring, from both sides of the table. Careers carries the same job list twice over, in two different interfaces, because two different people need it. A candidate gets search, filters and a Refer button. The recruiter gets the pipeline as four counts, applied, reviewed, interviewed, offered, with each role showing where its applicants have got stuck and when. One dataset, two products. Building it once and styling it twice would have served neither.

Leave, where most HR tools lose people. The approval queue is deliberately dull and dense: who asked, what type, the dates, how much they have taken against their balance, and Approve or Reject in the same row. No modal, no second screen, no navigating away and losing your place. A manager clearing eleven requests on a Monday morning is the real user here, and the measure of the design is whether that takes two minutes or twenty.

What it would do for an organisation. Fewer tools is the obvious answer and the least interesting one. The real gain is that the same facts stop being kept in several places at once. When leave, capacity, tasks and goals sit in one system, a manager approving time off can see what it costs the sprint, and a review can be based on the record rather than on memory. It also makes the quiet things visible: who is carrying too much, which roles have been open too long, which policies nobody has ever opened.

The task view integrates with ClickUp rather than replacing it, which is the honest position for a concept like this. An all-in-one product that insists on owning every workflow will lose to the tool teams already like. One that absorbs the reporting and leaves the doing where it is has a chance.