Formal moderated studies
Professional facilitators conducted sessions in observation suites, allowing the team to watch where members understood the model, hesitated, or interpreted the interaction differently than expected.
Case study 02 · WeightWatchers
Turning requirements into system behavior.
The strongest surviving evidence is not a finished screen. It is the work that made the product buildable: personas, use cases, business rules, decision flows, exception handling, and moderated testing.
Context
Information architecture before “UX” became the usual name.
This was my first full-time information-architecture position. The work connected member goals and personas to detailed interaction behavior, while accounting for the technical limitations of the early web.
Single-page applications and asynchronous loading were not yet mature. Load time and server calls shaped the interaction, so the specification had to address both user behavior and the realities of implementation.
01 · Menu Planner
A use case became a behavioral specification.
The menu-planner document did more than describe a page. It defined product states, what members could change, when information became committed, and what later actions followed from earlier choices.
The product was modeled as states and consequences.
A plan could be current or upcoming, transferred or not transferred, editable or locked, selected in whole or in part, replaced, favorited, printed, or used to generate a shopping list.
Current / upcomingThe plan’s status changes which actions remain available.
Editable / committedMoving information into the journal changes later behavior.
Whole / partial selectionMembers choose which meals become part of the journal.
Primary / downstreamPlanning produces consequences for journaling and shopping.
The design problem was a system of behaviors—not a collection of pages.
This is the central value of the artifact. It translates a product concept into explicit rules that design, engineering, product, and testing can share.
02 · Beyond the primary screen
The requirement followed the member into the real-world task.
The shopping list was treated as a downstream consequence of meal planning rather than as an isolated feature. The specification followed what members selected into the later task of acquiring ingredients.
The list had to reflect what the member actually chose.
Meals added to the plan determined the shopping list. The rules addressed aggregation, recipe context, purchase quantities, organization by store area, and the practical ways a member might carry the information away.
Derive from selected meals
Aggregate quantities
Retain recipe context
Organize by store area
Print
Email
Download
03 · Exceptions
Failure, conflict, and maintenance were UX requirements.
The use case did not stop at the happy path. It specified unavailable pages, unavailable suitable plans, conflicts with existing meals, administrative maintenance, and unresolved questions.
A usable system includes what happens when the intended path breaks.
Once information is committed elsewhere, a failure or conflict can affect more than the current screen. The document therefore addressed recovery, messaging, content availability, and the people responsible for maintaining the underlying plan set.
01
Failure
What happens when a page or service is unavailable?
02
Conflict
What happens when a meal already occupies the target location?
03
Coverage
What happens when no suitable plan is available?
04
Maintenance
How is the menu-plan set administered over time?
04 · Exercise flow
The functional flow modeled logic—not merely navigation.
The exercise flow joined user action, system response, validation, duplicate handling, favorites, Quicklist behavior, and journal behavior into one executable view of the interaction.
What the diagram makes explicit
01Members locate or choose an activity, including search and suggested choices.
02The system validates duration and intensity and handles missing or incorrect input.
03Favorites and Quicklist choices affect what is available for reuse.
04Duplicate entries and existing states change what happens next.
05The final action updates the member’s journal and returns the system to a stable state.
A sitemap could show where the exercise feature lived. This flow showed how the feature behaved.
05 · Testing
The specifications stayed connected to observed use.
I participated in extensive moderated, in-person testing. Formal sessions and quick iterative tests played different roles, but both kept the work grounded in how members actually understood the product.
Informal iterative testing
Smaller tests provided faster feedback during design. They supported revision without treating every question as requiring a full research event.
What the work left behind
The evidence attached to this job.
These artifacts also appear in the Work by Type indexes. Here they remain connected to the WeightWatchers role and the product decisions they supported.
Use cases & business rulesMenu PlannerPlan statesJournal behaviorFavorites
Downstream task requirementsShopping-list derivationQuantity aggregationPrint / email / download
Exceptions & administrationFailure statesConflictsNon-functional requirementsMaintenance
Functional flowsExercise entryValidationDuplicate handlingSystem responses
Research practiceFormal moderated testingInformal iteration
Case takeaway
Good requirements describe consequences.
The work connected member goals to rules, states, decisions, errors, and system responses. That made the intended experience understandable before implementation—and testable once it existed.
Behavioral specification and business rules
Functional flows and exception modeling
Task continuity beyond the primary screen
Moderated usability testing
Continue through the chronological portfolio.