Approach
We Don’t Start with the Visuals.
Every project has its own needs and complexities, but the path through it should not feel unclear. At each stage, we clarify what is being examined, which decisions need to be made, what will be presented for approval, and what each side is expected to provide. This allows the project to move from an initial need through launch and continued support with a shared understanding of the work.
Stage 1 — Listen & Understand
The engagement begins with conversations about the business, audience, current situation, and the need that led to the project. We discuss the intended outcome, existing problems, constraints, priorities, and the information already available. If a website or digital product already exists, its condition is also reviewed in proportion to the project. At this stage, the client provides accurate information, relevant examples, required access, and input from the people involved. The goal is not yet to choose a visual direction or final solution; it is to build a shared understanding of the starting point, the problem, and the areas that require further investigation. The outcome is a clear view of the current situation, project goals, audience, constraints, and the questions that need to be resolved in the next stage.
Stage 2 — Define the Direction
What we learned during the understanding stage is turned into practical goals, priorities, and scope. We define what needs to be created or improved, which pages, content, or capabilities are required, what remains outside the scope, and which questions still need a decision. The deliverables, responsibilities, overall sequence, timeline, and cost are clarified in the project proposal. Work begins after the proposal is approved, the agreement is signed, and the initial payment is received. If the project requires multiple stages or phased releases, the scope of the first release and later work is also defined. The outcome is a shared and practical direction that guides content, design, and development decisions—not a final visual or technical solution.
Stage 3 — Shape the Solution
The approved direction is turned into a solution that can be seen and reviewed. The content architecture, information order, core user journeys, and interface for the required areas are shaped to show how people will find information, make decisions, and complete the intended actions. Design decisions are explained in relation to the project goals, audience, content, and constraints. The client reviews the presented work, provides clear and consolidated feedback, and completes the required decisions or approvals within the agreed time. The number and method of review rounds are defined in the project agreement. The outcome is an approved solution ready to be built, with its structure, content, user journeys, and interface defined to the required level. Unapproved details should not move into development without a decision.
Stage 4 — Build & Test
The approved solution is turned into a working digital product. Its components and capabilities are built according to the project scope, with content, forms, user accounts, connected services, or other workflows brought together as required. Functionality, responsive behaviour, performance, accessibility, permissions, error states, and core user journeys are reviewed in proportion to the product. The client reviews a working version in a testing environment and checks the areas related to the agreed scope and behaviour. New requests or changes outside the scope are reviewed and estimated separately before implementation. The outcome is a tested version ready for launch, with its core areas reviewed and approved. Testing aims to reduce issues and establish a reliable product, but it does not guarantee the complete absence of errors in every circumstance.
Stage 5 — Launch & Support
After the release-ready version has been approved and the final payment completed, the product is launched on its final infrastructure. The domain, hosting, essential configuration, forms, connected services, and core user journeys are reviewed on the live version as required by the project. The client receives the agreed access, files, information, and training. Wherever possible, the domain and core accounts remain registered to and controlled by the client, with renewal responsibilities and required access clearly defined. Continued work after release follows a defined plan for maintenance, troubleshooting, or future development. The scope, duration, response times, and cost of these services are clarified separately, and launch does not begin a period of unlimited support. The outcome is a live and usable product with a clear path for handover, ownership, support, and future development.
What Does a Clear Collaboration Require?
ZARMIND’s responsibilities
- Understanding the problem and explaining the proposed path clearly
- Defining the scope, deliverables, and decisions required
- Explaining design and technical decisions in plain language
- Presenting work for review at the agreed points
- Communicating progress, issues, or changes that affect timing or scope
- Building, testing, launching, and handing over the work according to the agreement
The client’s responsibilities
- Providing accurate information, content, access, and project constraints
- Identifying the people responsible for decisions
- Reviewing the work and providing clear, consolidated feedback within the agreed time
- Completing approvals and stage payments by the defined dates
- Communicating business or requirement changes that affect the project
- Respecting the agreed scope, responsibilities, and documented decisions
The specific responsibilities are defined in each project proposal and agreement. This section explains only the general framework for collaboration.
How Are Decisions and Changes Managed?
Important decisions, approvals, and changes are documented in a traceable form so both sides understand what has been accepted and the basis on which the project continues. Feedback at each stage should be consolidated wherever possible, with unresolved decisions clarified before the work moves forward. If a new page, capability, or task outside the agreed scope is requested during the project, its effect on cost and timing is documented first. The change proceeds only after the client approves it. Delays in providing content, access, feedback, approvals, or payments may also require the schedule to be adjusted around the length of the delay and ZARMIND’s available capacity.
Frequently Asked Questions
The overall framework of understanding, defining the direction, shaping the solution, building and testing, and launching remains consistent, but the depth, duration, and outputs of each stage depend on the type and size of the project. Some activities may overlap or be lighter in one project and more extensive in another. The specific path, review points, and outputs of each stage are defined in the project proposal before work begins.
Initial conversations and review take place before the formal start to clarify the need, fit, and likely scope. Project work begins after the proposal is approved, the agreement is signed, and the initial payment is received. The start date and schedule are defined in the proposal and agreement based on the readiness of the information and content, required access, and ZARMIND’s available capacity.
The level of involvement depends on the project, but the client participates in clarifying the need, providing information and content, setting priorities, reviewing the solution, and completing key approvals. Decisions about the business, audience, and specialist project information cannot be completed without input from the responsible person on the client’s side. At the beginning of each stage, we clarify which information, feedback, or decision is needed and when it should be provided so the project can continue without unnecessary uncertainty or delay.
Work is presented for review at the agreed points, and the client gathers and provides clear, consolidated feedback for that stage. Feedback should relate to the project goals, audience, and scope so its effect on the solution can be evaluated. The number and method of review rounds are defined in the agreement. New requests or changes that alter approved decisions or the project scope are reviewed separately before implementation.
Communication channels, responsible contacts, and the frequency of updates are defined at the beginning of the engagement. Updates should clarify the current status, completed work, open decisions, actions required from the client, and the next stage. Important decisions and files should be recorded through a traceable channel. Scattered messages across multiple platforms should not replace the primary path for project communication and approval.
If required information, content, access, feedback, approval, or payment is not provided by the agreed date, part or all of the project may pause until it is received. The schedule is then adjusted around the length of the delay and ZARMIND’s available capacity. If the delay affects another stage or cost, the client is informed before the work continues.
We first review whether the change falls within the current scope or requires additional work. If it affects pages, functionality, approved decisions, timing, or cost, the result of that review is documented before implementation. The change is added to the work only after client approval. In phased projects, a new requirement may be moved to a later release or stage so the current path can be completed without unnecessary disruption.
At handover, the client receives the agreed access, information, and training. Post-launch services can include maintenance, troubleshooting, content updates, or the development of new functionality. The scope, duration, response times, and cost of continued work are defined through a clear plan. Launch does not begin a period of unlimited support or automatically include changes outside the agreement.
Tell Us About Your Business and What You Need.
To begin, answer a few short questions about your business, goals, and needs. We will review the information and contact you to discuss a suitable way forward. Sending an enquiry does not commit you to starting a project.