The short version
High Plains Reader sells several different things to two different kinds of people, and offers no way to sign up for any of them. I designed the account-setup system it would need: one entry point that reads intent, branches consumer from business, and assembles a setup flow whose length changes with what each person actually chooses.
A newspaper that never asks you to sign in
High Plains Reader is an alternative weekly in Fargo, North Dakota. It covers local arts, food, opinion, and culture, and like most alt-weeklies it runs on advertising. The only commercial path anywhere in the navigation is the Media Kit, aimed at businesses that want to buy ad space.
There is no membership. No subscription. No saved account of any kind. A reader who wants the arts newsletter, a print copy mailed to them, and a reminder about a calendar event has no single place to set that up, because the place does not exist yet.
That gap is the opportunity. Reader revenue has become a real line item for publishers while ad share keeps slipping, so a setup system is not a vanity feature. It is the missing infrastructure between an audience that already shows up and the products that would let them stay.
Everything a reader might sign up for already exists. None of it has a way in.
Setup is where products lose people
The pattern is well documented across digital onboarding, and it is the one any multi-product signup has to fight. People abandon setup when it feels long, unclear, or hard to finish on the device in their hand.
The named culprits
The research keeps pointing at the same three failures: progress indicators that do not tell people where they are, flows that break when someone switches from phone to laptop, and forms that ask too much before showing any value. None of these are visual problems. They are architecture problems.
The thesis
How I would architect a multi-product setup that resists each of those failure modes by design, rather than apologizing for them in copy.
Supporting context: advertising still makes up roughly 43% of industry revenue, but its share keeps shrinking, while reader membership is the line that is growing. The reason to build this is not only retention. It is a revenue stream the current site cannot collect at all.
Five products, two account types, one front door
The difficulty here is structural, not visual. HPR sells a spread of products that each ask for different information, plus a second account type entirely, and today there is nowhere to collect any of it. Setting all of that up in one coherent flow, without it sprawling into a wall of fields, is the design problem.
Reader membership
Free and paid tiers. The paid tier introduces payment and billing into the flow; the free tier must not.
Section newsletters
Feature, Arts, Eat & Drink, Opinion, Lifestyles. Multi-select, no extra data beyond an email.
Events & calendar
Saved events or RSVP. Needs nothing the account does not already hold.
Print / e-edition add-on
A physical product. Requires a verified mailing address and, if paid, billing.
Business / advertiser
A separate account type, not a product. Company details, billing contact, ad goals.
An intent fork at the top
One question decides everything downstream: are you here to read, or here to advertise? Two flows, one component set.
READER BRANCH
BUSINESS BRANCH
What the live site tells you
Before designing the new thing, I audited the existing hpr1.com, both its flows and its front-end system. Three findings shaped the work, and one of them is the kind of defect an accessibility reviewer would flag in the first ten seconds.
No commercial path except advertising
The navigation offers Feature, Arts and Entertainment, Eat and Drink, Opinion, Lifestyles, Calendar, and About. The only way to give the publication money is the Media Kit. There is nothing for a reader who wants to support or subscribe, which confirms the greenfield.
Runs on ExpressionEngine, Bootstrap 3, a Typekit nameplate
The index.php?ACT= tracker URLs give away the CMS, and the front end is Bootstrap 3 with a fixed dark navbar-inverse. The masthead is set in Abolition, headlines in Ibis Display. That is a real constraint and a real type voice. I designed the account layer to sit in front of EE and to extend that black-and-white system rather than replace it.
The homepage disables pinch-to-zoom WCAG 1.4.4 FAIL
The viewport meta tag ships with user-scalable=0 and maximum-scale=1, which blocks pinch-to-zoom. That fails Success Criterion 1.4.4, Resize Text. For a low-vision reader it is a wall, and it is ADA exposure for any organization that publishes to the public. The fix is one line, shown in the accessibility section, and it set the tone for treating accessibility as structural here.
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=0">Three directions, one chosen
The hard question was not visual. It was how to shape a setup that holds many products without becoming a long form. I sketched three structures before committing.
One long form, everything on a page
Put every product and field on a single scrolling page. Fast to build, easy to scan, no routing logic.
Rejected: collapses under the 5-to-10 question ceiling and shows a wall of fields that do not apply to most people.
A wizard with fixed steps
A classic numbered wizard. Step 1 of 6, clear and familiar, the same path for everyone.
Rejected: a fixed count lies the moment the flow branches. Free-tier readers would see steps that never apply to them.
Intent fork plus an adaptive stepper
Ask intent first, let the product picker rewrite the step list, and show a progress model that grows honestly when a choice adds work.
Chosen: the only one of the three that stays short for simple cases and still scales to the complex ones without misleading anyone.
Direction C carries one real cost: the progress logic is harder to design and harder to build. That cost is the point. It is exactly the part that separates an architecture from a form, because the flow branches constantly and a dishonest stepper is how you lose people at step three.
The variable stepper, solved
A static "step 2 of 5" breaks the instant the flow forks. My model treats the step list as derived state: the picker emits a set of required steps, and the stepper renders from that set. When a choice adds a step, the track grows and announces the change instead of silently renumbering.
How the count stays honest
The track shows completed segments in solid ink, the current step in red, future committed steps in neutral, and a step the picker is about to add as a dashed outline that slots in before it becomes current. A reader choosing the print add-on sees the track grow by one with a short message rather than discovering a surprise step later.
Why this is the hard part
Any setup where one choice changes what comes next runs into this: a selection adds work, and the interface has to tell the truth about it the moment it happens, not at the end. Get that wrong and the progress bar becomes a liar, which is the fastest way to lose someone mid-flow.
Principles I held the flow to
Inline validation on blur
Validate when a field loses focus, never on every keystroke, and move focus to the first invalid field on submit.
44px targets, whole-card hits
Every option is tappable across its full width, not just an icon. Comfortable spacing prevents mis-taps on a phone.
Progress that cannot lie
A multi-step flow shows where you are and recalculates honestly. Back navigation always preserves your choices.
Auto-save against data loss
Long flows persist a draft so a dropped connection or a closed tab never throws the work away.
The screens, including the ones portfolios skip
Mobile-first, because signups like this happen mostly on phones. These are set in the modernized HPR interface from section 10: the paper's black-and-white system, the dark app bar from its navbar, a black primary button, the one red reserved for brand and for errors. The happy path is the easy part; the state coverage below is what the work is really about.
What brings you to HPR?
We'll set up only what you need. You can change any of it later.
One decision routes the entire flow, separating the consumer and business paths before either side is asked for anything else.
Choose what you want
Pick any combination. Some choices add a quick step.
The toggles drive the rules engine. The "added 1 step" line is the honest-stepper promise made visible at the moment of choice.
Payment
$7/month membership. Cancel anytime from your account.
This step exists only because a paid tier was chosen. Free-tier readers never see it, and the stepper never counted it for them.
Device-switching is a named abandonment cause. State is the unit that travels, not the screen, so the link restores choices and position together.
Meanwhile, your newsletters are already set. Nothing else is blocked while you verify.
A pending state that still delivers value is how you avoid the dropoff between "submitted" and "confirmed."
Try a different card, or keep the free parts and add payment later from your account.
A failed payment is where signups quietly die. The rule here: never lose the reader's work, and never make a decline a full stop.
The business branch, same components, a different flow
When the fork routes to "advertise," the flow changes but the parts do not. The fields, toggles, variable stepper, review rows, and state cards are the same components from section 10, recomposed for a company opening an advertiser account. This is the clearest evidence of one system carrying two flows from a single shared kit.
Tell us about your business
We'll tailor a Media Kit and ad package to fit.
A distinct first step for businesses, built from the same field component the reader branch uses for name and email.
What are you trying to do?
Pick any. This shapes the package we suggest.
The same toggle and summary-row components from the reader picker, here driving a recommended ad package instead of a step count.
Billing contact
Where invoices and receipts should go.
Business flows branch too. A tax-exempt buyer needs a W-9 step a standard buyer never sees, and the stepper grows honestly to match.
Review your account
Nothing is created until you submit.
A review built from the same summary rows as the reader branch, with inline edit links so a fix lands on the right step.
The business equivalent of the reader's verification screen: an active account that delivers value at once while the slower human step happens in parallel.
Built to pass an inspection, not just a glance
Accessibility shaped the components from the first frame. The audit turned up a live defect on hpr1.com, and fixing it is where the approach starts.
content="width=device-width,
initial-scale=1,
maximum-scale=1,
user-scalable=0">
Pinch-to-zoom is blocked. A low-vision reader cannot enlarge text. This fails 1.4.4.
content="width=device-width,
initial-scale=1">
Zoom restored. One line removed. This page you are reading ships the corrected tag.
Errors announced, not just shown
Inline errors use aria-describedby and an assertive live region so screen readers hear them. Focus moves to the first invalid field on submit.
Nothing signaled by color alone
Every state carries a second cue: an icon, a label, a border-weight change, or a text string. On a near-monochrome palette this is not optional, it is the design.
Deliberate focus order
Tab order follows reading order through each step. The stepper update moves focus to the new step heading so keyboard users are not stranded.
Targets and contrast that pass
Touch targets clear 44 by 44 px. Ink on paper sits well above AA; the red accent is used only where it also meets contrast, never as the only signal.
This case-study page itself is the proof of intent: semantic landmarks, a skip link, visible focus rings, real alt text on the diagram and the cover, and a labeled progress model. An accessibility-aware reviewer can inspect it and find the claims hold.
HPR's black and white, extended for forms
The live site is monochrome on purpose: near-black ink, grays, white, no accent, a dark fixed navbar, Abolition for the masthead, Ibis Display for headlines. I kept that base and added the one thing a setup flow needs that an article page never did: a functional layer. One accent for brand and error, two state colors for success and pending, and a focus ring for keyboard users.
| Token / area | hpr1.com today | Account UI | Why it changed |
|---|---|---|---|
| Brand color | None · pure mono | Mono base + 1 red | A flow needs one unmistakable mark for primary brand and for error. |
| Semantic state | Absent | Success, pending, error, focus | Account states (verified, declined) have no representation on an article site. |
| Type scale | 2 display faces, undocumented | Documented 12→48 scale | Forms need predictable label, body, and heading sizes, not just headlines. |
| Spacing | Bootstrap defaults | 8pt scale | Consistent rhythm across dense form steps. |
| Form components | Search box only | Field, toggle, choice, stepper, state card | The entire account surface is greenfield. |
| Focus styling | Browser default | 3px ring, AA | Keyboard and low-vision users need a visible, consistent focus state. |
| Viewport / zoom | Zoom disabled | Zoom restored | WCAG 1.4.4. One line removed. |
| State | Primary (black) | Ghost | Danger | Behavior / a11y |
|---|---|---|---|---|
| Default | #191919 / #fff | #fff / 1.5px line | #c8102e / #fff | Native <button>, role announced, ≥44px tall. |
| Hover | Lift to #000 | Line darkens to ink | Deepen to #9d0c22 | Cursor pointer; transition 150ms. |
| Focus | 3px #1357a6 ring, 3px offset, on every variant | Visible for keyboard; never removed. | ||
| Active | Subtle press, no layout shift | Feedback within 100ms of tap. | ||
| Disabled | Opacity 0.4, no pointer | aria-disabled; not focusable as action. | ||
| Loading | Spinner replaces label, width held | aria-busy; button disabled during async. | ||
Each component ships with its states defined up front, default through loading, plus the keyboard and screen-reader behavior. That is the part that makes a system adoptable by someone who did not build it, which is exactly what working inside a client design system asks for.
What changed from v1 to v2, and why
Each of these came from walking the flow as a specific person and finding where it lied to them or made them work too hard.
v1 · Fixed "Step 2 of 5"
A standard numbered wizard with a hard-coded total carried across every path.
v2 · Derived step count
The total recalculates from the rules engine, and added steps slot in with a short message. Why: the fixed count was wrong for free-tier readers the instant they skipped payment.
v1 · Email verification blocked everything
Nothing activated until the reader confirmed their address.
v2 · Free products activate immediately
Verification gates only what needs it; newsletters start right away. Why: blocking all value behind a pending state is a known dropoff between submit and confirm.
v1 · Decline returned to an empty payment form
A failed card sent the reader back to a blank step with no context.
v2 · Decline preserves and separates
It keeps every choice, shows what already succeeded, and offers a free-only path. Why: the work was being thrown away at the exact moment trust was lowest.
v1 · Color-coded states on a colorful UI
An earlier draft leaned on green, amber, and red fills to carry meaning.
v2 · Monochrome first, color as reinforcement
States read in black and white, with color and an icon added on top. Why: it matches HPR's actual system and survives a colorblind or grayscale reading.
How I'd know it worked
No live results exist yet, so these are targets and a plan to test against them, not claimed outcomes. The targets are framed against the abandonment benchmarks in section 3.
Unmoderated task tests
Five to eight participants per path, on their own phones, completing a reader setup that includes a paid tier and the print add-on. Watch where the stepper surprises them.
The device-switch test
Start setup on mobile, resume on desktop. Measure whether choices and position both survive, and whether the resume link is understood.
Assistive-tech walkthrough
Full keyboard and screen-reader pass on the fork, the validation error, and the decline state. These are the screens most likely to fail in practice.
Funnel instrumentation
Once live, track step-level drop, the rate at which added steps cause exits, and resume-link completion, to find where the model still leaks.
What I'd carry into the next build
The interesting work here was almost never the screens. It was the rules that decide which screens exist, and the discipline to make the progress model tell the truth while those rules fire. That is the muscle any complex multi-product signup needs, where one answer can add a step, a product, or a whole second path, and the interface has to stay honest about the work remaining.
Next steps
Wire the screens into a clickable Figma prototype with real step transitions, run the validation plan in section 12, and pressure-test the resume link against real email-client behavior, which is where these flows tend to quietly break. The business branch is built to reader-branch fidelity here; the remaining gap is motion and live data.
What I'd keep honest
Raul Gomez, the publisher of High Plains Reader, asked me to take this on. It has not shipped yet, the metrics are targets rather than findings, and the screens are built to be tested next. The research and the accessibility defect on the live site are real. Commissioned by Raul Gomez, Publisher of High Plains Reader; reference available on request.