Perspectives Blog

Digital product design often falls quickly into the design of UI controls. Teams sometimes default to the most visible and most salient part of a system, the user interface — text, icons, buttons, form fields, and scrolling panels that make up a digital experience.

But UI isn’t the whole story.

In fact, the best way to think about UI is framing user interface(s) as the visible top of a big collection of decisions and artifacts.

Let us show you the Helpfully digital product stack and how those artifacts interact to deliver a quality product experience.  We’ve been at this a long time, and we’ve continued to evolve our product thinking and product deliverables over the epochs of design.

The UI - The interface controls themselves. The stuff ‘underneath’ the user’s fingers or mouse pointer, that serve as the inputs and outputs of the system.

Screen flows - Teams build interfaces through a series of screens or pages (or at least ‘states’ if we’re being fully generic). The screen flows are visible by the users, though almost by definition, the user can’t see them all at once. The screen flows can be linked in a variety of ways. Progress bars, breadcrumbs, or menus indicate the screen flow, allowing linear or nonlinear paths.

Features - Features are the named list of things that users can accomplish in a system. Some tools include a lot of features, while other tools only include a single feature. Features are what a design and development team talk about when prioritizing what to do next.

‍Conceptual Model - The controlling metaphor for a tool. Simple tools (or naive teams) sometimes just use the system model — the technological way that the software works  the back-end — and build the UI on top of it. This isn’t usually a good idea, but for some simple tools, or for an MVP, it might work. But good software often includes a conceptual framing that’s closer to what’s in a person’s head, even when the user’s idea of how the thing works is quite different than how the databases are connected and named.

Design System - The design system is invisible to users. It’s a resource for the design and development teams and is the collection of all of the approved UI elements that can be used, and the recipes or rules to combine them. A thorough design system includes the granular elements and the ways to create features, screens/pages, and flows. Other terms for this include ‘human interface guidelines’ (HIG) or ‘UI library’.

Magic Moments - A way to make digital products feel special is to put in extra work into a UI element, for example making a really nifty toggle switch, or a great opening animation while the screen loads. Teams can and should create a list of their magic moments for their tool. Some magic moments can be UI elements, other situations will require teams to focus on making a certain flow ‘magical’.

‍Requirements - Requirements represent what a system should do. Requirements are what design and development teams invent and manage. While the feature that ‘answers’ a requirement is what a user can work with. Requirements are invisible to users, but are often easy to infer from the features they see and use.

We’ll come back later to talk about what’s beyond the system itself, the water that surrounds the iceberg of the product. The business model, product strategy, customer journey, and other factors shape what product teams do, even as they’re best considered as outside of the product itself.