Draw the boundary before drawing the screens
An organization’s website and staff portal can share a visual identity while serving very different audiences. The website helps people understand services, find resources, and make contact. The portal supports work that depends on identity, responsibility, and access to information that may not be public. Deciding which job a feature serves is a useful early design exercise.
Consider a community program. Its public page might describe eligibility, opening hours, and the best way to ask for help. Staff may need to review requests, coordinate follow-up, or prepare program reports. The public explanation and the operational records are connected in purpose, but they do not need to share a public publishing path.
On the CCHSC public website, visitors can search community resources and browse service categories. That is information intended to help people find a next step. An internal record about a particular person would have a different audience and access requirement; the public directory is not a reason to publish it. The separate portal remains a development project.
Classify information by its intended audience
Begin with three practical questions: who needs this information, why do they need it, and who is allowed to change it? Public service descriptions are different from unpublished plans, staff notes, or records about identifiable people. A piece of information does not become suitable for publication simply because it is stored in the same system as website content.
Give public content a deliberate review process. Staff should be able to tell whether they are editing an internal record, preparing a draft, or publishing something to everyone. Clear labels and separate permissions help reduce ambiguity. The same care applies to files, exports, image metadata, and search results, not just visible page text.
- Public: approved information intended for any visitor.
- Internal: operational information for authorized team members.
- Restricted: information limited to specific responsibilities and a defined purpose.
A contact form is an information system
A short form still creates a data flow. Before adding fields, decide where submissions go, who can read them, how long they remain there, and what happens when delivery fails. Request only the detail needed to begin the conversation. A general project inquiry rarely needs attachments, personal histories, or copies of existing client records.
Make that boundary understandable to visitors. Tell them what the form is for and which information to leave out. If an organization needs a way to receive sensitive records, design that workflow separately with its operating requirements in view. Do not imply that a generic website inbox provides a suitable channel merely because the page uses HTTPS.
Connect systems through intentional handoffs
Sometimes approved portal information should reach the public website: a program description, an event, or an aggregated report. Treat that as a publishing workflow with a responsible reviewer. Define the approved fields and avoid letting a convenient integration expose the entire source record. Review examples with the people who understand the information before automating the transfer.
If a public report summarizes internal records, examine what combinations of details it reveals. Removing a name does not by itself answer every privacy question. Small groups, detailed locations, free-text comments, and linked information can change the picture. The appropriate review depends on the organization and its obligations; the interface should support that review.
Phase delivery around distinct acceptance criteria
A public website can be useful while an internal portal is still being developed. Give each phase its own acceptance criteria. Website review should cover understandable content, accessible navigation, working contact paths, and deliberate publication. Portal review should also cover identity, permissions, validation, account management, recovery, and operational support.
Document the boundary so future changes preserve it. A new team member should understand which system owns public content, where internal records belong, and who approves any movement between them. That clarity makes the next feature easier to evaluate and helps the organization keep its digital tools aligned with the people they serve.
Further reading
Thoughtful systems start with good questions.
Tell us what you’re working on
