WorkNumber 01Dow Jones

One mobile app for two news products, built to take more

A shared mobile platform that brings two professional news products into a single app, structured so the next product can be added without a rebuild.

Role: Product design lead at Wongdoody
Scope: Discovery, journeys, interaction and UI design
Platform: iOS, built in React Native
Year: 2026

The app's home feed in light and dark themes, in English and Japanese, with the product switcher open

The problem

Professionals read business news between meetings and on the train, but the publisher's two subscription products lived apart. The brief was one app for both, and for whatever came next.

The project began with no finalized UX or UI specification and more than fifteen open questions in the requirements document. The app had to serve two audiences in two languages on day one, and stay flexible enough that a third or fourth product would not need its own design and build.

What I did

I put discovery ahead of design. We interviewed product, engineering and client stakeholders until the open questions were closed, defined the two audiences, mapped the five journeys the app had to support, and then designed the experience on the client's existing design system.

open requirements resolved before design started: 15+
products and two languages in one app: 2
future products the structure was planned around: 3

Starting without a spec

With that many unknowns, drawing screens first would have meant drawing them twice. I started by taking stock of what already existed: every component in the web product, whether it had a mobile equivalent, and whether it could be reused or needed rethinking for touch.

Spreadsheet listing each interface component, whether it exists on mobile and on web, and notes on reuse — The component audit. Most components existed only on the web, which showed how much of the app was new work.

What discovery changed

Structured interviews did more than fill in blanks. Three findings changed what we built.

The hard decisions were organizational: Where the product switcher lives, how much content is cached offline, and what readers are allowed to share were all settled with stakeholders before any design work began.
Version one was never just two products: By interviewing the owners of the products due to follow, we learned the same foundation would have to carry Factiva, Risk Journal and GRI. That shaped the navigation and theming.
Translation was not the whole localization story: Japanese readers wanted to switch an article into English, in part to practice the language. That one insight changed the design of the article view.

Four flow diagrams: sign in and land on top stories, browse and read an article, receive and act on an alert, and switch products — The core journeys: authentication, reading, alerts, and switching between products.

Key decisions

Decision

Switch products from the header

Both products share one shell. Tapping the product name opens a switcher; choosing another product swaps the content, the language and the branding in place. Adding a product means adding a row.

Trade-off. A shared shell means every product inherits the same navigation model, so that model had to be simple enough to suit all of them.

Decision

Copy link, not share

Compliance rules limited how subscriber content could be passed around. Rather than offer a share sheet we couldn't stand behind, the article view has save and copy link.

Trade-off. Readers lose one-tap sharing to other apps. They keep a way to get back to an article and to pass on a reference.

Decision

An English toggle on Japanese articles

Because readers asked for it, switching to the original English article is a control in the article view itself.

Article screen with numbered annotations explaining tags, font size, save, copy link, summary and metadata controls — The annotated article view: editorial tags, a quick summary, three font sizes, save, copy link, and metadata for internal users.

Built on the system that existed

The interface uses the client's Index design system. That gave us dark mode and multilingual typography without inventing either, and kept design and engineering working from the same components in Figma and Storybook.

Design file showing the home feed in light and dark themes, in English and Japanese, the product switcher open, and an offline state — Light and dark, English and Japanese, the switcher open, and the offline state.

The home feed running on a phone, with region tabs and a list of headlines — The home feed in a working TestFlight build.

Where it stands

The app reached a working build on TestFlight, on a structure designed to take the publisher's other products without a rebuild.

The result I value most is less visible: every design decision traces back to a requirement someone confirmed, because the questions were answered before the screens were drawn. Next I would want to watch how often readers switch products and use the English toggle, since those are the two bets the structure rests on.