How I work

First I organize the system. Then I build the website.

Before designing screens or connecting automations, I define the full journey: customer, data, states, alerts, internal panel, and business response.

The result is a clear base for building faster, with less improvisation and decisions that can be validated.

work layers

complete flow

loose screens

100%

outcome oriented

Project criteria

Every decision should move the website toward a real action.

The visual layer, form, automation, and internal panel are treated as one system. If a section does not help capture, organize, or respond better, it gets simplified.

What gets defined

commercial goal of the website
data each request must collect
process states and owners
screens needed by customer and business

What gets validated

the CTA leads to a clear action
the data arrives complete
the alert fires at the right time
the panel supports a contextual response

Specification

Before designing screens, I reduce the system to use cases, entities, and rules.

This layer turns a general idea into operational decisions: who is involved, what they can do, which data exists, which states matter, and where exceptions can appear.

Use-case classes and actors

I separate customer, business, internal panel, and automation so it is clear who starts the action, who decides, and who receives the alert.

Data model and classes

Requests, bookings, services, statuses, and notifications become concrete entities that can later live in a database and admin panel.

Rules and exceptions

Duplicates, priorities, status changes, confirmations, and manual routes are defined before the form is connected to n8n.

Work evidence

Screenshots, diagrams, and explanatory notes that still matter when defining a real project today.

Traceability between needs, entities, and use cases

This map forces precision around what data exists, which actions depend on it, and where business decisions connect to the interface and operational logic.

Activity logic before automation work begins

The activity diagram helps review journey, states, and exceptions before code exists. That reduces improvisation and avoids reworking flows once real complexity appears.

Curated class diagram for operational web projects

The model connects customers, requests, bookings, services, automations, notifications, and the internal panel. It helps decide data and relationships before building.

Wireframes used to prioritize the visible layer

High-fidelity screens make it easier to discuss hierarchy, content, and the main action with stronger criteria than a verbal description or an isolated form.

End-to-end usage flow before final build

This is not just a nice screen. The visual flow already shows how steps, decisions, and friction points fit together before implementation.

Client translation

How this becomes useful in real business websites and automations today.

For a client, this layer is not delivered as a report. It becomes a short and practical process used to define the solution before building it.

more precise discovery questions focused on the flow that really matters

states, fields, and exceptions defined before forms or automations get connected

screens and CTA structure aligned with operational data instead of detached from it

stronger commercial and technical scope defense before quoting or deploying

Next step

Turn an idea into a clear system before building.

When the flow is defined from the start, the website can capture better, the automation responds with more context, and the business works with more control.

Back to portfolio Go to the form