Dadansoddeg / Nodyn maes
Mesurwch newid i'r broses dalu cyn ei alw'n welliant
Cysylltwch y rhagdybiaeth, diffiniadau digwyddiadau, gwiriadau'r daith a'r cofnod penderfyniadau cyn dehongli canlyniad trosi.
Mae’r nodyn maes hwn yn cael ei gyhoeddi yn Saesneg.
A redesigned checkout can feel clearer without yet proving that it performs better. The measurement plan should explain what changed, which behaviour is expected to change and what evidence would support a decision. Otherwise, a movement in a dashboard can become a story chosen after the fact.
Begin with a narrow question that connects the interface to an observable part of the journey. Keep the proposed outcome separate from any result until the work has actually been evaluated.
Write the hypothesis in ordinary language
For example: if delivery information is visible before someone begins checkout, fewer people may need to return to the product page to answer a delivery question. This identifies a change and a behaviour worth inspecting. It does not promise a conversion gain.
Name what would count against the idea as well. The new information might make the page harder to scan, or the existing checkout might already answer the question at the right moment. A useful hypothesis leaves room for the design to be wrong.
Agree on what the events mean
Map the journey before drawing a funnel. Google Analytics documents distinct ecommerce events for actions such as beginning checkout and making a purchase. The event names are only useful when the implementation fires them at the intended points and includes the relevant item information. Google's ecommerce measurement guide
Write a plain-language definition beside each event. If two checkout paths trigger the same event at different moments, the resulting comparison can be misleading even though the dashboard displays a neat sequence.
Check the experience beside the data
Walk through the changed flow on a phone and a desktop. Include an existing customer, a first-time visitor and an order that requires an option or a delivery choice. Check the interface, the event sequence and the return path after an interruption.
Keep a record of issues that could affect interpretation. A broken payment handoff or a missing event should be investigated as its own problem rather than folded into a general judgement about the design.
Record the context of the comparison
Traffic mix, promotions, product availability and the period being reviewed can all affect the story a team tells about a checkout. Write down relevant changes instead of assuming that the interface was the only thing that moved.
When running a controlled experiment, agree the decision method before reviewing the result. When a controlled comparison is not available, describe the limitations of the observation. A before-and-after chart can prompt useful investigation without establishing that one design change caused every difference.
