A control room for the people who keep a big festival safe and on schedule. A student project from 2025, redesigned in 2026 and built as a working prototype.

A festival runs on radios, spreadsheets and chat groups. Dashify gives each person on the team one calm screen with what they need: where the crowd is, who is where, what needs a response, and what it costs.
Teams use different tools, so nobody sees the same picture at the same time.
When something goes wrong, people lose time finding out who knows what and who should act.
A producer, a security head and a finance manager look at the same event through different questions.
The 2025 deck showed survey percentages. They were illustrative, not from a real survey, so here they are treated as what they were: starting assumptions about how festival teams work.
A student project with a classmate. We designed 11 screens for three roles: the production manager, the head of security and the finance manager. We started with wireframes, then built a dark and a light interface, a login and a clickable prototype in Figma.
Three clear roles, each with its own home. A confident dark interface in teal, with a light mode. A stylized festival map, photos, and a login that set the mood.
It was a set of pictures, so nothing could be tried or measured. It was designed for a desktop only. An alert could be seen but not handled from start to finish. The people in the field had no screen of their own.
Field event production manager
Needs an overview at any moment, to decide in real time and to prevent problems before they grow. Today he learns of a problem when it is too late.
Head of security
Needs to know where every guard is, what is happening and where the risk is. Today incident information arrives late and field reports do not match what happened.
Finance manager
Needs to keep the event in budget, follow income and control payments. Today the data sits in different places, so the full picture comes only after the event.
Field guard, one of 400
Needs to know his post, report what he sees in seconds and get his tasks, on a phone, standing up, with little time. He had no screen in 2025.
Drag the handle to compare the 2025 design with the 2026 redesign.
The same job, now as a working screen. The 2025 home showed a fixed set of cards. Now each person can show, hide, resize and move what they see, and the headcount and crowd numbers move as the day goes on.
Why: Managers need different things on different days. One fixed layout cannot fit them all.
The 2025 map was a picture with pins. The new map can be dragged and zoomed, shows how full every zone is, and opens a panel with the teams on duty there, now and next.
Why: Security needs to see a crowd building before it becomes an incident.
An alert could be seen, but not followed. Now an incident goes through five steps: new, acknowledged, team assigned, on scene, resolved. Every action goes on a timeline, and the team that is assigned gets the job as a task.
Why: Seeing a problem is not the same as solving it. Someone has to own it, and the next shift needs the story.
The same budget, now alive. Approving a payment changes the numbers at once, a category that goes over budget turns orange, and a report can be exported.
Why: A finance manager should see a deviation the moment it happens, not after the event.
In 2025 Dashify had three roles, all managers at a desk. Most people on site are guards on their feet, so the redesign added a fourth: Rani, one of 400 field guards. Everything is built for a phone, one hand and a few seconds.




Why: Seeing a problem on the ground and reporting it should take seconds, not a radio call.
A prototype in code can be tried, tested and measured. Figma pictures cannot. That is what turns opinions about the design into evidence.
Every screen has a guide that says what it is for, who uses it and what you can do. A new user, or a recruiter, should not have to guess how it works.
The biggest group on site stands up, holds a phone and has seconds. So the guard’s screens have big buttons, few steps and a clear status.
The real prototype. Pick a role, then try reporting an incident as the field guard.




I’m a designer, not a developer. I rebuilt Dashify in code by directing an AI assistant, Claude, one step at a time. I decided what each role needs, how an incident should flow and what each screen should say. The assistant wrote the code, and I reviewed every screen in the browser and asked for changes until it felt right.
I also asked it to challenge the work. It audited the 2025 version and found gaps such as no phone layout, no way to follow an incident to its end, and numbers that did not add up. I chose which ones to fix.
I wrote short scenarios for each of the four roles, such as handling a crowd alert at Gate 3, reporting a queue in two taps as a field guard, and approving a payment as the finance manager. I will measure whether people finish without help, how many taps it takes and where they hesitate. The findings will be added here.
Dashify was one of my favorite projects during my studies, and I worked on it with a classmate. I enjoyed every part of it, but it never felt finished, and I knew it could be better. Now, almost two years after graduating, I see it differently. I make better decisions, thanks to the experience and growth in between. So I came back to give it the level it deserved.
Original project, 2025: Aviya Koresh and Rotem Grava. Redesign and prototype, 2026: Aviya Koresh.