A website image content brief connects each photograph, illustration or mockup to a purpose on the page. It helps a Kenyan business provide the right assets before a developer builds the layout, instead of filling empty spaces with whichever pictures happen to be available at the end of the project.
This is a content-preparation guide for business owners and marketing teams. It focuses on image selection, context, descriptions and approval, rather than comparing cameras or prescribing a universal file format. Share it with your website design team alongside the page copy and intended customer journey.
Start with the question each image should answer
For every important page, identify the decision the visitor is trying to make. A service page might need to demonstrate the type of work offered. A project page might need to distinguish an identity concept from a completed installation. An about page might need to introduce the actual team.
Write that purpose in the image brief before collecting files. “Show the interior consultation area” is more useful than “add a premium photo.” The first instruction can be checked against a specific asset. The second leaves the photographer, designer and developer to guess what business information the image should provide.
Some images can be decorative. Others carry evidence or instructions that a visitor needs. Make that distinction deliberately. If removing an image would remove an important fact, explain the fact in the brief so the team can preserve it through the layout, caption and text alternative where appropriate.
Build a page-by-page image register
Create a simple register with the page, intended position, image purpose, source file, approval owner and status. Add notes about captions, permissions and whether the image is ready or still required. A shared folder without this index makes it harder to tell which files have actually been approved.
Give each asset a stable reference. For example, an illustrative identifier such as project-reception-01 can connect a source photograph to its caption and page location. The identifier does not need to be clever; it needs to prevent two similar files from being confused during review.
Keep rejected and pending assets clearly separate from the release selection. If a client has approved one photograph from a session, do not assume every image from that session has the same status. Ask the responsible person to resolve uncertainties before the development team publishes the page.
Explain the crop the layout needs
Tell the designer what must remain visible. That could be a complete product, a person's face, a logo on a garment or the relevant part of a machine. A technically sharp photograph can still be unsuitable if the intended layout cuts away the detail that makes it useful.
Ask to see representative desktop and phone crops during design review. A wide hero and a narrow card may need different framing. If the same asset cannot serve both comfortably, provide an alternative composition or ask whether the layout should use a different treatment.
Avoid embedding important headings inside a photograph simply to make the first mockup look complete. Keep essential page copy available as actual text where practical. This gives the team room to adapt the layout and helps prevent a phone crop from removing the very message the image was expected to communicate.
Describe images according to their role
W3C's images tutorial distinguishes informative, decorative and functional images. An informative image needs a text alternative conveying its essential information; a purely decorative image can use an empty alternative. An image acting as a button or link needs an alternative that communicates its function.
Apply that guidance to the actual page context rather than writing the same description for every use of a file. A portfolio image might need to identify the relevant design application, while a repeated decorative crop may add nothing beyond the surrounding text. Ask the developer to explain how each role will be implemented.
For a complex diagram, put the important explanation in the page content as well. A filename or a long string of search terms is not a useful substitute for the information a visitor needs. Have someone who understands the service check that the description conveys the right point without inventing details.
Separate captions from text alternatives
A caption is visible editorial context. It can identify a project, explain an illustrative example or disclose that a scene is a concept rendering. A text alternative supports the image's information or function for people who cannot use the visual in the same way. The two fields can serve related but different purposes.
An illustrative caption might say “Reception signage concept for the proposed identity.” That wording avoids presenting the picture as proof of a finished physical venue. The surrounding project text can explain the design task and what was actually delivered, using facts the business is authorised to publish.
Review claims in captions as carefully as claims in headings. Do not add client results, production quantities or performance improvements just because an image feels like a success story. If evidence is unavailable, describe the visible application and its concept status without implying outcomes that the image cannot establish.
Record permission and brand accuracy
Identify where each asset came from and who approved its use. For commissioned photography, client material, stock assets and generated concepts, keep the relevant usage information with the project records. Ask for clarification when the team cannot establish whether a file is suitable for public release.
Check logos, packaging, uniforms and signage against the approved brand references. A beautiful mockup containing a wrong name or outdated mark is still the wrong asset. Inspect readable lettering before approval rather than assuming that a realistic scene guarantees accurate brand details.
If a picture includes people, private documents, screens or identifiable premises, review what is visible with the responsible business contact. Remove or replace material that has not been cleared for that use. The purpose of the image brief is to resolve those decisions before publication, when they are easier to track.
Give the developer usable source material
Supply the best available approved source files through an organised transfer. Avoid using a screenshot of a screenshot as the only copy when the original exists. Tell the team whether a file has already been cropped, edited or exported for another channel, so they can assess its suitability for the planned placement.
Ask the developer to prepare delivery versions appropriate to the website. The final choice depends on image content, display size and the site's implementation. Do not impose one arbitrary pixel dimension on every asset, from a tiny icon to a detailed project gallery.
Keep visual quality and page behaviour in the acceptance check. A page should not require the visitor to download unnecessarily large source assets, but aggressive reduction should not make relevant work look blurred. Review representative images in the finished page, where the actual size and surrounding content are visible.
Approve the page, not only the image folder
Once the images are placed, inspect the page on a phone and a larger screen. Look for awkward crops, unreadable details, mismatched captions and pictures that suggest a different service from the one described. Check image links and enlargement controls where those features are part of the design.
Review the image register against the displayed page. Confirm that every release asset is the approved version and that outstanding replacements are recorded. If a temporary image must remain, agree how its status will be communicated and who owns the replacement instead of allowing it to become an undocumented permanent choice.
Include image-maintenance responsibility in your broader website handover checklist. Staff who replace project pictures later should know how to maintain captions, descriptions and approval records, rather than treating an upload as a purely visual change.
Frequently asked questions
Should every image contain our main keyword in its description?
Write descriptions that serve the image's actual purpose. Repeating a search phrase across unrelated images does not explain what those pictures contribute. Use clear language and confirm the role with the person implementing the page.
Can generated mockups replace all project photographs?
They can illustrate concepts, but they should not be presented as evidence of physical work that was never produced. Keep their status clear and use factual project descriptions. Actual approved photographs and concept visuals can have different roles in the same portfolio.
Do we need a different image for mobile?
Sometimes an alternative composition is useful. First test the proposed crop. The key question is whether important content remains visible and understandable, not whether every page follows the same image-swapping rule.
What should we send before website design starts?
Send a page list, approved image folder, purpose notes, captions and any missing-asset requirements to Mocky's website team. A clear register helps the team propose a layout around relevant content and identify photography or mockup work that still needs to be scoped.
