+ Carefully separates evidence, uncertainty, and inference.
- Sound but somewhat repetitive and could be more concise.
Looks for what they gave up, and states what cannot be known from outside.
| Category | Design › Design collaboration |
|---|---|
| Tags | AnalyzingReviewingIdeation |
Take apart how another product solved this. ***Not to copy it — to find what they decided.*** 1. **What problem does this screen solve for their user**, from what I described 2. **Decisions I can see**, and ***what each one gives up.* **Every choice costs something; name it** 3. **What they chose not to do** — ***the absence is a decision too.* **A missing feature, a hidden option, a step they removed** 4. **What their constraints probably were** — ***business model, scale, who their user is.* **Mark this as inference** 5. ***Where their situation differs from mine.* **This is the part that decides whether anything here transfers** **Then:** - ***What actually transfers*** versus **what only works because of something they have that I do not** - **What looks good and would be wrong for me**, ***with the reason*** - ***What I cannot tell from the outside*** — **whether it works, whether users complete it, whether they are about to change it.** *A polished screen is not evidence of a good decision* ⚠️ ***Do not assume anything about their product beyond what I described.* **Do not recall their features, metrics, or history from memory.** ***Do not reproduce their copy or assets*** — **this is for understanding decisions, not for copying.**
Looking at a competitor shows results, not decisions — and a polished screen is no evidence that it works. This reads each choice with its cost and separates what transfers from what only works for them.
ChatGPT is strongest because it respects the evidence limits while giving actionable transfer guidance. Gemini is well structured but substantially speculative, and [C] was not provided.
+ Carefully separates evidence, uncertainty, and inference.
- Sound but somewhat repetitive and could be more concise.
+ Clearly structures transferability and contextual differences.
- Invents UI details, users, and business constraints as facts.
| Criterion | ChatGPT | Gemini | Leader |
|---|---|---|---|
| Instruction following | 9 | 5 | ChatGPT +80% |
| Accuracy | 9 | 2 | ChatGPT +350% |
| Specificity | 8 | 7 | ChatGPT +14% |
| Structure | 9 | 9 | Tie |
| Right length | 8 | 6 | ChatGPT +33% |
Scored 1–10 by gpt-5.6-sol with model names hidden (2026-09-25). This is an AI review, not a measurement.
We gave three models the same input and copied their answers unedited. Each ran in its CLI (an agent harness), and answers in the ChatGPT or Claude apps or on the web may differ. Outputs are in Korean.
What they do: 토스증권 앱의 '내 자산' 탭 화면 What I am trying to solve: 가계부 앱에서 여러 은행 계좌·카드·투자 자산을 한 화면에 요약해서 보여주는 대시보드를 설계해야 하는데, 총액을 맨 위에 크게 보여줄지 카테고리별 목록을 먼저 보여줄지 정하지 못하고 있다
아래 분석은 제공된 정보가 “토스증권 앱의 ‘내 자산’ 탭”이라는 사실뿐이라는 전제에서, 화면의 세부 UI·기능은 추정하지 않고 진행합니다. 정확한 배치와 상호작용은 화면 캡처가 있어야 판단할 수 있습니다.
사용자가 가진 금융 자산을 개별 상품 단위로 찾아다니지 않고, “지금 내 자산 상태가 어떤가?”를 빠르게 파악하게 하는 문제로 보입니다.
특히 ‘내 자산’이라는 진입점은 다음 질문에 답하려는 화면일 가능성이 큽니다.
다만 이것이 투자 판단용인지, 순자산 확인용인지, 단순 조회용인지는 화면명만으로는 알 수 없습니다.
화면명을 기준으로 확실히 읽을 수 있는 선택은 자산을 개별 투자 화면과 분리해 한곳에 모았다는 것입니다.
| 선택 | 얻는 것 | 포기하는 것 |
|---|---|---|
| ‘내 자산’을 별도 탭으로 둠 | 사용자가 자산 현황을 찾기 쉬움 | 거래·주문 같은 행동보다 조회가 우선인 구조가 됨 |
| 자산을 한 화면에서 보여줌 | 여러 항목을 오가며 기억할 필요가 줄어듦 | 복잡한 금융 정보를 한 화면에 압축해야 하므로 세부 정보가 줄어듦 |
| 자산을 중심으로 묶음 | 사용자의 관심을 “무엇을 보유했나”에 집중시킴 | 수익률, 거래, 목표, 현금흐름 같은 다른 관점은 뒤로 밀릴 수 있음 |
다만 총액을 먼저 보여주는지, 카테고리를 먼저 보여주는지는 현재 정보만으로 확인할 수 없습니다.
두 방식의 비용은 명확합니다.
확인 가능한 정보가 제한되어 있어 특정 기능의 부재를 단정할 수는 없습니다. 다만 화면이 ‘내 자산’ 탭으로 설계되었다는 것에서, 적어도 진입점의 핵심을 거래보다 현황 조회에 둔 것으로 해석할 수 있습니다.
가능한 생략은 다음과 같습니다. 단, 이는 화면을 직접 보지 못한 상태의 분석 후보입니다.
가계부 앱이라면 여기서 더 중요한 부재가 생깁니다. 예를 들어 총자산만 보여주고 부채, 결제 예정액, 현금흐름을 숨기면 화면은 깔끔해지지만 사용자는 실제로 쓸 수 있는 돈과 순자산을 혼동할 수 있습니다.
다음은 모두 추론입니다.
이 추론들이 틀리면 화면의 설계 의도도 달라집니다.
여기가 가장 중요합니다.
토스증권의 ‘내 자산’과 가계부 앱의 통합 대시보드는 이름은 비슷해도 사용자의 질문이 다를 수 있습니다.
| 상대 화면일 가능성이 높은 질문 | 당신의 앱에서 사용자가 할 질문 |
|---|---|
| 내가 보유한 투자 자산은 무엇인가 | 내 돈이 전체적으로 어디에 흩어져 있는가 |
| 투자 자산의 현재 상태는 어떤가 | 이번 달에 얼마를 쓸 수 있는가 |
| 특정 자산 상세로 이동할까 | 지출을 줄여야 하는 곳은 어디인가 |
| 자산 규모를 확인할까 | 순자산, 현금, 카드 사용액을 어떻게 해석할까 |
상대는 자산 조회가 제품의 핵심일 수 있지만, 당신의 앱은 자산 요약과 생활 의사결정을 동시에 지원해야 할 수 있습니다.
또한 당신의 데이터는 다음처럼 더 복잡할 가능성이 큽니다.
따라서 “가장 큰 숫자를 위에 둔다”는 결정은 단순한 시각적 우선순위가 아니라 무엇을 자산으로 계산할지에 대한 신뢰 문제가 됩니다.
이 기반이 없다면 상대의 구조를 그대로 가져와도 사용자는 “총액은 알겠는데 이게 왜 이렇게 계산됐는지 모르겠다”고 느낄 수 있습니다.
좋아 보이는 이유는 강한 시각적 위계와 빠른 인지입니다.
하지만 가계부에서는 총액의 정의가 모호할 수 있습니다.
정의가 불명확한 총액은 유용한 요약이 아니라 오해를 크게 만드는 숫자가 됩니다.
은행·카드·투자를 같은 종류의 “보유 자산”처럼 나열하면 구조는 깔끔하지만, 사용자의 행동 목적을 흐릴 수 있습니다. 카드 사용액은 보유 자산이 아니라 지출 또는 미래 부채로 봐야 할 수도 있습니다.
구성 파악에는 좋지만, 사용자가 원하는 것이 “이번 달에 얼마를 쓸 수 있나”라면 계좌·카드·투자 목록은 핵심 질문을 해결하지 못합니다.
프라이버시나 복잡성 측면에서는 유리할 수 있지만, 요약 대시보드의 존재 이유인 빠른 상태 파악을 약화시킬 수 있습니다.
당신의 경우에는 총액 우선과 카테고리 우선의 양자택일보다, 총액의 의미를 먼저 분리하는 것이 선행되어야 합니다.
권장하는 판단 기준은 다음입니다.
순자산, 사용 가능 금액, 투자 평가액을 분리하는 편이 안전할 수 있음즉, 상대 화면에서 옮길 수 있는 핵심은 자산을 한곳에서 파악하게 하는 구조이지, 반드시 총액을 맨 위에 크게 보여주는 시각적 결정은 아닙니다.
화면이 polished해 보여도 다음은 확인할 수 없습니다.
따라서 이 화면에서 얻어야 할 결론은 “총액 우선이 정답”이 아니라, 그 제품이 어떤 질문을 첫 질문으로 간주했는가입니다. 당신의 앱에서는 먼저 사용자의 첫 질문을 전체 규모, 사용 가능 금액, 자산 구성, 이번 달 상태 중 하나로 정한 뒤 위계를 결정하는 편이 맞습니다.
| Design Brief | |
| Work out what a change request actually costs | |
| Decode vague design feedback | |
| Design Handoff Notes - AI First, Human Readable | |
| Write a developer handoff spec |