What a Website Redesign Really Means: Strategy, UX, SEO, and a Sustainable Improvement Process

A website redesign is not an event where a site is simply “made new.” It is a redesign of the site itself so users can understand it without confusion and take action with confidence. Outdated visuals or poor mobile usability are often what trigger the conversation, but in most cases the real causes run deeper: an information structure that no longer matches the site’s purpose, fragmented pathways, operations that have stopped updating, and systems that no longer support measurement and improvement. When only the surface is repainted, what improves is often limited to appearance or short-term likability. Outcomes such as inquiries, applications, and purchases remain difficult to grow, and users may instead be left with a vague feeling that “something changed, but I’m not sure what.” That is why a website redesign should be understood not as a visual refresh, but as an act of restructuring the site so that users can receive the materials they need to make decisions in the right order and move naturally toward the intended action.

What makes redesign difficult is that failure rarely comes from one isolated mistake. It usually happens through a chain of vague goals, lack of alignment, gaps in migration planning, and weak post-launch operations. When the objective is unclear, requests multiply, the structure swells, reviews turn into debates about taste, and the result becomes a site that looks polished but does not perform. If migration planning is weak, SEO and measurement break, and the team ends up with a site that was rebuilt but still does not grow. To succeed, the project needs aligned definitions and judgment criteria from the beginning, clear KPIs, deliberate pathway and content design, and a durable foundation that includes SEO, measurement, and operations. This article organizes the topic in a practical sequence, from definition to purpose, necessity, process, and evaluation.

1. What a Website Redesign Is

A website redesign means rethinking and rebuilding an existing site at a substantial level. It differs from partial updates or minor improvements because it includes reorganizing the site’s information structure, pathways, content strategy, UI/UX, technical foundation, and operational system to better match business goals and user behavior. Put differently, the main purpose of a redesign is not to change the shape of the current site. It is to make the site capable of fulfilling its intended role in a way that produces results. Visual style, functionality, and page count are outputs, not starting points. The first thing that should be designed is the user’s decision path: what they need to know, where they hesitate, what makes them anxious, and in what order they can feel convinced enough to act.

A redesign is also not complete the moment the new site goes live. Right after launch, numbers are often affected by migration impact, seasonality, and changes in traffic channels, so judging success or failure from short-term fluctuations alone often leads to bad decisions. What matters more is whether the team is able to measure, identify bottlenecks, and continue improving after launch. When redesign is framed not as the completion of a deliverable, but as the creation of a state where improvement can continue, the site becomes much more likely to generate stronger results over time and remain stable even as updates accumulate.

1.1 Clarifying the Difference Between a Redesign, an Update, and an Improvement

In web projects, the terms update, improvement, and redesign are often used interchangeably, and that confusion tends to create misalignment around scope and expectations. An update is the act of replacing information while keeping the existing structure intact. It typically includes adding news, changing wording, or swapping images. An improvement is a response to a specific problem, such as shortening a form, adjusting a CTA, or improving speed. These are usually localized efforts meant to lift performance within an existing design framework. Both of these approaches assume that the underlying structure is still broadly sound.

A redesign, by contrast, changes the underlying assumptions themselves to better match the current purpose. When the pathways are twisted, information is scattered, terminology is inconsistent, and operations are clogged, repeated local improvements tend to leave the overall confusion intact. At that point, results stop improving unless the structure itself is reworked. For example, even if the homepage is polished, evaluation still stalls if comparison materials are scattered. Even if the form is shortened, inquiries may not increase if pricing or conditions remain unclear. The practical question is whether the problem is local friction or structural distortion. That distinction determines the right approach.

A short way to think about the difference is this:

• Update: keep the current structure, but refresh the information inside it
• Improvement: fix a specific bottleneck to push results upward
• Redesign: restructure the system around the goal and create a stronger foundation for growth

When this distinction is clear, it becomes easier to define what should be done now, how far the effort should go, and how to align stakeholders around scope and budget.

1.2 What a Website Redesign Should Include

The scope of a redesign goes far beyond appearance. It includes information design, meaning what is shown and in what order; pathway design, meaning whether users can move forward without confusion; content design, meaning whether the materials needed for consideration are actually available; and technical design, meaning speed, security, and CMS operations. Strengthening only one of these almost always creates imbalance. A visual refresh alone does not make information easier to find. Shorter pathways alone do not solve weak comparison materials. A new CMS alone does not solve operational bottlenecks if workflow and governance remain broken. In practice, scope should be determined not by asking “What should we make?” but “What needs to be made possible?”

It is also usually more effective to redesign deeply around the areas tied directly to the goal than to attempt to improve everything evenly. When the business objective is translated into a set of priority pathways and critical page groups, budget and time can be concentrated where they matter most. By contrast, redesigning unimportant pages to the same depth often weakens the attention paid to core pathways and migration planning, leaving less room for actual performance improvement. Once the priority pathways are clear, reviews also become easier to align because the central question becomes whether those pathways are being strengthened.

A few perspectives are especially useful when deciding scope:

• the shortest route from entry to core understanding to action
• the materials needed for decision-making, such as comparison, pricing, case studies, specifications, and support
• areas that require frequent operational updates, such as news, case studies, FAQ, or recruiting pages
• SEO-critical page groups, such as intent-based landing pages, categories, and detail pages

Using these criteria helps teams converge not on “pages we want,” but on “pages required for outcomes,” which creates a structure that remains stable even as the site grows.

1.3 Common Misunderstandings About Website Redesign

Because redesign projects are highly visible, attention often goes to obvious elements such as design style, page count, or tools. If misunderstandings around those elements are left unresolved, agreement tends to break down in later stages. Common examples include believing that visual refresh automatically means better performance, that more pages automatically mean better SEO, that changing the CMS will automatically make operations easier, or that the project is finished at launch. In reality, outcomes are determined by the combined quality of pathways, information structure, content, and trust design. SEO can rise or fall dramatically depending on migration planning and internal structure. Operational ease depends less on the tool itself than on permissions, templates, review rules, and publishing workflow. If post-launch improvement never starts, a redesign ends as nothing more than a newer-looking site.

The problem is not that these misunderstandings are simply “wrong.” The problem is that they distort investment decisions. Too much money gets pushed into visuals while migration planning stays thin. Page volume increases and produces duplication and weak content. A new CMS is introduced without any change to governance. In each case, the team accidentally builds the reasons performance will not improve. Reducing misunderstanding means moving the project’s criteria from preference to performance conditions. Sharing the typical patterns early helps keep discussion from drifting and keeps quality more stable.

When these misunderstandings are clarified early, priorities become more stable, implementation and migration become stronger, and the post-launch improvement loop becomes easier to run on the same logic.

2. The Purpose and Role of a Website Redesign

The purpose of a website redesign is not to make the site “look nicer.” It is to turn the site into a system that produces results. Those results vary depending on what the site is expected to do: generate sales, inquiries, document requests, job applications, store visits, brand understanding, or reduced support burden. Different roles require different information orders, pathway designs, and content structures, which is why the first thing that needs to be fixed is what role the site is actually meant to play. A site treated as a corporate brochure is designed very differently from a site treated as a sales device that moves evaluation forward.

Once the role is fixed, reviews stop revolving around taste and begin revolving around whether the site can actually fulfill that role. Instead of asking whether the first view looks flashy enough, the question becomes whether a first-time visitor can understand the value within a few seconds and know where to go next. When that kind of question becomes the common language, even growing internal requests can be sorted by priority more easily, and the site becomes less likely to turn into a place where everything is present but nothing is clear. A purpose-driven structure also tends to remain more stable as content grows over time.

2.1 Translate Business Goals Into Site Roles

Even for the same company, a site’s role changes depending on context. In B2B, the site often functions as a device for building trust and moving evaluation forward. In B2C, it is more often a device for reducing hesitation and making purchase easy. In recruiting, it becomes a device for making the working experience tangible and reducing uncertainty around applying. The more clearly the role is defined, the more naturally the page structure, information order, and priority materials fall into place. When the role remains vague, each department brings its own definition of what is “correct,” and the site’s information and pathways split apart. Users then get stuck at the level of “where should I look first?” and action stops.

A useful way to define site roles is to translate goals into user actions:

• “Increase inquiries” becomes “provide comparison materials and make inquiry easy without confusion”
• “Increase job applications” becomes “make the job reality and expectations clear and reduce application friction”
• “Increase purchases” becomes “remove anxiety and make the cart-to-checkout path short and clear”
• “Reduce support burden” becomes “strengthen self-service resolution and reduce unnecessary inquiries”

Once the role is described in that form, discussion shifts from “what should the site contain?” to “what must the site make possible?”

2.2 Remove User Goals and Anxiety Early

The moment users arrive at a site, they already have a goal and a set of anxieties. The goal may be to understand pricing, compare options, learn the implementation process, or see examples. The anxiety may be whether the choice is safe, whether the company can be trusted, whether there are extra costs, or whether operation after adoption will be difficult. In many underperforming sites, the issue is not lack of information itself, but that the needed information is not presented in the right place and order. Users cannot decide, so they quietly leave. Because they rarely articulate the reason clearly, this becomes a structural design challenge more than a feedback problem.

Anxiety is often reduced more effectively through structure than through sheer volume of text. Pricing is often better explained through logic, ranges, and the path to getting an estimate than through exhaustive detail. Case studies work better when users can find them by industry or problem rather than simply seeing a long list. Support and contract conditions often reduce more abandonment when placed near the point in evaluation where the uncertainty arises than when buried deep in the footer. Aligning the site to the user’s thinking order is one of the most effective things a redesign can do.

2.3 Connect Purpose to KGI and KPI

When purpose remains abstract, it becomes hard to judge whether the design is good or not, and post-launch improvement often stops. A practical solution is to define KGI and KPI together and make it clear which KPIs the redesign is expected to move. KPIs should include not only “numbers we want to increase,” but also the friction that should be reduced, so that design and operations connect more naturally. Since CVR alone rarely reveals the cause of performance change, it is often more useful to break outcomes down by stage: reach rate, click rate, completion rate, and so on. It is also often necessary to connect quantity metrics to quality metrics, such as lead quality or recruiting pass-through rate, so that the site is evaluated in terms of actual business value.

The point of KPI design is not measurement alone. It is to align design decisions. When metrics are defined in advance, the team can identify what to improve much faster after launch, and the site becomes something that grows stronger through iteration.

3. Signs That It Is Time to Consider a Website Redesign

The need for a redesign usually appears through both numbers and day-to-day operations. In the numbers, it may show up as worsening bounce rate, weakening conversion rate, falling search traffic, or concentrated abandonment on specific pathways. In operations, it often appears as content updates slowing down, repeated customer questions increasing, the sales team failing to use the site as a decision aid, or the team struggling to add new content. Looking at only one side tends to lead to misjudgment. For example, metrics may not look terrible yet, but if sales keeps building supplementary materials outside the site, the site may already be failing as a decision-making tool. On the other hand, the internal team may feel no urgent pain while search traffic quietly declines because the structure is no longer competitive.

The longer these signs are left alone, the more expensive the problem becomes. There is usually a period where UX or information-structure distortion can still be patched through local fixes, but once the whole system enters a state where “everything breaks when touched,” a full redesign becomes unavoidable. Recognizing the signs early and separating what can still be solved through improvement from what now requires redesign helps optimize investment. This matters particularly for SEO and operations, because both often deteriorate quietly before revenue visibly drops.

3.1 Signs Visible in Data

Numerical warning signs become more useful when examined as pathways instead of isolated metrics. If CVR drops, the issue may lie in traffic quality, failure to reach key pages, or a breakdown at the form level. If search traffic falls, examining intent-based page groups such as problem-solving, comparison, case-study, and pricing content tends to reveal structural weaknesses better than looking only at the total. Data shows what is happening. The practical next step is to separate the phenomenon clearly, form a hypothesis about why it is happening, and define it in a way that can be tested. The better this is done, the more precise redesign requirements become.

This kind of analysis is not meant to conclude that all bad numbers require a full rebuild. Its value lies in isolating which part of the structure is weak so that effort can be focused where it matters most.

3.2 Operational Warning Signs

Operational signals show whether the site is functioning as a results-producing system. Content updates becoming overly dependent on one person, information remaining outdated, new pages taking too long to add, or CMS constraints causing expression problems are all strong signs that the operational side is clogged. Once operations slow down, information loses freshness, trust drops, and performance tends to follow. A website always assumes ongoing updates, so weak operations affect performance quietly but steadily. This is especially true for FAQ, case studies, pricing explanations, and other materials that directly support decision-making. When these stop being updated, users cannot resolve uncertainty and abandonment tends to rise.

Typical examples include:

• only a few people can update the site, so publishing stops when they are unavailable
• approval flow is unclear, so updates take too long to go live
• there are no templates, so each update starts from confusion
• old pages accumulate, increasing duplication and contradiction

When these signs are present, redesign often creates more value when operations are fixed before visuals. Once those bottlenecks are removed, post-launch improvement starts to run, and the site begins to accumulate performance over time.

3.3 Technical and Security Warning Signs

Technical aging often breaks the experience before users ever comment on visuals. Slow loading, heavy mobile interaction, unstable forms, or delayed security updates all connect directly to distrust and abandonment. Instability in key pathways such as forms or payments can reduce performance sharply. Because users usually do not explain these reasons in detail, technical problems often surface only as vague feelings of inconvenience or lack of trust. That is why technical warning signs need to be treated early and as part of performance, not as “IT issues.”

Typical signs include:

• worsening page speed, especially on mobile networks
• rising error rates in forms, search, login, or other core interactions
• security response delay, especially in old CMS or plugin environments
• broken measurement or tagging, which makes improvement impossible

Changing the CMS can be useful, but it becomes dangerous when tool replacement becomes the goal in itself. Technical investment connects to results only when it is designed together with how updates will happen, how checks will be made, and how improvement will continue afterward.

4. The Basic Website Redesign Process

Website redesign generally moves through planning, design, implementation, migration, launch, and improvement. The most important thing is to define clearly in the first half what needs to be fixed, and in the second half to migrate without breaking what matters. When the first half is weak, production proceeds with increasing rework and inflated cost. When the second half is weak, SEO and measurement break at launch and performance drops. It is useful to think of the process not merely as a production order, but as an order for preventing failure. In particular, pathways, content, SEO, and measurement become expensive to fix late, which is why alignment should happen as early as possible.

The more stakeholders are involved, the more important it becomes to fix performance indicators, priorities, decision rules, and exception handling early. It also helps to define before launch what will be monitored afterward, how often improvement meetings will happen, and who makes decisions. Process design is not glamorous, but it has a major effect on whether results can be reproduced.

4.1 Current-State Analysis and Defining the Problems

The first step is to describe the problems of the existing site as structural problems rather than cosmetic ones. Metrics such as pageviews or time on page do not by themselves show whether the site is helping users achieve a goal, so pathways should be broken down into entry, core understanding, and action to identify where they stall. Starting from the success action, such as inquiry or application, and tracing backward often makes bottlenecks more concrete. Inquiry logs and sales feedback also reveal friction that numbers alone miss, such as unresolved anxiety, weak explanation, or inconsistent terminology. What matters is to avoid reducing the issue to “the UI looks old” and instead describe it as “the site fails to provide the decision material users need, in the order they need it.”

Content inventory is equally important. Without understanding what exists, what is missing, what is duplicated, and what is outdated, redesign often reproduces the same structural problems under a new visual style. The purpose of an inventory is not just to delete content. It is to clarify roles and reassign them. Entry pages and detail pages can be separated more clearly, overlapping themes can be consolidated, and outdated explanations can be replaced with updated structures. The real value of the inventory is that it makes it possible to decide what should be explained, and where.

Useful materials to have aligned at this stage include:

• breakdown of performance pathways, such as reach, click, and completion rates
• intent alignment of entry pages, especially mismatch between search intent and actual content
• classification of inquiry reasons, to identify missing or unclear information
• content inventory showing duplication, gaps, outdated material, and role ambiguity

The more clearly these are defined, the more specific later discussion becomes and the less rework tends to happen.

4.2 Requirements Definition

Requirements definition is where the team fixes the target audience, objectives, priority pathways, required pages, required functions, constraints, and measurement approach. If this stage is vague, design review drifts into taste and agreement breaks down. In practice, requirements work less like a specification sheet and more like a decision framework for the rest of the project. It should be documented in language clear enough that everyone reading it arrives at the same interpretation. In particular, the priority pathways, the most important page groups, and the must-have quality conditions at launch, such as speed, form reliability, and measurement accuracy, should not remain vague.

It is also easier to manage when requirements are separated into must-have and desirable. As the must-have list grows, schedule and quality usually break. It is more realistic to prioritize the pathways tied most directly to outcomes and then continue improving other areas after launch. Explicitly stating the constraints, such as budget, timeline, staffing, and system dependencies, also reduces endless debates about what is ideal but unrealistic. The real function of requirements definition is to surface future points of conflict early and agree on how those decisions will be made.

The clearer this structure is, the less likely the team is to lose sight of what the redesign is actually supposed to achieve.

4.3 Information Design and Pathway Design

Information design determines where users can find what they need. Pathway design determines how they move from one stage to the next. Both matter more than appearance when it comes to performance. If pricing assumptions are unclear, case studies are difficult to find, or comparison materials are scattered, the evaluation process stops even if the design looks good. Users are often not unwilling to read. They simply do not have the materials needed to decide. That is why pathway design should not focus only on shortening the route, but on placing the needed materials in the right order and reducing hesitation.

The “shortest path” is not always the only correct answer. In B2B, where evaluation takes time, users often need a sequence such as comparison, proof, pricing, and then inquiry. In ecommerce, the priority may instead be reducing anxiety around shipping, returns, delivery timing, or stock. When pathways are designed to match the user’s actual decision process, increasing traffic is less likely to become waste, and acquisition efficiency improves as well. Since pathway strength depends not only on the quality of key pages but also on the connections between pages, internal links and CTAs work best when they are embedded naturally into the content flow rather than feeling bolted on.

Practical design viewpoints include:

• shortest routes by entry type, such as search, ads, social, or direct visits
• order of the next material users should see, such as comparison, proof, then action
• proactive placement of materials near typical anxiety points, such as pricing, proof, conditions, and support
• recoverability, such as current-location clarity, breadcrumbs, state retention, and return paths

When these are defined clearly, the site remains more stable as information grows and is much easier to improve later.

4.4 Design, Implementation, and Migration

Design is not just about visibility and branding. It is also the process of visualizing information priority. The first things users need to see, the next things they should compare, and the place where action should naturally happen all need to be visually legible. Accessibility and responsive behavior should be treated as built-in requirements from the start, since bolting them on later often causes breakdowns. Forms and critical pathways especially need careful design beyond appearance. It matters less how a button looks than whether errors make the next step clear, inputs are preserved, and duplicate submissions are prevented. That kind of completion reliability is often the real foundation of outcomes.

In migration, protecting SEO and measurement is one of the highest priorities. If URLs change, redirects need to be planned. Titles and headings need to stay aligned with search intent. Internal links need to remain functional. Sitemaps and tracking tags need to be ready. Content migration also needs more than mechanical transfer. Rules and review processes should exist, with the most important pages prioritized first for accuracy. Migration should be treated not as the final step of production, but as a stage where the future performance foundation is protected. Fixing broken tracking or collapsed search visibility after launch is far more expensive than preventing the issue beforehand.

This kind of migration checklist reduces the risk of last-minute omissions, which tend to happen most when production pressure is highest.

5. Common Failure Patterns in Website Redesign and How to Avoid Them

Website redesign often fails less because of design mistakes than because of process mistakes. Objectives drift, alignment never solidifies, scope expands, SEO and tracking are overlooked, and post-launch iteration never happens. Avoiding these outcomes does not require anything magical. It requires deciding the important things early, protecting what must be protected, and designing the project so that improvements can keep accumulating over time. In particular, fixing priority pathways, must-have quality standards, and the post-launch improvement structure early greatly reduces drift during production.

The larger the group of stakeholders, the stronger the pressure becomes to satisfy every request. But redesign is not the process of granting all wishes. It is the process of converging toward a structure that improves results. When priorities and decision criteria are fixed, and when exceptions are deliberately defined as “later,” the scope becomes far less likely to spiral out of control. Accepting from the start that improvement will continue after launch also reduces perfection-driven delays and usually makes useful results appear sooner.

5.1 The Goal Drifts and the Site Becomes Merely “Nice”

When the purpose remains vague, departmental requests accumulate, information grows, and pathways become more complex. The result is a site where nobody can clearly say what it wants users to do, and users end up confused. This is one of the most common ways a visually polished site still fails. The best defense is to fix the KGI, KPI, and priority pathways early, and then clearly define each page’s role as an entry point, comparison stage, source of proof, or action point. Once roles are explicit, it becomes much easier to decide what should and should not be included, which prevents collapse through information overload.

Useful countermeasures include:

• fix the role of the homepage in a single sentence
• decide the priority pathways, such as inquiry or application, before design expands
• define explicit rules for what can and cannot be added
• connect review criteria back to KPIs so discussions do not drift into taste

This helps keep the site coherent even as requests grow, and it creates a structure that is far easier to improve after launch.

5.2 SEO and Tracking Migration Accidents Damage Performance

Post-redesign ranking drops often happen not because the strategy was bad, but because migration operations failed. URLs are not redirected properly, internal links break, titles drift away from search intent, duplicate pages appear, or tracking tags disappear. The best defense is to treat SEO and tracking migration as required workstreams with assigned responsibility and checklists, rather than side tasks to be handled later. The busier production gets, the easier it is for these things to slip, which is why they need explicit owners and deadlines.

Minimum checks worth protecting include:

• ranking legacy URLs by importance and creating a priority migration map
• reviewing title and search-intent alignment on the most important pages
• testing pathway-level tracking for clicks and form-stage completion
• deciding which items will be monitored immediately after launch, such as 404s, indexing, and missing data

This level of discipline reduces launch chaos and makes it possible for meaningful improvement to begin quickly.

6. Evaluation Metrics and the Improvement Loop After a Website Redesign

A redesign that ends at launch will inevitably degrade over time. Real value appears only when the team continues to see which KPIs are moving, where pathways are blocked, and what should be improved next. Looking only at top-level numbers often slows improvement. When the pathway is broken down into stages, such as whether traffic is reaching the right pages, whether those pages are persuading users, and whether the form or next step is being completed, action becomes more concrete. In practice, the speed of improvement usually depends on how clearly the team can see where users are getting stuck.

Improvements after launch often work best not through dramatic changes, but through friction removal. Shorter pathways, better information order, stronger comparison materials, and improved error handling usually affect outcomes more directly than large visual revisions. When the redesign includes good measurement, operational ownership, and a clear improvement process, it becomes not a one-time event but a growth system. Sites built for improvement get stronger over time. Sites where improvement stops simply become outdated again, no matter how new they once looked.

6.1 KPI Design After Launch

It is often useful to separate post-launch KPIs into short-term, mid-term, and longer-term indicators. Short-term indicators tell whether the site is functioning properly as a system. Mid-term indicators show whether evaluation is actually progressing. Long-term indicators reflect the accumulation of trust, such as natural search, branded search, and repeat visits. If teams react too aggressively to indicators that need more time to move, they can damage the underlying structure. That is why KPI design by time horizon tends to produce more stable decisions, especially in SEO, where movement unfolds gradually.

It is also useful to define stop conditions in advance so that teams know when to act quickly:

• if form completion rate worsens beyond a threshold, fix immediately
• if 404 errors increase sharply, review redirect logic
• if tracking data disappears from key page groups, restore tags first

These rules make post-launch operation less dependent on individual judgment and keep improvement moving.

Conclusion

A website redesign is not simply a task of refreshing the UI. It is a management-level project that rebuilds the order of information and the flow of action in response to changes in business strategy, target users, and competitive conditions. The first question should always be what the redesign is meant to grow. That goal should then be translated into KPIs, and those KPIs should be broken down into user actions the site needs to support. Once priority pathways are defined, each page can be given a clear role and the necessary content and functionality can be organized around those roles. Only then does design carry real meaning. The homepage becomes the entrance to value and trust. Service pages deepen understanding. Case studies make the offering concrete. FAQ removes uncertainty. When structure remains weak, a visual refresh only increases confusion as information expands. But when purpose and pathways are consistent, growth becomes more stable and understanding remains easier even as content grows.

The outcome of a redesign is also strongly shaped by migration and post-launch design. On the SEO side, URL planning, redirects, internal linking, and title and meta structure need to be handled systematically so that search equity is not damaged. On the measurement side, conversion definitions need to be rechecked, key events redesigned, and data collection validated in a testing environment before launch. It also helps to separate evaluation into short, medium, and long timeframes, so that launch-day anomalies, mid-term conversion improvements, and longer-term search and brand indicators can each be judged in the right context. The value of a redesign is not maximized on launch day. It becomes valuable over time when the structure keeps supporting improvement. Visual change is only the trigger. The real substance is creating a site that users can understand without confusion and act on with confidence, then supporting that with data and operations so results become reproducible.