How should a UI design case be written? What is truly convincing is not the number of pages

If the project name and Logo in a UI case are covered up and only a few dozen beautiful screenshots remain, it is difficult to prove the design ability. Aesthetic appreciation can be seen from the visuals, but business understanding, problem judgment, process selection, complex states and implementation promotion can only be perceived through narrative and evidence. The case is not a project album but an explanation of "why it was done this way".

01 A case only needs to prove one core competence

Don't try to cram in every meeting, every flowchart and every modification of the half-year project. First, determine what the readers should remember after reading: Are you good at complex enterprise, growth and conversion, design systems, user research, or building a product from scratch? Selecting materials around a core competence will make the case clearer.

02 It is recommended to use these eight sections of structure

03 First, clearly define your personal responsibilities. Don't attribute all the team's achievements to yourself

A project may be accomplished jointly by product, research, UI, content, development and operation. The case should clearly define the part you are responsible for, the extent of your participation and the final decision-making power. Honesty shows that collaboration does not undermine ability; instead, it proves that you know how design can be implemented in a real team.

04 Don't start with "We conducted user research.

The research method itself is not the outcome. Readers are more concerned about: What samples did you choose to answer for what question, what evidence did you obtain, and which design did these pieces of evidence change? Sticky notes, interview photos and screenshots of competing products that do not affect decision-making can be deleted.

Each process diagram in the case should be able to answer one sentence: Which decision did it change?

05 Presenting a abandoned plan is more valuable than showing ten perfect final drafts

There are always conflicts in real projects: efficiency and security, brand and readability, completeness of functions and launch time, business goals and user burden. Only by writing down the candidate plans, restrictive conditions and reasons for giving up can readers see their judgment ability. If the case goes smoothly from the problem to the final draft, it will seem like it was written after the fact.

06 Images should serve as evidence, not fill up the page

07 Reliable results can be written even without business growth figures

Not every project can achieve conversion rates, revenue or retention data. It is possible to clearly state the scope of the system that has been launched, the completion time of tasks, the reduction of errors, changes in customer service issues, the coverage of the design system, development rework, and user feedback. It's better not to write the "30% increase" that cannot be verified. If the result has not yet been verified, it should also be stated directly.

08 Confidential projects can remain anonymous, but they must not lose their specificity as a result

Customer names, amounts and sensitive data can be hidden while retaining industry, product stage, role, process complexity and key constraints. If all the details are changed to "certain platform" or "certain user", the case will lose its credibility. Anonymity does not equal abstraction.

09 A directly usable case writing template

• What stage are we at, for what type of users, and what business problems are we solving?
• My responsibilities: Which decisions, deliverables and collaboration links am I responsible for?
• Problem evidence: What facts led the team to confirm that the problem was worth solving.
• Key trade-offs: At least present one direction that has been abandoned and the reason for it.
• Solution implementation: Illustrate the completeness with processes, pages, statuses, and components.
• Result boundary: Which results have been verified and which remain subsequent hypotheses.
• Review: If starting over, what should be adjusted first?

10 The first page of the case first explains three things

Readers won't spend ten minutes understanding the background of the project first. At the beginning, it should be stated within a screen: What kind of product is this, what you are specifically responsible for, and what the most difficult constraints or results are. Then proceed with the process. Change "responsible for the entire project" to a verifiable scope, such as "responsible for information architecture, core processes, visual systems, and two rounds of development reviews". Change "Enhance experience" to specific tasks, such as "Unify the approval entry points for the three types of roles into one workbench."

11 Conduct a "deleted image test" before release

Hide all large images for the time being and only read the titles, main text and tables. If the case still enables people to understand the problem, judgment and result, it indicates that the narrative holds true. If only "we conducted research, made a prototype, and ultimately received favorable reviews" remains, it needs to be rewritten.

Frequently Asked Questions

How long should a UI design case be?

It is determined by the complexity of the problem. Simple visual revisions can be short, but more evidence is needed for complex enterprise or 0-to-1 products. The key point is not the word count, but whether readers can understand the responsibilities, make judgments and implement them.

Must the case include the complete design process?

No need. Only retain the processes that influence decisions. Applying the fixed pattern of "research - portrait - journey map - prototype - UI" will make the case look like a template and may also not match the real project.

Can a concept project that has not been launched be used as a case study?

Sure, but it must be indicated that it is a conceptual project, and the assumptions, limitations and verification degree must be explained. Don't turn high-fidelity concept maps into real business achievements.

Can customer reviews be used in cases?

Authorized, genuine evaluations based on identity and context can be used. Do not fabricate anonymous five-star reviews, nor let reviews replace verifiable project processes and results.