Building Pulse from the feed to the system behind it
Pulse is an iOS app for following AI news and exploring model rankings. I designed the interface, built the app and its supporting services, and shipped it to the App Store. The design question is straightforward: what does a reader need in order to understand an update and decide whether to spend more time on it?
The answer reaches beyond the first screen. A readable card depends on the source material, the summary, the image, the publication date, and the way those pieces arrive together. Pulse gave me a way to work on that whole chain.
1. Start with the reading task
An AI release, a research paper, and a discussion about a new tool ask different things of a reader. Some updates deserve a quick scan. Others need a closer look at the original explanation or the evidence behind a claim. A feed has to help people move between those levels of attention.
Pulse brings a short account of an item together with its source and context. The summary offers a place to begin; the original material gives the reader somewhere to continue. Model rankings sit alongside the news as another way to explore the tools being discussed.
I see those as connected reading tasks. Someone might arrive through a headline and want to understand the model behind it. They might also start with a model and look for related updates. The interface needs a coherent vocabulary for both paths.
2. Give the feed a steady rhythm
The feed card puts the image first, followed by a title, a short summary, and source information. Those elements have different jobs. The image establishes a visual landmark. The title names the update. The summary adds enough context to help someone choose what to open.
Real source material is uneven. Some articles have useful images; others have none. The card therefore keeps a consistent image area and uses a branded fallback when an image is unavailable. The source badge remains in the same place in either case. Missing data can be handled without changing the rhythm of the entire feed.
That decision is also a small example of how design and implementation meet. A layout that works with the best possible content is easy to draw. The implemented component has to accommodate the ordinary variations that appear during use.
3. Build the path behind the screen
The application has separate responsibilities for collecting source material, producing summaries, storing results, and serving the reading experience. The iOS interface is built in SwiftUI, with TypeScript services supporting the product.
Source collectors use a common contract. Collection is coordinated so that one failed source can be reported independently while other collectors return their results. This matters because the product depends on a collection of outside publishers, each with its own format and failure modes.
Summary generation also has a defined shape: a Korean title, summary text, tags, and related descriptive fields. A structured result makes the next step easier to reason about. The interface can render known fields, and the system can distinguish a usable response shape from a malformed one.
There are still separate questions inside that response. A summary can fit the schema and miss the important point. It can read naturally and contain an unsupported claim. Those questions need their own checks.
4. Look at the weakest part of a summary
Pulse's evaluator considers accuracy, completeness, naturalness, and tag suitability. It records these dimensions separately and derives its verdict from the weakest score. A high score on the other dimensions cannot average away a serious weakness in one of them.
That is a useful product rule. Consider a hypothetical summary that is fluent and well organized but gets the central fact wrong. A strong average would hide the failure that matters most to the reader. Keeping the dimensions visible makes the disagreement easier to inspect.
A fluent summary still needs to be a faithful account of its source.
Automated evaluation is another judgment in the system, with limitations of its own. It can help locate problems and make comparison more systematic. Source checks and concrete failure examples remain necessary to understand what the evaluation is actually catching.
5. Make consistency travel across features
The feed card is shared across the main feed, search, bookmarks, and related items on a model's detail page. The card uses shared corner tokens and semantic colors, with spacing chosen from a common scale.
This makes a small design decision consequential. If the source label becomes clearer or the image fallback improves, that work can reach several reading contexts through the same component. Each screen can focus on its own task while presenting a recognizable piece of content.
The same principle applies to behavior. Shared notification code records an attempt, detects duplicates, and tracks delivery outcomes. Quiet hours and other sending policies belong to the surrounding workflows. Keeping those responsibilities explicit makes it easier to tell whether an event was recorded, skipped, or delivered.
These details are part of the experience even when they do not appear in a mockup. They shape what a person sees, when they see it, and whether the product behaves predictably when a request is repeated.
6. Keep the next questions concrete
Shipping Pulse connected decisions that are often discussed separately: the reading layout, the collection process, the quality checks, the app, and the release. Those parts provide different kinds of evidence. An implemented feature, a successful release, and a useful habit for a reader are different things to establish.
The next iteration should be judged through concrete reading questions. Can someone recognize why an update matters? Can they find the original source when they want more detail? Does a related model page add useful context? Are missing images and incomplete information handled clearly?
Those questions give me a better direction than adding features simply because the system can support them. They keep the work connected to a person trying to understand something.
Pulse is a product I can keep examining at every level, from a single card to the process that produced its contents. That is the part of building it I want to carry into the next piece of work: making design decisions concrete enough to implement, inspect, and improve.