LHLynHubOpen Design Collaboration
← Back to Help

How to Submit a Structured Review

A structured review is not just "looks good" or "don't like it". This guide explains how to write evidence-based strengths, issues, and improvement suggestions around dimensions like circulation, storage, daylight, materials, budget, and construction risk, along with a score and fork directions.

When to use this

Use this when you've browsed a design project or proposal and want to give constructive feedback. Structured reviews are suitable for: - You've noticed clear strengths or issues in a specific dimension (circulation, storage, daylight, etc.) and want to elaborate. - You have professional background and can give actionable improvement suggestions. - You've identified risks that may have been overlooked (construction difficulty, cost overrun, safety concerns, etc.). - You think a certain aspect is worth further forking and want to point out the direction. Unsuitable scenarios: - You just want to say "looks good", "nice", or "like it". - You want to express personal aesthetic preference without specific reasoning. - You want to advertise or direct off-platform contact.

What to prepare before you start

Before submitting a structured review: 1. Browse the entire project page: carefully review the project title, design goal, summary, highlights, areas for improvement, project images, and version tree. Don't review based only on the cover image. 2. Choose a review focus dimension: the page provides a dropdown of review focus options including circulation, storage, daylight, materials, budget, experience, feasibility, etc. Pick the dimension you're most focused on and build your review around it. 3. Prepare specific strengths, issues, and suggestions: every point should have specific evidence. Don't write "bad circulation", write "the path from kitchen to dining requires going around the living room, walking distance ~8m; consider adjusting the kitchen door direction, which could reduce the distance to 3m". 4. Give an overall score: the page has a 1-10 slider, defaulting to 7. Adjust based on your overall assessment. 5. If you have fork suggestions: describe which aspects are worth further exploration in the "directions worth forking" field.

How to fill in the key fields

The structured review page contains the following fields: - Reviewer name: your name or nickname. - Contact email: for platform review and communication only, not publicly displayed. - Overall score: 1-10 slider, drag to adjust. 7 means "overall good, with room for improvement". - Review focus: select from dropdown, e.g. "circulation", "storage", "daylight", "materials", "budget", "experience", "feasibility". Build your review around the chosen dimension. - Key strengths (required): list what the proposal does well, with specific evidence for each. E.g. "Entry storage design is well thought out: the 600mm deep cabinet on the right integrates shoe storage, coat hanging, and seating, addressing the request's pain point of 'shoes piling up at the entrance'". - Key issues (required): list problems in the proposal, explaining why each is a problem. Negative feedback is acceptable but must include reasoning. E.g. "The kitchen island is 1.8m long, but both side passages are only 700mm wide, below the 900mm comfortable walking width — two people operating simultaneously would feel cramped". - Improvement suggestions (required): give specific, actionable suggestions for the issues. E.g. "Consider shortening the island to 1.5m, or switching to single-side operation, widening one passage to over 900mm". - Risk reminders: highlight risk factors to watch for, such as construction difficulty, potential cost overruns, or safety concerns in use. - Directions worth forking: suggest which aspects deserve further exploration and improvement, providing starting points for subsequent forks. Three confirmation checkboxes at the bottom must be ticked: confirm the review is based on professional judgment not personal preference, confirm the review may be publicly displayed, agree to Community Guidelines.

What to check after submission

After submission, the page shows a "Submitted for review" screen listing the reviewer name, strengths, issues, suggestions, risk reminders, and fork directions. After submission, confirm the following: 1. Do strengths and issues all have specific evidence, not vague comments? 2. Are suggestions specific and actionable? If a suggestion is "fix the circulation" without saying how, it's essentially empty. 3. Does the score match your review content? If you wrote many issues but still scored 9, you may need to adjust. 4. Are all three confirmation checkboxes ticked? You can check your submission status on your account page (/zh/account or /en/account). Once approved, the review will be publicly displayed on the project page. Note: abuse, personal attacks, and advertising are prohibited in reviews. Negative feedback is acceptable but must include reasoning and suggestions. If a review only says "terrible" or "no good" without specifics, it will be considered invalid.

Common mistakes

Here are the most common mistakes when submitting a structured review: 1. Review too vague: writing "overall good", "circulation could be better", "not enough storage" without specifying what's good, what's bad, and how to improve. 2. Only negative without constructive suggestions: only pointing out flaws without offering suggestions. The purpose of a review is to help improve the proposal, not just criticize. 3. Review focus doesn't match content: selecting "daylight" as the focus but writing entirely about storage and circulation. 4. Score contradicts content: writing many issues but scoring 9, or only writing strengths but scoring 3. 5. Treating personal aesthetic preference as professional judgment: writing "I don't like this color" or "this style is ugly" instead of evaluating from functional, experiential, or feasibility dimensions. 6. Writing "none" for risk reminders: almost every proposal has discussable risks — at minimum, think from angles like construction difficulty, cost control, or usage safety. 7. Fork directions too vague: writing "can continue optimizing" instead of specifying which aspect is worth optimizing and in what direction.

Conduct guidelines

The following behaviors are prohibited in structured reviews: - Abuse, personal attacks, discriminatory remarks. - Advertising, leaving contact information, directing off-platform transactions. - Spam content unrelated to the design proposal. - Maliciously inflating or deflating scores. Reviews should focus on the design itself, addressing the proposal's circulation, storage, daylight, materials, budget, experience, and feasibility. If you believe a proposal has serious issues, specifically explain what the issue is, why it's an issue, and how to improve it. See Community Guidelines for detailed rules.