Motta Industries Blog

A redesign meeting can produce attractive mockups before anyone has agreed what the website must accomplish. The result is often a collection of visual preferences carrying unresolved business decisions. Those decisions return later as revisions, missing content, unexpected integration work, or disagreement about whether the project is finished.

Website redesign planning should make the consequential questions visible before appearance becomes the center of the conversation. Discovery does not need to be an endless consulting exercise. It needs to establish enough shared understanding to choose an appropriate scope, investigate important uncertainties, and explain what the next stage is supposed to prove.

Why does this project need to happen now?

Name the trigger in terms the business can evaluate. The site may no longer explain the offer, staff may be unable to make necessary changes, or customers may struggle with an important task. Outdated colors can be a concern, but they do not explain every operational or commercial problem attributed to the website.

Separate observations from interpretations. Customers asking the same question is an observation if there is reliable evidence. Assuming the entire site needs rebuilding is a proposed response. Discovery should consider whether the underlying issue calls for clearer content, a focused repair, a new feature, or a broader redesign.

Motta Industries’ website redesign service can help frame that decision. Describe the problem and the conditions in which it occurs rather than beginning with a list of fashionable components. The most useful outcome may be a smaller intervention than the business initially imagined.

Agree what would make the work worthwhile without inventing a forecast. A clearer customer route, a maintainable editing process, or a dependable handoff can be legitimate objectives. Each still needs an observable definition; a promise that the website will simply perform better leaves everyone free to interpret success differently.

Whose decisions must the website support?

Identify the people who need to use the site and the decisions they face. A first-time buyer comparing options needs different information from an existing customer checking a requirement. Avoid describing the audience only through broad demographics that do not explain what the person is trying to accomplish.

For a fictional equipment servicing business, customers may need to determine whether their machine is supported before asking for an appointment. Staff may need a usable enquiry rather than an immediate booking. Those distinctions affect the page content, form questions, and operating expectations long before anyone chooses a homepage layout.

Google’s August 2022 people-first content advice asks whether visitors learn enough to achieve their goals. That is a useful discovery question. The original advice is not being presented as a current ranking formula or evidence that a redesign will improve search performance.

Find appropriate evidence for the important tasks. Authorized aggregate information, staff knowledge, and relevant user research can inform decisions, but each has limitations. Do not turn one memorable complaint into a claim about every customer, and do not invent research findings to make a proposal sound more certain.

What should remain valuable after the redesign?

Inventory the existing pages, resources, features, and routes people rely on. A redesign is not a reason to discard everything that does not fit a new visual concept. Some plain-looking information may answer a high-consequence question or support an established customer process.

Record why an item matters and whether it needs keeping, improving, combining, or retiring. An old page with useful information and an old page that describes an unavailable service need different decisions. Avoid treating age alone as proof that content should disappear.

Include materials outside the main navigation. Downloaded instructions, campaign landing pages, and links shared by staff can still have an audience. Discovery should establish what is known and identify important gaps, rather than implying that a quick navigation review has captured the entire website.

Keep the evidence proportionate. The purpose is to guide decisions, not to accumulate reports nobody will use. A short inventory with clear owners and consequences can be more valuable than an elaborate spreadsheet whose categories do not influence the proposed work.

What happens after a visitor takes action?

The website is part of a business process. An enquiry may require review, a purchase may depend on inventory, and a requested appointment may need confirmation. Describe those transitions so the new interface does not promise something the organization cannot deliver.

Map the information that must move and the person or system responsible for the next step. Ask what happens when that handoff fails, arrives incomplete, or occurs outside ordinary working conditions. A polished success screen cannot repair an undefined operating process.

Motta’s custom website design service can connect the presentation to those requirements. A custom build is useful when it addresses a real constraint or workflow, not merely because the design differs from a standard layout. Specify the behavior the business needs before deciding how much customization it requires.

Distinguish existing integrations from desired ones. A future connection to office software may require separate investigation, access approval, or specialist involvement. Do not let a box on a diagram imply that a dependable integration already exists or that its implementation is included without discussion.

Which content decisions are not ready yet?

Identify missing facts, policies, examples, and approvals before designing around them. A page that depends on an unapproved pricing model or an uncertain service area carries a business decision, not just a writing task. Mark that dependency clearly in the project plan.

Assign responsibility for producing and approving content. The person with authority to explain a policy may be different from the person who edits the website. Agree how disagreements are resolved so a designer does not become the accidental decision-maker for matters outside the design brief.

Useful content also needs boundaries. Decide which claims require supporting evidence or qualified review, which information belongs in a customer portal, and which questions should be answered before someone contacts the business. A new layout should not quietly publish an offer the company has not approved.

A discovery summary should state what is known, what is assumed, and what remains unresolved. Those categories make it possible to move forward without pretending that every answer is final. They also help distinguish a genuine scope change from information that was explicitly uncertain at the outset.

What constraints belong in the brief from the beginning?

Accessibility, performance, privacy, security, editing capability, and relevant platform limits should influence the project before visual approval. Treating them as final checks can reveal that an attractive concept relies on behavior the site cannot responsibly support.

WCAG 2.2, published in October 2023, provides technical accessibility criteria relevant to planning and evaluation. The appropriate scope and assessment need qualified consideration. Choosing readable colors or adding labels does not establish complete conformance or resolve the business’s legal obligations.

Ask who will maintain ordinary content and what they need to change safely. A small team may need bounded editing controls more than unrestricted layout freedom. The discovery brief should distinguish those routine tasks from changes requiring development, training, or additional review.

Motta Industries’ UI and UX design work can help translate tasks and constraints into an interaction plan. Early examples should test the difficult decisions, not merely decorate an already familiar page. Choose prototypes or sketches according to the uncertainty they can resolve.

Will addresses or underlying systems change?

Google’s June 2014 site moves explanation distinguishes infrastructure changes without URL changes from moves that alter URLs. That foundational distinction is useful during discovery. A visual redesign does not automatically require a domain move or a different address for every existing page.

List the proposed changes separately: content, layout, platform, hosting, addresses, and connected systems. Combining them all under redesign conceals different kinds of work and risk. Ask which changes are necessary for the objective and which are preferences that can be evaluated independently.

If addresses will change, plan the relationship between old content and intended destinations. Relevant technical review should cover the transition and how important routes will be checked. This is planning guidance, not a current migration-tool recipe or a promise that search traffic cannot fluctuate.

Include the people responsible for existing business dependencies. A website change may affect resources owned by another team or supplier. Discovery should identify those boundaries early enough to coordinate the project, without assuming the redesign team can approve changes on everyone else’s behalf.

How will competing requests become a scope decision?

Discovery often reveals more useful work than the first release can reasonably contain. Separate essential requirements from preferences and future possibilities. For each consequential request, explain the customer or staff task it supports, the dependency it creates, and what would happen if it were deferred. That makes prioritization more concrete than voting on favorite features.

For the fictional servicing business, the ability to update supported equipment may matter more immediately than an elaborate animated introduction. A portal could be valuable but depend on unresolved identity and office-system questions. The discovery process should expose those differences without treating every attractive idea as equally urgent or equally understood.

Agree who can make tradeoffs and who must approve changes affecting operations or policy. Listening broadly is useful, but a project cannot rely on an unlimited sequence of competing approvals. Record the reason for important decisions so a later stakeholder can understand the scope without reopening the entire discussion.

Include the cost of maintaining a feature in that decision, not only the effort to launch it. New content collections, integrations, and interaction patterns need owners after the redesign team finishes. A feature that nobody can keep accurate may create a new problem even if its first presentation looks convincing.

A deferred item should have an understandable boundary. Identify any groundwork worth preserving and any assumptions that would need revisiting before implementation. Deferral is not a promise of automatic inclusion later; it is a deliberate choice about what the current project will and will not undertake. Keep those decisions visible throughout the project.

What must be decided before the next commitment?

Finish discovery with a decision-ready brief rather than a pile of meeting notes. It should explain the objective, important audiences and tasks, retained assets, operating dependencies, content ownership, constraints, unresolved questions, and proposed scope. State what is deliberately outside the first release.

Choose the next step according to the remaining uncertainty. A content inventory, integration investigation, interaction prototype, or focused technical repair may be more useful than a full set of polished mockups. The business should understand what it is approving and what evidence that stage is expected to produce.

A strong redesign begins with shared decisions, not a contest between favorite layouts. Answer the questions that control scope and risk, preserve what still matters, and leave room to investigate what is not yet known. Then the visual work can express a clear plan instead of concealing the absence of one.