Briefing 01 / 01
All pages
Internal briefing · Working draft 01

Production

Website
Department

For project managers and account executives

Presenter-led · Reusable reference

Start here

Use the arrow keys, spacebar or controls below.

01

Introduction

01Introduction

The website department

Team size [As of Aug 2026]

02

One website lead and one designer.

Website lead

Vivien

Technical direction, production oversight and internal sign-off

Designer

Farah

Assigned website design and production work

Role descriptions are intentionally concise and can be refined after the process is approved.

01.1Introduction

Content map

01

Introduction

Team, portfolio, capabilities, boundaries and the PM/AE role.

02

Website lifecycle

Production phases, infrastructure, migration, QA/QC, timeline and handover.

03

Website solutions

WordPress + Elementor, Astro and Astro + Sanity delivery models.

04

WordPress + Elementor

Solution fit, content inputs, plugin controls and task assignment.

05

Astro + Sanity

Framework basics, stack, production process, CMS, deployment and ownership.

06

Brief preparation

Minimum brief requirements and a complete working example.

07

Scope + delivery control

Scope expansion, process risks, issue intake and operational case studies.

01.2Selected portfolio

Solutions we’ve built

Three examples showing different content, integration, governance and client-maintenance requirements.

01

Lianson

Corporate website revamp

https://lianson.com/
  • Revamp from ICON Offshore.
  • Mega menu and INSAGE investor-relations integration.
  • Distinctive client-provided imagery.
02

MGB Group

Client-managed corporate website

https://mgbgroup.com.my/
  • Bursa integration without a third-party association.
  • Routine content structure designed for client-managed updates with an MNC presentation.
  • Motion-led Homepage introduction.
03

Sunway

Reusable sustainability report

https://sustainability.sunway.com.my/
  • Reusable sustainability-report website for Sunway.
  • Designer IP whitelisting required by the client’s security environment.
  • Strict corporate brand-guideline compliance.
01.3Department scope

What we can do

These are the confirmed WordPress and Elementor capabilities of the website department. Astro scope will be documented after its delivery model is approved.

Website production

Deliver the complete WordPress lifecycle

Brief review, Wireframe, Cosmetic, mobile and tablet optimization, internal QA/QC and migration readiness.

Content management

Build brochure-style websites for regular updates

Corporate and marketing websites focused on presenting approved information, services, pages, copy and imagery.

Established setup

Work within approved Elementor capabilities

Standard pages, forms and interactions supported by our existing components and controlled plugin set.

Technical review

Assess unfamiliar or technical-heavy requests

Vivien reviews custom requirements before feasibility, additional cost or timeline is confirmed.

01.4Department boundaries

What we do not do

These boundaries protect security, stability, production time and the accuracy of client commitments.

Plugins

No additional WordPress plugins during standard production

Our websites use a controlled plugin set. A requested feature is not approved simply because a plugin exists.

Client commitments

No unverified feature promises

Unknown functionality must be checked with the website team before cost, feasibility or timeline is confirmed.

Service model

No web application development

We provide brochure-style, content-focused websites, not Laravel applications, calculators, portals or custom business systems.

Production assets

No Google-sourced production imagery

Use client-owned assets, licensed Freepik or Envato assets, or approved AI-generated imagery.

01.5Project ownership

PM / AE role overview

PM/AE owns the information, assignment and client expectation surrounding website production.

01 · Define the inputs

Confirm the source of truth

  • Who supplies content and imagery?
  • Which files are approved?
  • Is each item final, provisional or pending?

02 · Assign the work

Resolve the assignee before production

  • PM/AE team allocates WordPress work.
  • Consider workload, priority and technical needs.
  • Designers do not self-select assignments.

03 · Protect the commitment

Check before promising

  • Verify that client feedback is clear, consolidated and within the agreed scope.
  • Technical feasibility → Vivien.
  • Quotation or maintenance coverage → Xin Ying, Account Director.
  • Do not confirm delivery, cost or timing until the request is verified.
Workload coordination When urgent work conflicts with a scheduled task, the requesting PM/AE must align priority and timing directly with the PM/AE responsible for the existing workload and the website team. The designer is not responsible for choosing between projects or explaining the resulting delay.

02

Website lifecycle

02WordPress

Website lifecycle

00

PM / AE prepares the brief

Project information is prepared before website production begins.

W

Wireframe

RFRS → Client approves the W direction.

C

Cosmetic

RFRS → Client approves C.

R

Mobile and tablet optimization

RFRS → Internal sign-off target.

M

Website migration

Hosting and DNS ownership, client approval and a confirmed migration date are required.

This lifecycle is confirmed for WordPress work only. Astro’s process remains to be defined.

02.1Website lifecycle

PM/AE brief context

PM/AE owns the complete brief and coordinates the website assignee before production begins.

WordPress assignment

Vivien or Farah

The PM/AE team assigns WordPress work based on workload, priority and technical requirements. Designers do not self-select tasks.

Assign to Vivien

Technical-heavy work and migration

Proposals, R&D, scoping, design reviews, custom coding, migration and requirements outside native Elementor capabilities.

Uncertain requirement

Check before promising

The website team confirms whether the feature is supported, requires additional cost or needs a different approach.

Assignment example

Standard Elementor taskPM/AE assigns Vivien or Farah

Custom feature or migrationAssign to Vivien

PMs should use their designated internal brief template. The minimum information required in a complete brief is listed under Website brief preparation.

02.2Website lifecycle

Wireframe

Our wireframe is a branded structural direction, not a grayscale draft.

Included

Layout, website structure, approved Web Content, fonts and brand colours. Images and icons remain as standard placeholders. Animation or transitions may be applied where relevant.

Client review

The client reviews the website structure, content placement and branded direction before final images and icons are applied.

Approval gate

The client must approve the Wireframe direction before the project proceeds to Cosmetic.

Why colour is applied here

Reference mood does not replace the official brand guide. Applying brand colours early exposes conflicts before imagery is added and prevents avoidable redesign.

02.3Website lifecycle

Cosmetic

Final images and icons are applied after the Wireframe direction has been approved.

PM/AE prepares

Confirm the client’s image direction and collect any usable image assets before assigning the phase.

Accepted sources

Client-owned assets, licensed Freepik or Envato assets, and AI-generated imagery where appropriate.

Not accepted

Google-sourced images cannot be used as production assets, including when a client asks the website team to use them.

Approval gate

The client must approve Cosmetic before mobile and tablet optimization begins.

02.4Website lifecycle

Mobile and tablet optimization

This phase begins only after Cosmetic has passed.

  1. 01

    Optimize the layouts

    Designer adapts the approved desktop direction for mobile and tablet.

  2. 02

    Perform device QC

    Designer checks the responsive website on the devices available to them.

  3. 03

    Prepare for migration

    This is the final production phase before migration readiness is confirmed.

Migration does not begin automatically after this phase. Client approval and a confirmed migration date are still required.

02.5Infrastructure basics

Hosting and DNS

Hosting and DNS work together, but they are not the same service.

Domain

The house address

The address visitors enter to find the website.

Address written on the parcel

DNS

PosLaju’s routing system

Reads the domain and directs visitors to the correct server.

Our usual provider: Cloudflare

Hosting

The house

The server environment where the website and its files live.

Our usual provider: Cloudways
Our usual setup Client domainCloudflare DNSCloudways hosting

Changing DNS does not move or rebuild the website. It changes where the domain sends visitors. If DNS points to the wrong place, the website may still exist, but visitors will not arrive there.

02.6Infrastructure basics

Hosting and DNS ownership

Confirm hosting and DNS as two separate decisions before planning migration.

Hosting owner

Where the website lives

Managed by us

Cloudways.

Client-managed

The client confirms the hosting provider and supplies the required environment and access.

DNS owner

Who controls the domain routing

Managed by us

Cloudflare.

Client-managed

The client or their provider applies the DNS records using our instructions.

Confirm the hosting owner and DNS owner

Never assume the same party manages both services. Confirm each owner separately.

24–48 hours

DNS changes can take time to propagate. Confirm ownership, instructions and the launch date early.

02.7Website lifecycle

Website migration

Migration begins only after the website is approved and the client has confirmed the migration date. Vivien performs WordPress migrations for now.

01Confirm approval and date

Do not plan migration from an assumed launch date.

02Confirm hosting

If hosting with us, send the domain to Vivien early so the Cloudways application can be prepared. If client-hosted, the client prepares the WordPress environment and provides access using the current internal process.

03Confirm the DNS owner

Identify whether the client, our team or another provider is responsible for making the change.

04Coordinate DNS early

DNS changes can take up to 24–48 hours to propagate. Send the instructions early, obtain acknowledgement and follow up proactively.

05Verify migration readiness

Hosting, DNS ownership, access, required changes and sufficient propagation time must all be confirmed.

Not migration-ready:

A launch that depends on a same-day DNS request is not migration-ready.

PMs must consult their latest internal migration resources and checklist. This page explains migration from the website production team’s viewpoint and does not replace the PM’s operational procedure.

02.8Internal QA/QC

RFRS

Review, Feedback, Repeat, Sign Off

RFRS is the internal QA/QC process used after a designer completes an assigned website phase that requires website lead approval.

01

Review

The website lead reviews the completed phase.

02

Feedback

The website lead compiles the required adjustments.

03

Repeat

The designer applies feedback and the website lead checks again.

04

Sign Off

The website lead approves the phase before it moves forward.

Applies to

Wireframe, cosmetic and responsive optimization phases.

Content check

PM / AE reviews content placement against the approved Web Content.

Technical check

Website lead QCs UI/UX and the website development structure.

02.9Internal QA/QC

Six-day phase

Two production days, one fine-tuning day and three internal review days.

Applies to

Wireframe Cosmetic Mobile + tablet optimization

WordPress + Elementor only for now.

Days 01–02

Production

Designer completes the assigned phase.

Planning rule

PM / AE allocates the complete six-day internal QA/QC window when assigning each phase.

External time

Client review and approval sit outside these six working days.

If it runs longer

The website team realigns expectations with the PM / AE when client feedback is added or lead feedback is heavy.

02.10Internal QA/QC

Responsibilities

Internal review is scheduled work. Urgent requests must be aligned with the website team.

PM / AE

Schedule and review

Assign the website task with the complete internal review window and check content placement against the approved Web Content.

Designer

Complete and adjust

Produce the assigned phase, fine-tune it and apply compiled feedback.

Website lead

Review and sign off

Review UI/UX and development structure, compile feedback and conduct the final review.

Open guidance Claude and Codex usage boundary

Use for

Missing links, incorrect or missing content, broken images and other functional completeness checks.

Do not use for

Design approval. UI/UX judgement and sign-off remain with the website lead.

02.11Website lifecycle

WordPress project timeline

Standard delivery uses three sequential six-day internal production phases.

Phase 01 · 6 days

Wireframe

Structure, approved content placement and branded direction are reviewed and signed off first.

Phase 02 · 6 days

Cosmetic

Final imagery and icons are applied only after the Wireframe direction is approved.

Phase 03 · 6 days

Mobile + tablet

The approved desktop direction is optimized and checked across available devices.

Total · 18 internal working daysMinimum for the three production phases. Client review periods and website migration sit outside these 18 days.

One-page exception

Cosmetic and responsive work may overlap

For a simple landing page, these phases may run together after Wireframe approval.

Rush request

Discuss the delivery method with the Account Director

A shorter timeline may require reprioritization, a template or a reused direction. Position the reduced method clearly; compressed delivery does not support full custom expectations.

02.12Website lifecycle

Post-migration setup and handover

Migration is followed by technical setup, account preparation and handover coordination.

Vivien

Complete the website setup

  • Apply plugin licensing and required plugin setup.
  • Connect the confirmed email provider.
  • Set up Google Search Console and coordinate DNS verification when required.
  • Create the client dashboard administrator account.

PM / AE

Collect the handover inputs

  • Confirm Microsoft 365, Google Workspace, Outlook or the relevant mail provider.
  • Request the client email for the WordPress administrator account.
  • Confirm the DNS owner and coordinate access or verification.
  • Provide the information required by Vivien and the SEO team.

SEO team

Prepare Yoast SEO

The SEO team confirms the required Yoast SEO readiness and configuration after migration.

Confirm with Xin YingWhether the guide kit remains relevant, whether training is a paid scope, and how the proposed three-month bug and speed support period differs from website maintenance.

03

Website solutions

03Solutions

Our three website solutions

01

Content-managed website

WordPress + Elementor

Our established brochure-website solution with visual layout and content management through WordPress.

02

Code-managed website

Astro

A fast, secure framework suited to fixed content, custom presentation and more complex motion.

03

Structured CMS website

Astro + Sanity

The Astro front end with controlled content-field editing through Sanity CMS.

Astro and Astro + Sanity use the same front-end framework. Sanity adds controlled CMS editing for predefined content fields.

03.1Solution selection

Website solution comparison

Decision point WordPress + Elementor Astro Astro + Sanity
Internal baseline 18 days 18 daysProvisional 21 days minimumProvisional
Content editing WordPress and Elementor backend. Website team updates the code. Client edits predefined Sanity fields.
Layout control Visual layout through the established Elementor setup. Code-controlled components and layouts. Code-controlled layout; CMS fields do not reorganize sections.
Best fit Client prefers WordPress or needs a familiar visual CMS. Speed, security, custom presentation and no client CMS. Astro benefits with controlled client content editing.
Standard hosting Cloudways with DNS ownership confirmed separately. Cloudflare Pages with Astro-only imagery in R2. Cloudflare Pages with content and images managed through Sanity.

Client review and migration sit outside these internal baselines. Astro estimates remain provisional while the delivery workflow is being established.

04

WordPress + Elementor

04Website solution

WordPress + Elementor

Our established content-managed website solution. It works best when the project stays within the approved Elementor and plugin setup.

Works well for

Structured, content-managed brochure websites

  • Corporate and marketing websites.
  • Regular copy, page and imagery updates.
  • Controlled client backend access.
  • Standard functionality supported by our setup.

Requires review

Requirements outside the established setup

  • Custom forms or integrations outside the existing setup.
  • Third-party integrations or additional plugins.
  • Application-style tools such as calculators or portals are outside scope.
  • Hosting, caching or major configuration changes.
Operating principleWordPress is straightforward within a known setup. It becomes unpredictable when every new requirement is answered with another plugin.
04.1WordPress + Elementor

Content and imagery source

Before assigning production, the PM/AE confirms who supplies each input and what the designer is expected to follow.

Content source

Define the approved copy

  • Who supplies it: client, agency or both?
  • Which document or Dropbox folder is approved?
  • Must it be followed exactly?
  • May production proceed with placeholders?

Imagery source

Define the usable assets

  • Who supplies the final images?
  • Are client-owned assets available?
  • May licensed Freepik, Envato or AI imagery be used?
  • Google-sourced production images are not accepted.
PM/AE confirms status Final Provisional Pending from client

Designers should never have to infer whether content is approved, temporary or still expected from the client.

04.2WordPress + Elementor

Feature, plugin and assignment control

Elementor is a production tool, not an unlimited feature builder. Confirm the setup before committing the team.

Controlled setup

Use the approved plugin set

New plugins are not installed during standard production. Caching, optimization and feature plugins are not added ad hoc because overlapping tools can create conflicts and complicate troubleshooting.

Task allocation

PM/AE team assigns the work

Vivien and Farah can both handle WordPress work. Assignment is based on workload, priority and technical needs. Technical-heavy requirements and migrations go to Vivien.

  1. 01Feature requested
  2. 02Check existing setup
  3. 03Website team confirms feasibility, cost and timeline
  4. 04PM/AE responds to client
If uncertainDo not promise the feature. Check with the website team first.

05

Astro + Sanity

05Website solution

Astro + Sanity

Our code-based website solution has two delivery models. The choice depends on whether the client needs an editable content backend.

Astro only

Code-managed website

  • Website is built in Astro and versioned in GitHub.
  • Production images are stored in Cloudflare R2.
  • Content or layout changes go through the website team.

Astro + Sanity

Defined content fields for client updates

  • Astro controls the frontend and layout.
  • Sanity stores the editable content and imagery.
  • Clients replace approved fields; they do not reorganize sections.
05.1Astro basics

What is the Astro framework?

HTML and CSS are what the browser receives. Astro is the production framework used to organize, reuse, build and deploy them across a complete website. Reusable components are created once; changing a shared component updates every page that uses it after the website is rebuilt.

What the browser receives

HTML, CSS and JavaScript

HTML
Page structure and content.
CSS
Layout, typography and visual styling.
JavaScript
Interactions that need browser behavior.

What Astro manages

The system around the website files

  • Reusable headers, footers and page components.
  • Pages, routes, shared layouts and metadata.
  • Content connections such as Sanity.
  • The build sent to GitHub and Cloudflare.
Can we use only HTML + CSS?Yes, for a small standalone page. For a maintained multi-page website, Astro prevents repeated files and shared elements from being managed manually. The finished Astro website still outputs HTML and CSS.
05.2Solution selection

WordPress or Astro

The platform follows the client’s operating needs. PM/AE confirms the requirement before the solution is proposed.

Choose WordPress when

The client prioritizes familiar content management

  • The client specifically requests WordPress.
  • Their team already has WordPress experience.
  • They need broad control over pages and content.
  • Elementor provides the required design flexibility.

Choose Astro when

The project prioritizes speed, security and custom interaction

  • A smaller WordPress and plugin attack surface is preferred.
  • Speed and predictable frontend output matter.
  • The design needs custom motion, scrolling or interactions.
  • The client accepts the defined content-editing model.
Decision ruleIf the client’s hosting, editing or feature expectation falls outside the known setup, consult Vivien before quotation or commitment.
05.3Solution fit

Benefits and limitations

Benefits

Controlled output and custom frontend freedom

  • Fast website delivery to the browser.
  • Reduced WordPress and plugin attack surface.
  • No WordPress plugin or cache conflicts.
  • Custom motion, scrolling and interaction.
  • Git history, review and rollback.
  • Clear separation of code, content and assets.

Limitations

Changes must stay within the delivery model

  • Astro-only has no client-editable CMS.
  • There is no Elementor-style visual builder.
  • Sanity edits predefined fields, not layouts.
  • New functions require development and technical review.
  • CMS projects need upfront modeling, QA and training.
  • Alternative hosting is outside the standard workflow.
05.4Technical structure

The stack

GitHub stores the code and version history. Cloudflare delivers the website. Production imagery is stored outside the repository.

01
GitHub

Source of truth for Astro code and deployment history.

02
Astro

Frontend components, layouts, motion and website logic.

03
Cloudflare Pages

Builds and serves the Astro frontend. A Sanity Studio can also be hosted here.

04A
Cloudflare R2

Required production image storage for Astro-only websites.

04B
Sanity

Stores editable content and imagery for Astro + Sanity websites.

Sanity content and assets remain in Sanity’s Content Lake and CDN even when the frontend and Studio are deployed through Cloudflare.

05.5Production process

Process overview

The familiar approval gates remain. The production method changes because Astro is built as code and deployed through GitHub and Cloudflare.

  1. 01
    Direction

    ImageGen exploration and two-page HTML/CSS prototype.

  2. 02
    Wireframe

    Astro build, approved content, placeholders and internal UI/UX QC.

  3. 03
    Cosmetic

    Final imagery, client amendments and approval.

  4. 04
    Final fidelity

    Responsive optimization, full QC and final approval.

  5. 05
    Deployment

    Confirm date and publish through Cloudflare Pages.

05.6Direction and prototype

Direction and prototype

Step 01

Generate design directions

Use ImageGen to explore the visual direction before production begins.

Step 02

Approve one direction

Confirm the visual language before committing it to the website build.

Step 03

Prototype two pages

Develop the Home page and one representative subpage in HTML and CSS first.

Approval gateDo not develop the full Astro website until the two-page direction is accepted internally.
05.7Wireframe production

Astro development

Build

Develop the remaining pages in Astro

Convert the approved direction into reusable components and page layouts across the website.

Content rule

Web Content is the source of truth

The layout may be adapted for the design, but information cannot be omitted, invented or materially rewritten.

Wireframe state

Use placeholders first

Keep placeholder images and icons while structure, content placement and interaction are being approved.

Internal QC

Polish UI and UX before content review

Check the design system, layout behavior and interaction before handing the build to the writer for content polishing.

05.8Source control

GitHub and staging

The repository starts when Astro development starts. It is part of production, not a file added only at launch.

Repository

Code lives in GitHub

Components, configuration and deployment history are tracked in the company repository.

Preview

Cloudflare builds the staging site

Approved changes are pushed to the repository and published to the assigned preview environment.

URL convention

Astro staging uses “a0”

Astro: a0#.wipwebs.com
Example: a03.wipwebs.com
WordPress: #.wipwebs.com

Asset boundaryProduction images do not remain in GitHub and are not embedded into the website code.
05.9Astro + Sanity

Sanity integration

Sanity begins during Astro development because the editable content model must match the approved website structure.

Step 01

Confirm editable scope

Identify which copy, links, lists, images and SEO fields the client is allowed to update.

Step 02

Structure the CMS

Create schemas, fields, validation, slugs, relationships and image fields from the Sanity Factory.

Step 03

Connect Astro

Map the Sanity content model to the approved Astro components without giving the CMS control of the layout.

Pending workThe current Sanity Factory must be rebuilt and validated before it becomes the standard production base.
05.10Astro + Sanity

Sanity QA

Content model

Test every editable field

Check required fields, validation, slugs, references, images, SEO inputs and empty states.

Frontend result

Test every mapped output

Confirm edits appear in the correct Astro component without breaking layout, links or responsive behavior.

Full review

Use agents and manual QA

Run structured checks, then manually test the complete editing and publishing experience before launch.

Client can editApproved content fields and imagery Client cannot editSection order, components or page layout Layout changesRequested through the website team
05.11Cosmetic and responsive

Imagery and final fidelity

After wireframe approval

Apply final imagery

PM/AE confirms client assets. Otherwise use licensed Freepik or Envato imagery before resorting to AI-generated images.

Storage rule

Store images by delivery model

Astro only: Cloudflare R2.
Astro + Sanity: Sanity image assets.

Final QC

Do not rely on automatic optimization

The initial build provides a responsive baseline. Full fidelity and device behavior still require extensive manual QC.

05.12Post-production

Cloudflare deployment

Astro is deployed rather than migrated through WordPress tools. The website still requires client approval, a confirmed production date and DNS readiness.

  1. 01
    Confirm final approval

    Layout fidelity, content and responsive completion are signed off.

  2. 02
    Confirm production date

    Do not plan from an assumed launch date.

  3. 03
    Prepare the production build

    Push the approved repository state to the Cloudflare Pages project.

  4. 04
    Connect the domain

    Confirm DNS ownership and allow the required propagation window.

  5. 05
    Verify production

    Check routes, assets, forms, metadata and responsive behavior on the live domain.

05.13Infrastructure ownership

Standard and alternative hosting

Standard company setup

Company GitHub and Cloudflare

  • Astro code is managed in the company GitHub organization.
  • Frontend and optional Sanity Studio deploy through company Cloudflare Pages.
  • Astro-only imagery uses company Cloudflare R2.
  • The domain and DNS owner are confirmed separately.

Alternative or client hosting

Technical review required before commitment

  • Astro can be hosted elsewhere, but it is not the standard delivery workflow.
  • The platform must support the required build and deployment process.
  • Adaptation, testing, access and handover may become additional scope and cost.
  • PM/AE consults Vivien before quotation or promise.
Pending policyRepository ownership, client handover, long-term maintenance and alternative-hosting support still require an internal operating decision.
05.14Provisional timeline

Astro project timeline

Astro follows three sequential six-day internal production phases. Each phase includes production, fine-tuning and internal review.

Phase 01 · 6 days

Direction + Astro wireframe

Approve the visual direction, prototype the first pages and establish the Astro component structure using approved content.

Phase 02 · 6 days

Cosmetic

Apply final imagery, icons and motion after the Wireframe direction has been approved.

Phase 03 · 6 days

Responsive + fidelity

Complete responsive optimization, interface polish and technical front-end QA before migration readiness.

Total · 18 internal working daysClient review periods and Cloudflare migration sit outside this internal baseline.
05.15Provisional timeline

Astro + Sanity project timeline

Astro + Sanity follows the same 18-day production baseline with a minimum three-day CMS integration and QA allowance.

Phase 01 · 6 days

Direction + wireframe

Approve the direction and define the reusable Astro structure.

Phase 02 · 6 days

Cosmetic

Apply final imagery, icons and motion after Wireframe approval.

Phase 03 · 6 days

Responsive + fidelity

Complete responsive optimization and front-end QA.

CMS · 3 days minimum

Sanity integration + QA

Finalize schemas, connect fields and test editing, validation and publishing.

Integration rule: Sanity content modelling begins during Astro development. The additional allowance covers final integration and full CMS QA, not a late-stage bolt-on.

Total · 21 internal working days minimumComplex content models, relationships, previews or migration requirements need additional technical review.

06

Brief preparation

06Task assignment

Website brief preparation

PMs should use their designated internal template. Regardless of format, every complete website brief must include the following information.

  1. 01

    Task Name

  2. 02

    Action Plan

  3. 03

    Brief Description of Client

  4. 04

    Web Content Dropbox URL

  5. 05

    Brand Guideline / Info PackIf available.

  6. 06

    Website ReferencesCheck whether the client has a preferred design direction or websites the team can benchmark.

  7. 07

    TimelineInclude allocated production days, urgency, fixed dates and possible extensions where the designer has other priorities.

  8. 08

    Other Notes

Task title format

{Client Name} [Website Task Type] – {Designer Name}

Task types: amendment / wireframe / cosmetic / optimization

The PM’s designated template remains the source format. These are the minimum content requirements from the website production team’s viewpoint.

06.1Historical example

Complete brief in practice

Resource names must be accompanied by their actual URL or file location. The designer should not have to search for a reference named in the brief.

Actual source brief

Dear Kai Ying,

I need your help to begin drafting the wireframe for our new website project, the Gombak-Hulu Langat Geopark website, which is under Tourism Selangor.

CONTEXT

For context on the project/client, you may refer to the existing landing page at

https://selangor.travel/geopark/

They also have existing social media accounts here:

https://www.instagram.com/ghlgeopark/ https://www.facebook.com/GHLgeopark/

We have previously provided the client with two Homepage mockups, and they prefer C1 but want a few elements from C2 in the website design

https://proposal.wipwebs.com/tourism-selangor/

[Note that this URL is no longer accessible]

INFO PACK:

Dropbox: C:\Users\USER\Walk Production Dropbox\Walk Production\Production\Tourism Selangor\GHLGp Website\Info Pack
GDrive: https://drive.google.com/drive/folders/1jZd31UPL_7N5EONndNdCuD7HFVvzOlHK?usp=sharing
Latest web content: C:\Users\USER\Walk Production Dropbox\Walk Production\Production\Tourism Selangor\GHLGp Website\To Client\Malay Web Content\251013

Notes:

There is a few pages that still do not have content as the client have yet provided the info needed for the writer to draft the content.

The current website is on Malay content, but later, once the web content has been finalised, we will translate it to Eng.

You may need some of the information/context for certain sections' designs by going through the comments I put on the client's feedback file to understand what the client wants.

C:\Users\USER\Walk Production Dropbox\Walk Production\Production\Tourism Selangor\GHLGp Website\To Client\Malay Web Content\250724\Client's Feedback

E.g.: "Jelajahi Intipati Geopark Kami" section on the Homepage

Website references:

https://visitselangor2025.my/ (they set this as the benchmark) https://www.langkawigeopark.com.my/ https://lenggonggeopark.com https://selangor.travel/

Brand Guidelines:

C:\Users\USER\Walk Production Dropbox\Walk Production\Production\Tourism Selangor\GHLGp Website\Info Pack\CI Geopark

File Name: GeoPark Brand Guidelines 2025 Final.ai

Missing from source briefPM/AE must add the production window, urgency, fixed dates and known scheduling constraints before assignment.

07

Scope + delivery control

07Scope + delivery control

Verify before committing

PM/AE verifies scope, technical feasibility and team capacity before confirming a request to the client.

Feedback + scope

Verify the request is established and included

Consolidate the feedback and confirm it sits within the quotation or maintenance boundary. Consult Xin Ying when the commercial scope is unclear.

Technical feasibility

Consult Vivien before promising the feature

Confirm whether the request works within the website solution, existing setup and technical constraints.

Capacity + timeline

Coordinate priority across the PM team

Discuss urgent work with the PM responsible for the existing priority and the Account Director. The designer is not responsible for choosing between competing PM requests.

Commitment ruleConfirm scope, feasibility and capacity before confirming cost, timeline or delivery to the client.
07.1Scope + delivery control

Scope expansion

A request can be technically feasible and still sit outside the approved project scope.

Training

On-site or additional client training

Do not assume training is included. Confirm the quoted scope and any additional cost with Xin Ying before scheduling it.

New functionality

Features outside the established setup

Non-native WordPress features, custom forms, calculators, portals, additional plugins or integrations require technical and commercial review.

  1. 01Request received
  2. 02Xin Ying confirms quotation or maintenance scope
  3. 03Vivien confirms technical feasibility where required
  4. 04PM/AE confirms cost and timeline
Scope ruleNo client confirmation is made until the relevant owner has verified the request.
07.2Scope + delivery control

Process risks

These actions create avoidable rework or transfer responsibility to the wrong person.

Review sequence

Skipping an earlier internal sign-off

Client approval does not replace the website lead's review. Moving directly to responsive work can reveal late structural issues and force the designer to rebuild approved work.

Workload

Accepting urgency before checking availability

Confirm the designer's assigned priorities and coordinate with the responsible PM before giving the client a delivery commitment.

Research

Escalating an undefined request

PM/AE gathers the intended outcome, examples, client context and initial evidence before asking the lead to validate technical feasibility.

Process ruleSkipping an earlier review does not remove the review work. It moves structural problems into a later and more expensive phase.
07.3Technical escalation

Urgent technical issue intake

PM/AE gathers the incident context before technical triage. Farah is the website designer and is not responsible for technical support.

01 · Timing

When did the issue happen?

Record when it started and whether the issue is still happening. An exact date and time helps the technical lead compare activity and changes.

02 · Live impact

What is at stake?

Confirm what is affected on the live website and the practical impact on the client, their visitors or an active launch.

03 · Project blocker

Does it block the next phase?

Identify the dependency. Example: the client cannot provide the DNS account required to change the A Record.

04 · Security

Is there evidence of hacking?

Share the symptoms and available evidence. Do not assign a cause or responsibility before the technical lead reviews the incident context.

Technical routeConsult Vivien for urgent technical issues. If Vivien is on leave, Evans provides technical support. Do not assign the issue to Farah.
07.4Technical escalation

AKW Land vs HG-NIC

AKW Land was a domain and DNS incident. HG-NIC was a WordPress security incident.

AKW Land · Domain and DNS

The domain registrar was hijacked

The property development website was redirected to a gambling website after its Gname nameservers were changed. Cloudways and WordPress were clean.

HG-NIC · WordPress security

An administrator account was compromised

The large client-managed WordPress website was compromised through an administrator account. Malicious plugins and webshells caused site-wide 404 errors.

Scope noteIncident investigation and remediation are not automatically included in website production or maintenance.
07.5Incident breakdown

AKW Land

A property development website previously hosted on WordPress and Cloudways.

01 · Website context

Property development website

AKW Land's corporate website presented its property developments and company information. The website files were stored on our Cloudways hosting.

02 · What happened

The Gname account was hijacked

Gname is the domain registrar, where the domain and its nameserver settings are managed. The nameservers were changed and visitors were sent to a gambling website.

03 · WordPress check

Hosting was not compromised

The Cloudways origin returned the correct website. No malware, rogue users, malicious plugins or injected redirects were found.

04 · End result

The website was removed from our hosting

The new PIC was not aware that the website existed. After confirming the WordPress installation was clean, AKW Land was removed from our Cloudways hosting.

PM/AE takeawayIf a site shows the wrong content, check domain and DNS ownership before assuming WordPress was hacked.
07.6Incident breakdown

HG-NIC

A large WordPress website with extensive content that the client updates regularly.

01 · Website context

Large and regularly updated

The site stores extensive content and is updated by the client. It also had known cache-related editing issues that were deferred because a website revamp was being planned.

02 · What happened

The WordPress website was compromised

An administrator account was used to add malicious file-manager plugins, webshells and a fake Google Search Console verification file. The website returned 404 errors.

03 · Immediate response

Block, restore and scan

The attacker IP was identified and blocked immediately. Because the site is on Cloudways and access is shared with us, we rolled it back to a clean backup and reran the file-cleaning check.

04 · Prevention

Remove the shared administrator account

The shared WordPress account was the most likely entry point. The client was advised to change passwords, enable 2FA and replace the shared account with individual user accounts.

PM/AE takeawaySend security incidents to Vivien immediately. Do not ask the designer to diagnose or resolve them.

Navigate

Briefing outline