From a conference app to an events platform
- My role
- Product Designer & Product OwnerSole designer at launch; later joined by a junior designer. The team grew from three to seven people.
- Period
- 2021 → 2023in-house, alongside the freight portal
- Scope
- Product · research · IA · UX/UI · design system · ownership · QAmobile and web, participants and organisers, prototype through platform
- Product
- Events platform, mobile and webcorporate events inside the country's largest rail carrier
- Idea1 month
- To the first live release
- One conference100+ events
- In the first year
- ~80%
- Of attendees signed in during an event
- ~90 screens
- Across mobile and web
Adoption was tracked through attendee sign-ins during events.
Interfaces are reconstructed in English with synthetic event and participant data. Photographs are illustrative, not records of the original events.
Where it began
One month to the first event
A month before an internal IT conference, my department head asked what we could automate.
Event information was spread across email, printed schedules and messaging apps. I proposed a conference app and built a no-code prototype over a weekend.
With one backend engineer and one mobile engineer, we shipped a Flutter app in time for the conference. It included the programme, participants, materials, locations, notes and polls. Around 150 people used it during the event, and the company subsequently funded continued development.
I designed the product and held product ownership. The first release had no organiser interface: our team made changes through the terminal during the conference. That experience made organiser tools a priority for the platform.
How the product grew, in four screens
The order the product grew in. Each screen is shown in full further down; these link to where.
The whole of it
Designing the event around the participant
As the app expanded to multiple events, I organised the experience around the participant’s context: preparing, finding the next session, taking part and returning to materials afterwards.
One participant, one event
- Before
- Arrival
- Live event
- After
Participant
Programme · people · locations · materials · polls · questions · notifications
Speaker
Session control · questions · polls · timer · presentation · materials · attendance
Moderator
Session flow · audience interaction · questions · notifications
Organiser
Event setup · programme · participants · speakers · locations · polls · materials · communications
What is happening now
Design around what is happening now
The first version listed the contents of one conference.
Once users could join multiple events, the home screen needed to distinguish what was happening now from upcoming and past events. I made the current session the starting point, with access to the next session, locations and live interaction.
The programme opens where the participant is
The programme opened at the current session. Participants could switch between the full programme and a personalised view, using their role, department, organiser tags and favourites to narrow the list.
Current, upcoming, and a memory of the rest
Past events stayed available for finding people and materials, but were visually separated from current and upcoming events.
A clear mobile interface
I used simple navigation, large touch targets and a clear hierarchy for employees with different levels of mobile experience.
Inside the room
Make the phone part of the session
Once the session started, the audience answered back through the phone, and the speaker watched it happen.
During a session, participants could answer polls, submit questions and open materials. Speakers and moderators had controls for running the session and reviewing audience responses.
One session, two interfaces
I kept the participant view focused on session information, showing live interaction when relevant. The speaker view added session controls, questions, polls and a timer.
Polls had to work in public
A web view displayed live poll results on the room’s presentation screen.
One poll, three surfaces
- Speaker launches
- Audience votes on the phone
- Result appears on the screen in the room
One live feature fixed a post-event problem
Speakers used to promise to send their materials after a conference, and then forget. At first the app let a speaker attach files to a session.
Later the product also became the presentation control, which changed who had to act first: a speaker who wanted to present through the system uploaded the materials before the session.
The product already knew which sessions somebody had attended, so it could send them those sessions with the right files afterwards. The files people wanted after the event were in the system because the speaker had needed them to present.
A moving target
Design for an event that keeps changing
Rooms, schedules and meeting points could change during an event, sometimes with poor connectivity.
The app needed to make updates visible and keep essential information available offline.
A notification only matters if it arrives
We added an SMS fallback for operational updates when push delivery failed, including room changes and transport information.
Offline was a product state, not an accident
Participants could download an event in advance and update the local copy when connected. The programme, people, locations and materials remained available offline; live polls, questions and reactions were unavailable until the connection returned.
The offline package
Still available
Programme · People · Locations · Materials
Off until the connection returns
Polls · Questions · Reactions · Live notifications
What people did
Real behaviour was messier than the flow
I attended ten events and gathered feedback through a 45-person study after the first conference and a company survey with around 2,000 responses.
Watching people use the app revealed several gaps in our assumptions.
We expected
People would build an agenda with favourites
What happened
Some participants tapped Share rather than using the favourites control.
What I learned
Some participants saved session links in their notes app instead. Favourites had not become their preferred planning tool.
We expected
People would complete their profiles
What happened
Two participants in forty-five uploaded an avatar. For speakers, organisers often had to fetch a photo out of internal systems by hand.
Not shipped
The next step was an integration with the employee directory. It had not shipped when I left.
We expected
Raise hand would work in the app
What happened
Hardly anyone used it. The room had a simpler social protocol: people raised their hand.
What changed
We stopped mirroring physical hand-raising and kept text questions, polls and reactions.
We expected
Frictionless first login was a straight win
What happened
We printed QR codes on the badges, so anyone who had ignored the setup email still got in. As usability it worked, and it survived one conference.
What changed
After the security review, we replaced badge-based login with corporate access and added tools for organisers to help attendees sign in.
The other side
One event, two products
The participant app only worked because somebody on the other side kept the event current.
I designed the organiser interface so approved employees could create events, maintain the programme, manage participants and send updates without our team making each change. Most events were managed by one organiser, so the tools had to support that person’s full workflow.
We added lightweight onboarding and continued attending events to observe how organisers used the product.
I stayed hands-on while the team grew around it
As the team grew, I continued designing the information architecture, flows, interfaces and design system, and reviewing implementation. I also held product ownership for much of the project and mentored the junior designer who joined us.
Where it landed
A platform organisers could run themselves
The product supported more than 100 events in its first year, including conferences, corporate schools and professional competitions.
Organisers could run events independently, and participants could return to past events for contacts and materials.
I left in 2023. The team has continued releasing updates since then.
In hindsight
What I would improve in a similar project
Three things I would do differently on a similar project.
- Define behavioural analytics earlier, especially for agenda planning and live interaction.
- Formalise shared event structures and permissions when expanding beyond the first conference.
- Prioritise employee-directory integration to reduce manual profile maintenance.
Open to Senior Product Designer roles
Based in Porto, Portugal, with authorisation to work here. Get in touch about a Senior Product Designer role or to discuss my work in more detail.