The roster roller coaster
AristoTelos is a workforce management system used by thousands of employees and their managers in companies like Albert, T‑Mobile, Innogy, and Sconto. At its core is the roster, a personal work calendar. I inherited the old mobile app and rebuilt it from scratch, solo, end to end: research, IA, interaction design, spec.
What I was given
A raw data table. Information exported from a database and handed to a user with no further thought. The real problem wasn't the interface. The app was organized around how the system stores data, but ordinary employees don't care about data.
“Can we go fishing this weekend, or do you have to work?”
Answering that should take two seconds. What users care about is their time in and outside of work. Framed that way, the flaw is obvious: the app had no concept of the person using it.
I reframed the whole thing around a single question: am I working, and what does my week look like? That made the day the primary unit.
A day at work is complicated
A shift isn't just a block of time. It carries activities, parallel activities, mandatory and flexible breaks multiple absence types with meaningful differences between them that payroll absolutely cares about. Pending requests, approved ones, denied ones, manager notes, labels, legal warnings.
The user base runs the full spectrum: HR managers on one end, warehouse workers opening a work app for the first time on the other. The design had to work for both.
The goal
Give people a calendar. Something they can open and scan in seconds. At the same time, keep the roster as a reliable source of truth, where users can find everything about their shifts when they need to go deep.
The process
I mapped everything a single shift could possibly contain. Found shifts whose composition was worse than your worst nightmare and designed for those first. Setting priorities was the key: what does a person actually need to see at a glance, and what can wait until they ask for it?
Fun fact: Forklift operators are legally required to take a five-minute break every thirty minutes. No exceptions.
And that broke the timeline. Shifts with parallel activities and five-minute breaks recurring hourly throughout the day made a conventional timeline unreadable, and it got worse the more a shift contained.
The solution
Hide the complexity without losing it, and lead with the time information users actually read. So the day, the main unit, became the main component. It has two states.
Collapsed, for scanning the whole month. On the left, a calendar for orientation in time: date, day of week, holidays highlighted. Same for everyone. On the right, the essentials: when you work, what you'll be doing, absences, total hours. Plus a signal when something needs attention, so you can tell a shift you've worked a thousand times apart from one that isn't routine.
Expanded holds everything a shift can contain: properties, tags, manager notes, requests, the full schedule. There when you need to go deeper, invisible when you don't.
When the timeline failed, content categories emerged from how users actually think about their time:
- When do I work and when don't I?
- Day flow: main activities, breaks, absences.
- Do I have anything extra to do?
- Parallel activities.
- Am I working more than usual?
- Overtime.
- Anything else?
- Labels, most commonly home office.
That hierarchy is the structure of the visual solution. A regular roster looks like the one above; the same structure holds the horror shifts.
The roster isn't read-only. From any shift, an employee can raise a request, offer it up for a swap with a coworker, or leave a note for a manager. A floating action button extends the same actions to date ranges, so a five-day vacation is one request instead of five.
Attendance state is also reflected. Closed attendance, in the past: shifts that have already happened and can't be changed, though in some companies employees are still required to review and confirm them before payroll is processed. Open attendance, the current period, live and actionable. Unpublished attendance, in the future: shifts the system drafts from the rules before a manager plans the period. Suggestions, not commitments. The same component looks different in each state without changing the pattern or dropping information.
This hierarchy is the result of internal testing on an early prototype with basic data. Absences used to sit as chips attached to the top of roster items, where they broke the visual rhythm and still weren’t prominent enough for something as important as an upcoming vacation. Absences now hold the spot labels used to have, and labels sit too low in the hierarchy to earn a permanent place there.
The same logic and information hierarchy became the foundation for several other views across the app. The manager's roster swaps one employee's week for the whole team's schedule, side by side. Open shifts lets employees pick up what's available and managers assign it. The shift editor puts adjustments on the manager's phone instead of at a desk. Moving a shift start by thirty minutes. Nudging a lunch break or changing it from the ground. The kind of change that used to require a computer now takes a few taps, because the underlying model was already there.
Where it is now
Design is delivered and the app is in development. AristoTelos expects to release it by the end of this year.
The complexity didn't disappear. It just stopped being the user's problem. The same component holds a free day, a regular 9-to-5, and the most complicated shift imaginable.
That's the fishing question, fully answered: “Free this weekend, but back by Monday, because a request is still pending.”
TL;DR: “Can I go fishing this weekend?” used to take a spreadsheet, a headache, and a phone call to HR. Now it takes two seconds, because I turned a raw database dump into a calendar that also survives forklift-operator labor law. Solo. And I am even funny about it. Let's talk!