One User Type, Five Real Users

Requirements documents love the word "user." One word, one login, one set of permissions. Real businesses are rarely so tidy.

A regional accounting firm needed a client portal: businesses upload tax documents, track year-end filing tasks, receive status updates. The firm had already written requirements, engaged a development team, and received a first version before realizing it would not survive contact with a real filing season. The original design treated each business as one account with one user type.

During Blueprint, interviews with the people who actually run the workflow told a different story. Tax managers, client service coordinators, and billing staff each described a different cast on the client side. An internal bookkeeper uploads payroll records and bank statements. An outside accountant provides loan statements and sales tax reports. The owner, and only the owner, approves the final return package. Different people, different documents, different rights, different notifications.

Built as designed, the portal would have forced clients to manage all of that outside the system, over email and phone during the busiest weeks of the year, or worse, exposed sensitive documents to contacts who should never see them.

Because the gap surfaced before any additional code was written, the fix was scoped rather than retrofitted: role-based access, approval routing, and an audit trail of who provided and approved what. The final build matched the workflow the firm actually runs, cut manual follow-up during peak season, and shipped without a post-launch redesign of the account model.

The pattern: when a requirements document says "the user," it is compressing several real people into one word, and the compression always fails at the moment of most pressure. The people who know the real cast are rarely the people who wrote the requirements. They are the ones answering the phones.

Before building any portal, ask who touches the process today, by name and role. The answer is longer than the requirements say. It always is.