61 lines
3.8 KiB
Markdown
61 lines
3.8 KiB
Markdown
# 第二题 为一个小麻烦设计 App
|
|
|
|
- **类型**：设计题（必做）
|
|
- **基础要求**：不需要编程基础
|
|
- **提交材料**：一份 PDF 设计文档
|
|
- **AI 规则**：仅可润色本人已有的文字和草图，想法与设计须独立提出
|
|
|
|
## 任务背景
|
|
|
|
请选择自己或身边人在学习、校园生活、兴趣活动中遇到的一个小麻烦，为它设计一个手机 App。
|
|
|
|
题材可以自选。例如：出门总是漏带东西，想看的作品散落在聊天记录里，社团活动准备时不知道还缺什么。这些只用于帮助理解范围，你可以选择完全不同的问题。
|
|
|
|
你的任务是让我们看懂：谁会用它、为什么需要它、怎样操作，以及这样设计的理由。一个有具体用法的小想法就足够，不要求前所未有的创意。
|
|
|
|
## 设计文档应包含什么
|
|
|
|
**1. 一个具体场景与简短方案。**
|
|
|
|
说明使用者在什么时候遇到什么困难，现在通常怎么处理，你的 App 想改善哪一步。亲身经历、观察或合理假设都可以，假设请写明，不需要为本题专门进行正式访谈，也不能编造调查。
|
|
|
|
列出首版最重要的 2–3 项功能。再写一个你决定暂时不做的功能，以及暂缓原因。
|
|
|
|
**2. 能看懂操作的草图。**
|
|
|
|
画出完成核心任务需要的页面或状态，建议 2–4 幅。可以手绘拍照，也可以用任何绘图、幻灯片或文档工具。标出主要信息、可以操作的位置和操作后会发生什么。
|
|
|
|
如果只有一个页面，可以画它在不同操作前后的状态。页面数量和精美程度不作为高分依据。
|
|
|
|
**3. 一次完整使用示例。**
|
|
|
|
用一个具体例子串起“打开 App → 做哪些操作 → 看到哪些反馈 → 完成什么事情”。尽量与草图编号对应，让别人能顺着你的说明走一遍。
|
|
|
|
再补充一种不顺利的情况，例如输入为空、操作错了、没有搜索结果、取消操作或再次打开 App。说明用户会看到什么、接下来能怎么做。
|
|
|
|
**4. 自己的选择与反思。**
|
|
|
|
挑一处设计，说明你为什么这样安排；如果还有一种做法，为什么暂时没选。再说明目前最不确定的一点，以及怎样了解这种设计是否有帮助。
|
|
|
|
可以用[模板提纲](../templates/design-document.md)组织内容，建议 3–4 页，清楚简短即可。页面建议只用于控制工作量，不是硬性扣分标准。
|
|
|
|
## 不需要提交什么
|
|
|
|
不需要源码、数据模型、数据库设计、技术选型、接口文档或架构图，也不要求研究怎样实现。正文用自己的话说明即可，不要求使用产品或设计行业术语。
|
|
|
|
## AI 使用范围
|
|
|
|
想法、功能取舍、操作过程和设计理由必须由你自己提出。
|
|
|
|
AI 只可以润色你已经写好的文字，或整理、美化你已经画出并决定好的草图。不得让 AI 代选问题、构思功能、设计交互或代写思考。如果润色过程中新增了功能或改变了操作，应去掉这些越界内容，按自己的方案表达。
|
|
|
|
在 PDF 最后用几句话说明是否使用 AI，以及用于哪些润色。没有使用就写“未使用”。可以保留自己最初的短笔记或草图，便于二面说明；本题只要求提交一份 PDF，不要求额外上传私人聊天记录。
|
|
|
|
## 提交与评价
|
|
|
|
提交 `design.pdf`，包含简短方案、草图、操作示例、选择理由及 AI 使用说明。
|
|
|
|
我们主要看问题是否具体、功能是否服务这个问题、使用过程能否讲通、是否考虑反馈和不顺利的情况，以及设计理由是否来自自己的思考。漂亮排版和写作长度不能代替这些内容。
|
|
|
|
二面会围绕你的方案追问。例如：为什么把这个操作放在这里；如果用户取消了怎么办；只保留一个功能时你会留下什么。允许坦诚指出还没想清楚的地方，不要求背诵文档。
|