Plataforma E — A school communication app, designed and built

Overview

Portuguese schools run on paper. Field trip authorisations, absence notices, administrative requests, formal communications between teachers and guardians — most of it moves through printed forms sent home in a child’s backpack, signed, and sent back. Softowner had built a desktop web platform to fix this. What it didn’t have was the device its actual users hold in their hands.

Over a 300-hour curricular internship (May–June 2024), I took that platform to mobile: gathering requirements, designing the interface in Figma, and building the cross-platform application in Flutter — then documenting the architecture so the company’s developers could take it further.

Why this one is different from everything else in my portfolio: it had a real client, a real reporting line, and real constraints I didn’t set. The school group (Agrupamento de Escolas de Vila Pouca de Aguiar) had requirements. Softowner had a design direction I was asked to follow. Every decision below was negotiated, not chosen freely — which is a more honest picture of professional design work than any of my academic projects can offer.

The brief

Softowner is an IT solutions company founded in 2008 in Vila Pouca de Aguiar: equipment maintenance, systems development, websites, commercial management and point-of-sale software.

The assignment was specific: turn an in-development web platform into a simple, low-cost, cross-platform mobile app for Android and iOS. The platform’s purpose is to remove bureaucracy from school processes — authorisation requests, guardian consent, administrative procedures, absence reporting — and to create a more direct channel between teachers, administrative services and guardians.

Working method. A SCRUM-like cycle, run remotely: meetings with the company to define tasks, work submitted for feedback to both Softowner and the client school group, adjustments, next cycle. Communication ran through a dedicated Discord server with task-specific channels.

One week of training first. I had never written Dart. The first seven days went into a Flutter course — Dart fundamentals, control structures, functions, object orientation, then Flutter basics, debugging and target devices. Not the whole course; the sections that made the technology legible enough to start.

Why that detail matters: the internship was accepted knowing it sat across two disciplines, one of which I was comfortable in and one I had no foundation in. Building the thing I designed changed how I designed it — which is the finding I’d put above all the others in this project.

The constraint that shaped everything

The company asked for a direct, practical adaptation staying as close as possible to the existing website’s design.

This is worth stating plainly rather than dressing up, because it removed most of the freedom a designer would normally exercise: no rethinking of the information architecture, no reconsidering of the visual language, no proposing a different model. The design task became translation under constraint — how does a desktop layout become legible and operable on a phone, without breaking a visual system users would recognise from the desktop version?

The variables I did control:

• Structure. How the desktop’s persistent sidebar and wide content columns re-form on a narrow screen.
• Navigation model. What becomes a drawer, what becomes a bar, what becomes a header.
• Density and disclosure. What collapses into expandable blocks and what stays visible.
• Client identity. I merged the school group’s own brand elements — its typography and logo colours — into the interface, so the app reads as belonging to the school, not just to the software vendor.

The result was described in the report as minimalist, modern and immediately legible. In hindsight I’d phrase the achievement differently: the design succeeded by being unremarkable. Guardians did not need to learn a new system.

Requirements

Before any screens, I documented functional and non-functional requirements against the reference website and the school group’s needs — the step that keeps a translation honest, since it forces you to state what the system must do before deciding what it looks like.

Functional, condensed:

Non-functional: Flutter; Google Fonts (Quicksand) for consistent typography; responsive layout across screen sizes; clear icons and legible text; primary actions (authorising, completing, editing) accessible and intuitive; interactive elements visually distinct; efficient widget use for smooth performance; reusable widgets for common components; documented, organised code for maintenance.

That last pair is where design and engineering met: the requirement for reusable widgets is simultaneously a code-quality requirement and a consistency requirement. Components that exist once in the codebase cannot drift visually.

Navigation architecture

The desktop platform’s navigation had to become three coordinated layers on mobile, each with a distinct job:

The decisions behind it:

• The logo is a control, not decoration. Centred in the top bar, tapping it returns the user home. It reinforces identity and doubles as the most forgiving escape hatch in the app.
• The drawer opens by swipe or by tap. Two affordances for one action, because a single gesture is a single point of failure for less confident users.
• Active state is shown, not implied. Drawer items carry a left border when active; bottom bar items get visual emphasis. On a system with three navigation layers, “where am I” has to be answerable at a glance.
• Bottom bar icons borrow the school logo’s colours. Each icon takes a colour from the client’s own brand mark — identity reinforcement doing double duty as a colour-coded wayfinding cue.
• The drawer is personalised. Avatar plus a welcome message with the user’s name. A small thing that changes the register of an administrative tool from institutional to addressed-to-you.
• Notifications resolve at two depths. The header icon opens a popup with recent items and a red dot for unread; swiping an item dismisses it and marks it seen; a link inside leads to the full notification centre with everything regardless of read state. Quick triage in the popup, full management in the page.

Designing consent

The most interesting design problem in the project wasn’t navigation — it was making a legally meaningful decision safe to take on a phone.

A field trip authorisation is a guardian consenting, on the record, to their child leaving school premises. Getting it wrong in either direction matters. Two flows handle this:

Generic notices — acknowledgement before proceeding. The notice displays icon, title and body text. At the foot sits a Tomei conhecimento checkbox. Until it is checked, the Seguinte button stays disabled — the user cannot advance without acknowledging the content. Tapping it raises a dialog: “Declaro que tomei conhecimento do comunicado.” with two options, Não aprovo (red) and Aprovo (green). Approving returns to the notification centre; declining closes the dialog so the notice can be read again.

Field trip authorisation — decisions that can be undone. Trip details are broken into expandable blocks (destination, date and time, price, itinerary and objectives, required equipment) rather than one dense text block, so a guardian can find the specific fact they care about. Below them: Não Autorizo in red, Autorizo in green.

The part worth defending:

• Authorising updates the interface to show a cancel authorisation control, plus confirmation that an email notice has been sent.
• Declining shows a cancel control too — with no email message, because nothing was dispatched.

Why this matters: neither decision is a trapdoor. A guardian who taps the wrong button has a visible, immediate way back, and the interface tells them precisely what did or did not happen as a consequence. The asymmetry in the confirmation message is deliberate — the interface reports the actual system state rather than a generic success message.

This is Nielsen’s user-control-and-freedom heuristic applied to a consent flow, and it is the piece of this project I’d defend in an interview without any qualification.

Design to code

Between the high-fidelity prototype and the codebase sat one more artefact: interactive flow maps in Figma, laying out every navigation possibility to orient whoever built it. In this case that person was also me — which turned out to be the most instructive part of the internship.

Build environment: VS Code with the Flutter, Dart and Code Runner extensions; Java Development Kit and Flutter via Chocolatey; Android Studio with a Pixel 6 emulator for testing across scenarios and resolutions; GitHub for sharing code with the company. Material Design icons for iconography, the google_fonts package for typography.

One architectural decision worth surfacing: the app was first written with hard-coded content, then converted to array-based variables once the pages existed — preparing the structure for API and data integration without blocking progress on a backend that wasn’t ready. A pragmatic sequencing choice under a fixed deadline.

What building it changed about designing it. Designing a component and then implementing it collapses the distance between an interface decision and its cost. Debugging was the hardest part of the internship — the report calls it a test of persistence, and a fast-moving framework meant hours of research per problem. But the loop between drawing a component and making it behave is the reason this project taught me more about interface design than any brief where I only produced the drawing.

Handing it on

The final deliverable was a UML class diagram, built in PlantUML.

Class diagrams normally precede implementation. I produced this one afterwards, deliberately — as documentation for the developers who would continue the project after my internship ended. Given the codebase existed and the goal was continuity rather than planning, a diagram derived from what was actually built is more useful to the next person than one describing what was originally intended.

Delivered: requirements documentation · low- and high-fidelity Figma prototypes · interactive flow maps · a functional cross-platform Flutter application · a class diagram and documented codebase for handover.

What I’d do differently

• Test with guardians. The users are parents and legal guardians — a group spanning a very wide range of ages and digital confidence, using the app irregularly and often under time pressure. No usability testing was run at any point. Five think-aloud sessions with real guardians on the authorisation flow would have been the highest-value hour of the whole internship, and I’d now argue for it as a scoped deliverable rather than assume there was no room for it.
• Push back on the fidelity constraint, with evidence. “Match the website as closely as possible” is a legitimate client requirement, but it is an assumption about users, not a fact about them. I’d now ask what it is protecting — recognition? development cost? — and offer a tested alternative for the one or two screens where the desktop pattern transfers worst.
• Question the three-layer navigation. A drawer plus a bottom bar plus a header is a lot of simultaneous navigation for an app used occasionally. It mirrors the desktop faithfully; I never established that faithfulness was what users needed.
• Design the accessibility properties explicitly. Colour-coded icons and red/green action buttons both encode meaning in colour alone. Adding text labels, contrast checks and screen-reader semantics would matter for a group this broad — and this is precisely the gap that pushed me towards accessibility work in my MSc.

Learnings

• Constraints are the professional condition. Every academic project in my portfolio let me define the problem. This one didn’t. Working inside a client’s fixed design direction, with a reporting line and a delivery date, is a different skill from designing freely — and the interesting design decisions still exist, just in a narrower band.
• Reversibility is the whole design. In a consent flow, the value isn’t in the moment of decision — it’s in what the interface offers immediately afterwards. Cancel controls and state-accurate confirmations are the difference between a form and a system a guardian can trust.
• Building what you design changes how you design. The distance between a Figma component and a working widget is where cost lives. Having crossed it, I specify differently.
• Documentation is a deliverable, not an afterthought. Producing the class diagram after implementation was unorthodox and correct: it was written for the person coming next, not for the process I had already finished.