Native App Redesign

The first decision was how to handle platform parity. The temptation in a cross-platform redesign is to pick one platform as the reference and adapt it, which usually means one platform gets a slightly worse version of the other. I designed one visual language that worked identically across iOS and Android at the UI layer, and only diverged where the platform required it: native pickers, native date selectors, system-level navigation patterns. Where the OS had an established convention that users expected, we used it. Where it didn't, we used ours. This kept the experience consistent for users moving between devices while respecting the feel of each platform.

The second decision shaped the interaction design. The original brief was a visual redesign, new screens, updated components, a consistent look. I pushed to extend the scope to cover motion and feedback states, which weren't in the initial spec. A content-heavy app that relies on daily image loading, newspaper covers, thumbnails, fullscreen photography, has a particular problem when content is slow to arrive. Blank and broken both read as errors. We built a set of skeleton loading states and placeholder animations that gave the user something to look at while content loaded, communicated that something was happening, and matched the visual language of the rest of the app. These were prototyped in Principle, reviewed internally, and handed to the development team with annotated support videos specifying timing, easing, and trigger conditions.

The third decision was about information architecture. The spec defined a complex structure: covers and news as two parallel worlds, each with their own category trees, favourites, offline saving, search, and settings. The risk was that users would get lost between the two modes. Rather than redesign the structure, which would have required significantly more research than the timeline allowed and would have disrupted existing users, I kept the architecture the previous app had established and invested the design effort in making navigation between the two modes fast, legible, and low-friction. The bottom toggle between Covers and News became the primary orientation device. Categories sat above the content grid, accessible but not dominant. Returning users could find their way around immediately. New users had an onboarding flow that introduced the modes before dropping them into the app.

The app shipped with a full design system built alongside the product: colour tokens for light and dark themes, native typography from each platform's system fonts, icons drawn from scratch, and a component library covering every state the development team would need to implement.

The light and dark themes were designed in parallel from the start, not retrofitted. SAPO's brand green anchored the primary interactive elements across both. In dark mode the surface palette shifted to near-black with adjusted contrast levels, and the accent and interactive colours were tuned individually rather than inverted.

Onboarding introduced the app's two core modes, Covers and News, across a short walkthrough before dropping the user into the default home. The structure was deliberate: users came to SAPO Jornais for a specific reason, and the onboarding needed to explain the product without obscuring it.

The fullscreen cover view extended the content to the edges of the device, with actions, favourite, share, archive, visit site, surfaced as a light overlay rather than a persistent bar. The cover was the product. The UI stepped back from it.

Search returned results across three content types, covers, headlines, and news, tabbed so the user could move between them without re-running the query.

Settings gave users control over their default landing section, text size, appearance mode, and the option to replay the onboarding. These were the four things users were most likely to want to adjust. Everything else was left at a sensible default rather than surfaced as a preference.