Ruankao E-Commerce Designer (Intermediate) common mistakes
Ruankao E-Commerce Designer (Intermediate) · Understand the traps and how to avoid them.
Treating the afternoon case study as a free-form essay: writing general commentary about e-commerce trends instead of answering the specific questions asked in the paper, and burying the required calculation or design answer in the middle of a long paragraph.
Candidates prepare by reading textbooks and memorising concept lists, so when a scenario appears they reproduce memorised prose rather than extracting the actual question stem (e.g. 'list three deficiencies in the current process and give the corrected flow'). Marking schemes award points per distinct, correct, explicitly stated item, so unstructured prose scores near zero even when it contains relevant knowledge.
What to do instead
Before writing, underline the question's command words and count the required items ('list three', 'draw', 'calculate', 'explain why'). Answer in numbered points, one idea per line, leading with the key term, and add the supporting sentence after it. Reserve the case text for evidence citations ('per paragraph 2, the payment step lacks reconciliation'). Practise by taking past-paper-style scenarios and writing only bullet answers under timed conditions, then comparing against the point allocation.
Confusing business-model vocabulary in multiple-choice items: labelling any online store a 'B2B platform', treating O2O, C2C, B2C, and B2B2C as interchangeable, or describing a revenue model (commission, subscription, advertising) as a business model.
The terms overlap in real companies, and candidates learn them from marketing articles rather than from the exam's analytical framing (who the payer is, who the seller is, where the transaction and fulfilment occur). Under time pressure the familiar-sounding option wins.
What to do instead
Build a decision table with axes: participant on the paying side, participant on the supplying side, whether the platform owns inventory, and where fulfilment happens. Classify five real platforms you use into that table and justify each cell. In the exam, identify the payer and the seller in the stem before reading the options, then eliminate options that describe a revenue stream rather than a participant structure.
Drawing architecture diagrams that show only boxes and arrows with no interface, protocol, or data-flow labels, and omitting the non-functional requirements (availability, peak concurrency, security zones) that the scenario explicitly states.
Candidates focus on getting the functional components right and treat the diagram as decoration; they also skip re-reading the scenario for numbers such as 'peak 5,000 concurrent users' or 'must survive single-node failure', because those numbers appear in prose far from the question.
What to do instead
Adopt a fixed diagram template: client tier, web/CDN tier, application/service tier, data tier, plus external payment and logistics interfaces; label every arrow with protocol and direction and every external system with its integration style (synchronous API, message queue, batch file). Then annotate the diagram with the scenario's stated constraints and one sentence per constraint explaining how the design satisfies it. Rehearse this template on three different scenarios until it takes under ten minutes.
Normalising a schema to third normal form and stopping there, without addressing the scenario's read/write ratio, indexing, sharding, or hot-data caching, and without stating keys and constraints explicitly.
Academic database courses reward normalisation as the endpoint, so candidates believe 3NF is the complete answer. Exam scenarios for e-commerce almost always include high read volume, order and inventory contention, or historical data retention, which require deliberate denormalisation or partitioning decisions.
What to do instead
For every schema question, produce four artefacts: the entity-relationship outline, the table definitions with primary, foreign, and unique keys plus nullability, the index list justified by the stated query patterns, and a short paragraph on partitioning or caching tied to the stated volume. Explicitly justify any denormalisation by naming the query it accelerates and the consistency risk it introduces.
Answering payment and security questions with a single word ('encryption', 'firewall', 'SSL') instead of specifying the mechanism, the protected asset, and the trust boundary it sits on.
Security and payment content is broad and candidates memorise acronyms without mapping each to the threat it mitigates. In scenario questions, an unspecific answer cannot be matched to a marking point.
What to do instead
For each control, write the triple: asset protected, threat mitigated, mechanism. For example, 'card number in transit - interception - TLS 1.2+ with HSTS'; 'card number at rest - database breach - tokenisation so the merchant stores only a gateway token'; 'repeat submission - duplicate charge - idempotency key on the payment API'. Memorise the payment lifecycle (authorise, capture, settle, refund, chargeback) and the third-party gateway versus direct-acquiring trade-off, since these recur.
Treating the English reading section as a translation exercise: reading slowly word by word, translating every sentence into Chinese before answering, and running out of time on the last passage.
Candidates with moderate English proficiency default to full translation because it feels safer, but the section tests locating information and inferring meaning under time pressure, not literary translation. Time lost on passage one cascades.
What to do instead
Read the questions first, then scan the passage for the keywords and their paraphrases (the exam rarely reuses the exact wording). Answer in passage order and skip any item that takes more than about ninety seconds. Build a personal glossary of about 150 recurring technical terms (scalability, throughput, idempotent, reconciliation, fulfilment, chargeback, latency) and drill paraphrase matching rather than translation.
Ignoring the operations and logistics half of a scenario: proposing an elegant system design while never addressing inventory allocation, last-mile delivery choice, return handling, or the fulfilment SLAs the case states.
Candidates with a development background gravitate to architecture and code, and the operations content feels like business common sense that needs no preparation. But the exam awards substantial marks for linking system capability to operational process.
What to do instead
After drafting any design answer, force yourself to add a short operations paragraph covering four items: inventory reservation and release rules, order-to-shipment state machine, reverse logistics for returns, and the metric each step is measured by. Prepare a one-page reference of fulfilment models (self-operated warehouse, third-party logistics, dropship, click-and-collect) with their cost, control, and speed trade-offs.
Writing project-management answers that name a methodology ('use Agile', 'do a risk assessment') without producing the artefact the question asks for, such as a work breakdown, a milestone schedule with dependencies, or a risk register with probability, impact, and response.
Methodology labels are easy to recall and feel responsive, but marking schemes look for structured content: identified tasks, sequencing logic, owners, and quantified risk exposure. Candidates also misjudge which phase a scenario sits in and prescribe the wrong process group.
What to do instead
Memorise three blank templates and fill them from the scenario: WBS with three levels and effort estimates, a milestone table with predecessor dependencies and float, and a risk register with likelihood, impact, exposure score, response strategy (avoid, mitigate, transfer, accept), and owner. State the project phase explicitly at the start of your answer so the examiner can see your assumption.
Treating standards and professional-practice items as trivia to skip, or answering them with invented standard numbers and document names.
This domain is a small share of marks, so candidates deprioritise it; when forced to answer they guess plausible-sounding identifiers. Fabricated specifics are penalised and also signal weak professional judgement in essay items.
What to do instead
Learn the small stable core rather than a long list: the purpose of software documentation standards, the distinction between requirements, design, and test documentation, basic quality-attribute vocabulary, and the professional obligations around intellectual property, data privacy, and honest reporting of test results. If you cannot recall an exact identifier, describe the standard's function and scope instead of inventing a number.
Mismanaging the clock: spending forty minutes perfecting the first essay question, then writing rushed one-line answers for the remaining questions that carry equal or greater marks.
The first question often feels most familiar, and candidates over-invest to secure it. Because marks are roughly proportional to required items rather than to prose quality, the marginal return on polishing question one is far lower than on starting question four.
What to do instead
Budget by marks, not by interest: allocate minutes proportional to each question's point value, keep a visible timer, and enforce a hard stop. Answer every question at a basic level first (all required items, one line each), then return to deepen answers with remaining time. Practise full papers under strict timing at least three times so the pacing becomes automatic.