Redesign of the application used by councillors before, during, and after meetings.

One application instead of several tools.

The most important assumption was not to add more functions but to limit situations in which a councillor has to leave eSesja.

Research indicated that during one meeting, a user could simultaneously use eSesja, a communicator, documents opened in another program, and a separate place for notes. I wanted to gather this context in one product.

Therefore, I rebuilt the application’s architecture. Instead of one dashboard where most functions were located, a permanent top bar was created with the most important context, profile, settings, notifications, and a communicator, along with side navigation leading to specific areas of the system.

Documents can now be opened directly during the session, notes are aggregated and searchable, and the calendar has become a full schedule with day, week, month, and list views. I also added a predictive search feature because, with the increasing number of meetings, documents, and notes, one cannot expect the user to remember where each piece of information is located.

Tablet first, because that’s how councillors really work.

The tablet-first approach was not a stylistic decision. Research showed that during meetings, the primary device for councillors is often the work tablet provided to them specifically for working with the system.

Therefore, I designed the main variant of the application for the tablet, not for the desktop, which would later just be scaled down. The layout is fluid, and individual areas can change their proportions depending on the task being performed.

At the same time, councillors also use eSesja outside of the meeting itself when preparing for the next session, reading documents, or checking the schedule. They may then use a personal computer or phone, which is why we ensured full responsiveness. Mobile received its own layout and behaviors, not a compressed version of the tablet view.

In the process, we also rebuilt access to the product. The project includes 2FA, login via mObywatel, and more convenient login using a QR code. This makes using eSesja on different devices not only simpler but also safer.

Different application during meetings, different between sessions.

One of the more important conclusions from the research was noticing that the same user uses eSesja in two completely different situations.

During an active meeting, the most important aspects are the current session, voting, quorum, documents, and quick access to information needed at that moment. Between meetings, voting or quorum are irrelevant. At that time, the user wants to check the next meeting, read materials, return to notes, or check messages.

Therefore, the interface changes depending on whether a session is ongoing. We do not show the user all the product’s possibilities all the time, only those that are relevant at that moment.

Working without losing context.

In the old application, many actions meant going to another screen or exiting to another application. In the new version, I focused on contextual work.

Documents, notes, or additional information are located within the application and can open in a side panel without leaving the current session. The user still sees where they are and what the material they are currently working on is about.

We treated communication similarly. One global chat was replaced with a communicator featuring private and group conversations, the ability to create custom groups, and send files and photos. This was partly to ensure that councillors did not have to move discussions about council work to WhatsApp.

The application reacts to what is happening during the session.

Research also revealed a very specific problem with voting. A councillor could be physically present at the meeting but temporarily using another application and not notice that voting had just begun.

Therefore, we designed a notification system, including push notifications about the start of voting. Instead of requiring the user to constantly monitor the eSesja screen, the product draws their attention when something important happens.

AI as another way to access information.

We also added an internal AI assistant to the new version. Its task is not to replace classic navigation or search but to create an additional way to work with the increasing amount of information in the system.

The assistant is meant to help find information and work with documents without the need to manually search through various materials. This way, eSesja is no longer just a place where the user performs specific actions, but can also help them find the necessary context.

Iterations with users instead of revolutions.

The new product was to be much better, but it could not force thousands of users to learn everything from scratch.

One of the biggest challenges was the scale of the existing user base. Although the old application required a complete overhaul, completely changing its key elements would simply create another problem. Councillors use eSesja during real meetings and have developed specific habits over the years, so we retained the placement of key functions, including voting and quorum. We changed the architecture, operating model, and capabilities of the application, but at the most important moments, the user can still rely on their memory and existing habits.

Not everything worked out the first time. A good example was the Informant, which we initially treated as another type of event. It only became clear later in the process that it serves a completely different role and requires the councillor to familiarize themselves with specific information. We had to return to earlier decisions and rebuild that part. Several iterations were also required for mobile navigation. The first versions diverged too much from the expected way of using the product, and subsequent iterations led to a simpler solution and a clearer division of the application into active session mode and work between meetings.

To avoid discovering such errors only after implementation, I connected key scenarios in an interactive prototype in Figma. Users could actually go through the new application, check the navigation, contextual transitions, and key functions, rather than just viewing static mockups. The prototype was used during user testing, and the feedback collected went directly into subsequent iterations before handoff.