Loading
ZWIK-STOCZEK-LUKOWSK

ZWiK Stoczek Łukowski

Website for a municipal water and sewage utility, designed for residents of every age and built to WCAG 2.1 AA.

ZWIK Stoczek Łukowski Cover
Role
Fullstack-developer, UI/UX
Period
May 2024, updated Oct 2026
Status
Live
Stack
Frontend
Next.js, React, Shadncui, Tailwind CSS, TypeScript, Vercel

The problem

A public utility's website has to work for residents of every age

People visit a water utility's website with a few concrete tasks: report a failure, check whether the water will be cut off, submit a meter reading, look up prices. The visitors range from young residents on their phones to seniors, and as a public body the utility must also comply with the Polish act on digital accessibility, which follows WCAG 2.1 at level AA. That rules out a showcase design. I designed and built a site that is clear, calm and makes every piece of information easy to find.

The product

Everything a resident needs, starting with how to report a failure

The homepage opens with failure reporting: the phone number and a link to the online form.

  • Announcements about planned works and water supply interruptions.
  • Latest water quality results for each intake: pH, turbidity, colour, free chlorine, hardness and coliform bacteria.
  • Online forms for meter readings, failure reports and liquid waste collection, plus downloadable documents.
  • Tariff and non-tariff price lists, an FAQ and contact details with a map.
  • A link to the Public Information Bulletin (BIP), marked as an external site.

Decision 01

Calm and predictable instead of distinctive

I kept the design deliberately quiet: calm colours, a clear hierarchy and the same layout on every page. Each menu item carries a one-line description of what is inside, the customer office lists its four services as numbered cards, and the FAQ links straight to the right form. The layout is fully responsive, so the site works the same on a phone as on a desktop. It gives up visual distinctiveness in exchange for being easy to use for every visitor.

Decision 02

Accessibility built into every component, not added at the end

Every page starts with a skip link, the top bar has a high contrast switch and three text sizes, and the layout adapts to screen width and browser zoom. Form fields have labels and examples of the expected input, such as a meter reading in m³, and external links are announced as external. The cost is testing: every component has to work in two contrast modes and three text sizes.

Decision 03

Forms prepare an email instead of sending data to a server

The meter reading, failure and service forms send nothing to a server. The button opens the resident's email client with a ready message addressed to the utility's existing inbox. Personal data goes straight to the utility, and there is no form backend or mail server to maintain. The cost is that the resident needs a configured email client and still has to press send, so the phone number and email address are always shown on the same page.

The result

The accessibility statement lists no issues in the site itself

The only non-compliant items are three PDF documents in the downloads section, which lack tags or a defined language, and an embedded Google Map, which the law exempts. The statement names them openly and offers residents an accessible version of any document on request.

Contact

Open to frontend, full-stack and AI engineering roles. B2B, Warsaw or remote.

lukols.dev@gmail.com
Email me

Let's work
together

Łukasz©2026
Olszewski