84 lines
6.6 KiB
Markdown
84 lines
6.6 KiB
Markdown
# 第二题 为一个小麻烦设计 App
|
||
|
||
- **类型**：设计题（必做）
|
||
- **基础要求**：不需要编程基础
|
||
- **提交材料**：一份含草图的 PDF 设计文档
|
||
- **AI 规则**：仅可辅助润色、排版和制图等表达工作；问题与方案由本人构思
|
||
|
||
## 任务背景与概述
|
||
|
||
请选择自己或身边人在学习、校园生活、兴趣活动中遇到的一个小麻烦，为它设计一个手机 App。例如，出门总漏带东西，想看的作品散落在聊天记录里，或社团活动准备时不知道还缺什么。你也可以选择其他问题。
|
||
|
||
本题要让别人看懂：谁会用它、遇到了什么麻烦、App 怎样帮助他，以及从打开到完成任务会发生什么。一个具体、能讲清楚的小想法就足够，不要求编程或前所未有的创意。
|
||
|
||
## 任务详细要求
|
||
|
||
### 1. 场景、目标与功能
|
||
|
||
说明使用者在什么时候想做什么，现在怎样处理、哪里不方便，以及你希望改善哪一步。可以写亲身经历、观察或合理假设；假设请注明，不需要专门访谈，也不要编造调查。
|
||
|
||
用一句话概括 App 的用途，列出首版最重要的 2–3 项功能，并说明各功能怎样帮助使用者。若确实考虑过暂缓某个功能，可选填该功能与原因；没有则不必写。
|
||
|
||
### 2. 能看懂操作的草图
|
||
|
||
画出完成核心任务需要的页面或状态，建议 2–4 幅。标出主要信息、可操作的位置，以及操作后会有什么变化。只有一个页面时，也可以画出操作前后的不同状态。
|
||
|
||
可以手绘后拍照或扫描，也可以用 Figma、绘图、幻灯片或文档工具制作。最终 PDF 必须包含清晰可读的图，不能只放文字描述或外部链接。页面数量和精美程度不是考察重点。
|
||
|
||
### 3. 使用过程与不顺利的情况
|
||
|
||
用一个具体例子串起“打开 App → 操作 → 看到反馈 → 完成事情”，尽量与草图编号对应，让别人能顺着说明走一遍。
|
||
|
||
再选一种不顺利的情况，例如输入为空、操作错了、没有结果、取消操作或再次打开 App。说明用户会看到什么、接下来能怎样继续。
|
||
|
||
### 4. 待验证问题与设计取舍
|
||
|
||
写出目前最不确定的一点，以及准备怎样了解这个设计是否有帮助。尚未进行的验证写成计划即可。
|
||
|
||
如果设计过程中确实比较过不同做法，可以选填一处选择及理由；没有则不必为了填写而凑出另一种方案。
|
||
|
||
请按[App 设计说明书（简版模板）](../templates/design-document.md)组织文档：问题背景 → 设计目标与使用对象 → 方案与功能范围 → 界面与操作流程 → 待验证问题与设计取舍（取舍选填）→ AI 使用说明。建议全文 3–4 页（含草图），页数只是控制工作量的参考。
|
||
|
||
## 提交材料、方式与格式规范
|
||
|
||
### 提交材料与格式
|
||
|
||
| 材料 | 格式与要求 |
|
||
| --- | --- |
|
||
| 设计文档 | `design.pdf` 一份，包含简短方案、清晰草图、正常操作示例、一种不顺利的情况、待验证问题及 AI 使用说明；设计取舍选填 |
|
||
|
||
正文用自己的话说明即可，不要求产品设计术语。无需提交源码、数据库设计、技术选型、架构图、文档编辑源文件或单独的草图链接。导出 PDF 后请检查文字、图和编号是否清楚，草图与操作示例是否一致。
|
||
|
||
### 提交方式
|
||
|
||
第一题与第二题一起放在 `submissions/年级姓名/`，本题文件放在 `02-design/design.pdf`。在本仓库的个人分支提交，再发起指向 `main` 的 PR，由干部审核合并。目录示例与步骤见[前两题提交说明](../submissions/README.md)。正式开放时间和截止时刻以[仓库首页](../README.md)通知为准。
|
||
|
||
## 学习范围与资源
|
||
|
||
了解“具体问题 → 核心功能 → 操作过程 → 界面反馈 → 简单草图”即可，不需要先学编程或完成一整套专业设计课程。可以按自己卡住的环节选读这些资料：
|
||
|
||
- **找场景**：[NN/g：如何写真实的任务场景](https://www.nngroup.com/articles/task-scenarios-usability-testing/)。留意“谁在什么情况下想完成什么”，把功能清单放回实际生活场景。
|
||
- **理顺操作**：[NN/g：用户旅程与用户流程](https://www.nngroup.com/articles/user-journeys-vs-user-flows/)。本题主要看文中较短的“用户流程”：一次具体任务里的操作与反馈，不需要制作正式流程图。
|
||
- **画草图**：[NN/g：即使不会画画也能画线框图](https://www.nngroup.com/articles/draw-wireframe-even-if-you-cant-draw/)。重点看怎样用简单形状表达页面、信息与操作；不需要做精细视觉稿。
|
||
- **想反馈**：[Apple 人机界面指南：反馈](https://developer.apple.com/design/human-interface-guidelines/feedback)。参考操作成功、失败或需要改正时，界面怎样让人知道发生了什么。
|
||
|
||
这些资料是英文参考，可使用浏览器翻译；只需阅读与自己题目有关的部分，也可以观察熟悉的 App 怎样引导操作、处理空白和错误。工具不限，手绘同样可以完成本题。
|
||
|
||
## 独立完成规则
|
||
|
||
问题选择、目标、功能、页面内容、布局和操作流程由本人思考。AI 仅可辅助润色本人已有文字、调整格式与排版，或根据本人已经确定的设计绘制、整理草图；不能代为提出问题、补全方案或决定交互。
|
||
|
||
PDF 末尾附一小段 AI 使用说明：用了哪些工具、它们具体完成了什么、自己完成了什么；未使用写“未使用”。无需完整聊天记录、逐次使用清单或专门举例论证。这段说明帮助我们了解大家的工作过程和 AI 工具使用情况，作为后续教学的采样参考，**不参与评分**。请如实填写，不必因担心考核结果而把 AI 完成的工作说成自己完成的。
|
||
|
||
## 考察重点
|
||
|
||
完成后，可以用下面的问题检查自己的方案是否讲得通：
|
||
|
||
- **问题与目标**：谁在什么情境下遇到困难？你的 App 改善的是哪一步？
|
||
- **功能与范围**：首版 2–3 项功能各有什么用？删去其中一项会怎样？
|
||
- **草图与流程**：别人能否从图上找到操作入口，按示例走到结果？操作后有什么反馈？
|
||
- **不顺利的情况**：发生空白、错误或取消时，用户知道发生了什么、接下来怎样做吗？
|
||
- **理解与验证**：你最不确定什么，准备怎样了解设计是否有帮助？
|
||
|
||
二面会结合 PDF 讨论你的具体方案。设计取舍选填，AI 使用说明不评分；我们主要看问题是否具体、功能和操作过程是否清楚，以及你是否理解自己的设计。漂亮排版和篇幅不能代替这些内容。
|