Citizen Portal Development: A Planning Guide

Good citizen portal development is decided before the tender is written. Pick a few high-volume services, decide how users prove who they are, set an accessibility standard, map the personal data you will process, then score suppliers on things you can verify: a working demonstration, security practice, code ownership and support. This guide walks through each step and ends with a scoring grid you can paste into your specification.

Define the scope: start small, finish end to end

The most common mistake is trying to digitise every service at once. A first release works when it covers few services but covers each one completely, from submission to final decision.

Choose services by crossing three criteria:

• Volume: applications per month, seasonal peaks, queues at the counter.
• Stability: rules that rarely change and supporting documents that are clearly defined.
• Dependencies: services that do not yet require a connection to another body you do not control.

For each selected service, document today's process: who submits, who reviews, who approves, how long each step takes, which documents are needed and why applications get rejected. A portal digitises a process. If the paper version is confusing, the screen version will be too.

Also separate three components that are often lumped together:

• the user front end (submission, tracking, notifications);
• the staff back office (review, statuses, comments, reminders);
• the administration layer (form configuration, roles, dashboards).

The back office is the one most often underestimated, yet it decides how much staff time you actually save.

Writing e-government platform requirements that can be tested

Useful e-government platform requirements are decisions, not generalities. Structure them like this:

1. Context and measurable goals, such as fewer counter visits or a shorter average processing time, with a baseline you measure today.
2. Users: citizens, businesses, representatives, staff, administrators. Note mobile use, slow connections and languages (Arabic, French, possibly Tamazight).
3. Journey per service: steps, fields, documents, validation rules, statuses, notifications.
4. Non-functional requirements: expected availability, response time, volumes, backups, logging.
5. Integrations: existing systems, file exchanges, payment if any, SMS or email.
6. Reversibility: data export, documentation, handover of source code or access.
7. Acceptance criteria: how you will decide the delivery is accepted.

Mark each item as mandatory or desirable. Otherwise a supplier can answer "yes" to everything and invoice the gaps later as change requests.

Accessibility: make it a contract criterion

A public portal serves everyone, including older people, people with visual impairments and people who are uneasy with digital tools. Use the W3C WCAG (level AA) as the technical reference and write it into the contract as an acceptance criterion, not an intention.

In practice, require:

• full keyboard navigation with visible focus;
• sufficient contrast and resizable text;
• forms with explicit labels and understandable error messages;
• Arabic and French support, including right-to-left layout;
• smooth performance on an entry-level smartphone.

Plan a test with real users before launch. For more on the subject, read our article on accessible and inclusive web design.

Identity, authentication and data protection

This is where the risk sits. First decide the level of identity proof each service needs: checking the status of a file does not call for the same assurance as obtaining an official document.

Approach	Strength	Limit
Own account (email or phone + password)	Quick to launch	Weak identity proof, password-reset support load
Two-factor authentication (SMS code or app)	Good balance of security and usability	Cost and reliance on operators
In-person or document check, then account activation	High trust	A manual step to organise
Federation with an existing national identity service	Unified experience	Depends on that service's availability and access conditions

For personal data, rely on Law No. 18-07 on the protection of individuals in the processing of personal data, and confirm with your legal team which obligations apply to your organisation, including formalities with the data protection authority. Our practical guide to data protection in Algeria covers the approach from the business side.

Some design rules keep this manageable:

• Minimisation: ask only for fields the review actually needs.
• Mapping: for each data item, record purpose, retention period and authorised staff.
• Permission separation: a staff member sees only the files in their remit.
• Audit logging: who viewed or changed what, and when.
• Encryption in transit and at rest, supporting documents included.
• Hosting: know where data is stored and who can access it, and state it in the contract.

On the technical side, the OWASP ASVS offers a list of application security controls you can ask the supplier to verify before acceptance.

Public sector software procurement: scoring a supplier

Public sector software procurement rules depend on your legal status and the contract value, so have your competent department validate the procedure. What you control is the technical scoring grid. An indicative weighting to adapt:

• Understanding of the need and method: does the supplier restate your services and risks, or copy your text back?
• Demonstration: ask for a prototype or demo on one of your real journeys, not a catalogue of screenshots.
• Security and data: role management, logging, backups, incident recovery (see our cloud disaster recovery guide).
• Accessibility: testing method, experience with bilingual interfaces.
• Verifiable references: comparable projects you can contact.
• Ownership and reversibility: who holds the code, data and documentation? What happens if you change provider?
• Operations: support, fix times, evolution, scaling.
• Total cost: design, hosting, any licences, maintenance, staff training.

Be wary of very low prices without a precise scope, suppliers who refuse a demonstration, and closed solutions with no exit route. Cost depends mainly on the number of services, rule complexity, integrations, required identity level, hosting and training volume. Ask for pricing by work package so you compare like with like.

Rollout: pilot, training, indicators

A realistic sequence is scoping, mock-ups validated with staff and users, iterative development, acceptance testing, a limited pilot, then extension. The pilot exposes the real problems: missing documents, misunderstood labels, bottlenecks in review.

Do not neglect internal change. Train staff, clarify what happens to the old paper routes, and keep an assistance channel for users who are not online. Track a few indicators regularly: share of complete files at first submission, processing time, support requests, and drop-off per step.

For an idea of what a secure user space with case tracking involves, see our client portal and subscriber area case study. The context is private, but the mechanisms (accounts, permissions, tracking, notifications) are close to those of a public portal.

How Data Forge can help

Data Forge builds custom web applications, portals and SaaS products, including e-service portals for organisations with processes to formalise. Our approach falls under custom software development.

Typical scope: bilingual user front end, review back office, role and permission management, notifications, dashboards, audit logging, data export.

Deliverables: a prioritised specification, validated mock-ups, an accepted application, technical and operating documentation, staff training, a backup plan.

How a project starts: a scoping workshop with your business and IT teams to choose the first services, map the data and set acceptance criteria. It leads to a proposal priced by work package and a staged timeline, with no commitment to the rest of the project.

Preparing a portal or a specification? Contact Data Forge and describe your two or three priority services. We will tell you honestly what is realistic and where to start.

Frequently asked questions

Which service should we start with?

One with high volume, stable rules and clearly defined documents. It lets you measure the gain quickly and validate the foundation (accounts, review, notifications) before extending.

Should we build our own citizen account or use an existing identity service?

It depends on the proof level each service needs. An own account suits simple lookups. For official documents, plan stronger verification or federation, if an identity service is available and open to your organisation.

How do we check the accessibility of a delivered portal?

Ask for an audit against WCAG level AA, keyboard and screen reader tests, and a trial with real users. Write these checks into the contract's acceptance criteria.

Can we change provider after go-live?

Yes, if the contract provides for handover of code or access, documentation and data exports. Require this in the specification, because it is what prevents lock-in.

Sources

• W3C – Web Content Accessibility Guidelines (WCAG) 2.2
• OWASP – Application Security Verification Standard (ASVS)
• ISO – ISO/IEC 27001, information security management
• Journal officiel de la République algérienne (JORADP)

Article prepared by the Data Forge team with the assistance of AI tools.

Prepared by the Data Forge team with the assistance of AI tools.