结对作业第一次——原型设计

[222200332康思梦]

这个作业属于哪个课程	24秋-软件工程&实践-W班
这个作业要求在哪里	结对作业第一次——原型设计
结对学号	222200313 222200332
这个作业的目标	完成巴黎奥运会查询平台原型设计
其他参考文献	Figma教程

目录

• 1. 原型设计地址
• 2. NCBAD模型的详细说明
• 2.1 N（Need，需求）
• 2.2 A（Approach，做法）
• 2.3 B（Benefit，好处）
• 2.4 C（Competitors，竞争）
• 2.5 D（Delivery，推广；Data。数据）
• 3. 模型设计
• 3.1 原型设计工具
• 3.2 设计过程
• 3.3 设计成果
• 3.3.1 首页
• 3.3.2 奖牌榜
• 3.3.3 每日赛程
• 3.3.4 详细赛况
• 3.3.5 对阵表
• 4. 遇到的困难以及解决方案
• 4.1 原型的界面布局和交互
• 4.2 轮播图的制作
• 4.3 每日赛程中支持通过切换日期查看不同的赛程
• 4.4 对阵表中鼠标移动到某一场比赛显示黑色边框提示
• 4.5 比赛详情图中，鼠标悬停在小图标上，显示该图标所在时间点的比赛信息
• 5. 效能分析和PSP表格
• 5.1 PSP表格
• 5.2 效能分析
• 6. 结对总结
• 6.1 分工
• 6.2 结对照片
• 6.3 结对感受
• 6.4 结对评价

1. 原型设计地址

313、332的原型设计

2. NCBAD模型的详细说明

2.1 N（Need，需求）

用户希望能通过一个可视化平台了解巴黎奥运会的详细信息，具体需求有：

• 奖牌榜排名：
  • 展示所有国家的奖牌排名；
• 每日赛程：
  • 展示每一天的赛事，显示比赛类型(足球、七人制橄榄球、手球等)，比赛时间，比赛项目，参赛国家和比赛比分，且获胜国家加粗显示
  • 支持通过切换日期查看不同的赛程
  • 支持点击查看详细赛况
• 详细赛况（设置足球比赛即可）：
  • 展示比赛的成绩，包含本场比赛参赛国家，初赛名单和比赛详情等
• 对阵表（设置足球比赛即可）：
  • 鼠标移动到某一场比赛需要高亮或显示边框提示

2.2 A（Approach，做法）

功能实现：

• 首页：展示奥运会相关图片，提供“奖牌榜”、“每日赛程”等页面的入口。
• 奖牌榜：展示各个国家的金、银、铜牌数量，并按照奖牌总数排名。
• 每日赛程：提供巴黎奥运会期间每天的赛事安排，支持用户通过日历选择查看不同日期的比赛，并提供“详细赛况”和“对阵表”的入口。
• 详细赛况：展示比赛的成绩，包含本场比赛参赛国家，出赛名单、比赛详情、团队数据和运动员数据。
• 对阵表： 提供赛事的对阵信息，帮助观众了解比赛的安排和参赛队伍。

2.3 B（Benefit，好处）

• 专注于巴黎奥运会：我们的设计专注于巴黎奥运会，可以提供更加专业、详细的内容。
• 直观和简洁的界面设计：易于导航和操作，用户能够快速找到所需的信息，减少使用复杂性的困扰。

2.4 C（Competitors，竞争）

竞争者：

• 官方奥运会网站（olympic.rog），能够踢狗详尽的奥运会信息，包括历史、运动员、赛事安排等。官方内容更新频繁，是权威的信息来源。
• 巴黎奥运会官方网站（paris2024.org），专门为巴黎奥运会设计，包含详细的赛事安排、票务信息、志愿者招募等。作为主办城市的官网，信息非常详细。
• 各个运动员或国家队的官方网站，这些网站通常提供有关运动员的详细信息、赛季安排、训练日志等。
• 社交媒体平台（Twitter、Instagram、Facebook），运动员、球队和赛事组织会在这些平台上发布实时更新和互动内容。
• 体育新闻和信息聚合平台（Bleacher Report、The Athletic），聚合各种体育信息，提供分析和评论。

我方优势：

• 创新和灵活性：大学生拥有更多的创意和灵活性，可以尝试不同的设计和功能，而不受制于现有大型平台的传统模式。
• 用户体验（UX）的优化：作为年轻的大学生，我们可以更贴近目标用户群体的需求，特别是年轻观众和学生。

我方劣势：

• 经验不足：团队成员可能缺乏实际项目经验，特别是在大规模网站开发和管理方面。
• 技术限制：缺乏先进的技术支持或面临技术实施的挑战。
• 缺乏市场影响力和品牌认知：作为新兴团队，在用户中缺乏知名度和信任度。
• 开发周期紧张：大学生团队通常有学业负担，没有足够的时间来专注于项目开发。

2.5 D（Delivery，推广；Data。数据）

通过社交媒体和校园网络进行宣传，增加平台的曝光率和用户参与度。

3. 模型设计

3.1 原型设计工具

我们采用Figma进行原型设计。

3.2 设计过程

首页：展示奥运会相关图片，提供“奖牌榜”、“每日赛程”等页面的入口。
奖牌榜：展示各个国家的金、银、铜牌数量，并按照奖牌总数排名。
每日赛程：提供巴黎奥运会期间每天的赛事安排，支持用户通过日历选择查看不同日期的比赛，并提供“详细赛况”和“对阵表”的入口。
详细赛况：展示比赛的成绩，包含本场比赛参赛国家，出赛名单、比赛详情、团队数据和运动员数据。
对阵表： 提供赛事的对阵信息，帮助观众了解比赛的安排和参赛队伍。

3.3 设计成果

3.3.1 首页

展示基本内容，“奖牌”和“结果”提供奖牌榜和每日赛程的入口，其中，奖牌榜还可通过主页的奖牌界面的“全部”按钮进入。

3.3.2 奖牌榜

为了节省工作量，仅展示部分国家的奖牌排名。

3.3.3 每日赛程

点击日期，可唤出日历。选择日历内的日期，可切换至对应日期的赛程，不可选择的日期以灰色样式显示（为了减轻工作量，只做了 7.24 与 7.31的按钮 ）

3.3.4 详细赛况

点击该按钮，进入该场比赛的具体赛况。展示本场比赛的参赛国家、出赛名单、比赛详情等内容。

其中，比赛详情中，当鼠标悬停在比赛时间段的图标上，可显示该时间点的比赛详情。
上下半场以及半场比赛结束的内容可点开详细查看。

3.3.5 对阵表

参考了官方的对阵表，当鼠标悬停至某国家时，该国家所处位置均会显示黑框提示。

4. 遇到的困难以及解决方案

4.1 原型的界面布局和交互

困难描述：因为第一次接触原型设计，我们对于原型的界面布局和交互都没有太多思路。
解决尝试：参考官方网站的设计，学习他们的设计思路。
是否解决：是。
有何收获：了解了体育赛事网页的原型设计。

4.2 轮播图的制作

困难描述：在首页使用轮播图展示图片，但我们都不会制作轮播图。
解决尝试：在网上寻找对应教程，边学边做。一开始对于交互功能并不熟悉，制作时交互功能选成了溶解，导致图片无法滚动出现，后来通过多次尝试发现问题所在。然后在连接交互功能时最后没有连接最后一张图片和第一张图片的交互，导致图片滚动到最后一张就停止滚动，最后通过再次观看教程解决。
是否解决： 是。
有何收获：学会了轮播图的制作，对于Figma的使用更加熟练，对组建和交互功能的理解更加深刻。

4.3 每日赛程中支持通过切换日期查看不同的赛程

困难描述：需要设置日期按钮展开日历选择日期跳转页面，一开始理不清思路，觉得很复杂，需要做的组件非常复杂。
解决尝试：最后尝试使用比较简单粗暴的办法，每一次点击就跳转一个页面，比如点击日期按钮就会跳转到日历展开的那个完整的页面，再次点击则回跳转回来。
是否解决：是。
有何收获：虽然比较简单粗暴，但至少最后效果是一样的。

4.4 对阵表中鼠标移动到某一场比赛显示黑色边框提示

困难描述：鼠标移动到某一场比赛的某个国家，无法使对阵表中该国家所在的所有位置用黑色边框提示。
解决尝试：最开始将每个国家的黑色边框提示放在单独的desktop中，交互选择导航到页面，虽然可以让该国家所在的所有位置都有黑色边框提示，但会导致页面闪动。后发现是因为两张交互页面的显示位置不同导致的闪动，因此放弃将黑色边框提示放在desktop中。而是将每个国家的黑色边框提示放在单独的frame中，交互选择打开叠加，手动调整叠加位置，解决了上述问题。
是否解决：是。
有何收获：学会了更加复杂的展示功能，并且对Figma的交互功能更加熟练。

4.5 比赛详情图中，鼠标悬停在小图标上，显示该图标所在时间点的比赛信息

困难描述：在每日赛程的 比赛详情图中，鼠标悬停在小图标上，显示该图标所在时间点的比赛信息
解决尝试：在网上寻找对应教程，边学边做。顺便学习了按钮的四种变化制作。其实也是换汤不换药，原理都是一样的。
是否解决：是。
有何收获：一开始接触到这个功能的设计认为很难，但其实上手了就发现这其实只是一个简单的交互功能。学会了该功能的制作，并且对Figma的交互功能更加熟练。

5. 效能分析和PSP表格

5.1 PSP表格

PSP	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning	计划	30	30
• Estimate	• 估计这个任务需要多少时间	30	30
Development	开发	660	720
• Analysis	• 需求分析（包括学习新技术）	120	120
• Design Spec	• 生成设计文档	30	30
• Design Review	• 设计复审	40	30
• Coding Standard	• 代码规范 (为目前的开发制定合适的规范)	20	30
• Design	• 具体设计	600	720
• Coding	• 具体编码	120	150
• Code Review	• 代码复审	30	60
• Test	• 测试（自我测试，修改代码，提交修改）	180	200
Reporting	报告	60	90
• Test Repor	• 测试报告	30	40
• Size Measurement	• 计算工作量	10	15
• Postmortem & Process Improvement Plan	• 事后总结, 并提出过程改进计划	10	10
	合计	1210	1430

5.2 效能分析

通过PSP表格可以看出我们在设计和开发这两块中预估耗时与实际耗时相差较大。设计方面是因为我们在作业开始时对于作业完成优秀度要求较高，希望做出一个非常完美的原型，这就导致在实际设计时耗费比较多时间。开发方面是因为我们在设计各种交互效果时遇到了很多比较麻烦的设计，一个看似简单的交互效果不仅需要我们先去学习其背后的技术，还要不断地修改测试才能做出来，所以我们实际耗时高于预估耗时较多。可以看出我们在开发中耗费大量时间的就是对于新技术的学习，这体现了我们对于原型工具的不熟练，我们后续应当多实战原型设计，这样就不用在开发时再去学习很多新知识。

6. 结对总结

6.1 分工

222200313杨祝竹（60%）：负责所有页面的设计、部分功能的实现、以及撰写博客。
222200332康思梦（40%）：负责部分功能的实现以及撰写博客。

6.2 结对照片

6.3 结对感受

222200313杨祝竹：我原先有做UI设计的经验，包括原型工具的选择也是我推荐的，所以我们的合作路线很快就变得变得清晰起来。这是一次比较愉快的合作，一个团队的有效运作非常需要成员之间的及时反馈、互相协调，好在这方面我们都做得不错。当然过程中不免会有点小问题，比如作为全局规划者需要对成员间的分工、进度有比较好的把握，过程中如果出现了偏差需要不断及时调整，会一定程度降低效率，在这些过程中我不断学习和总结经验，让我能做出更好的决策和规划，丰富我的团队经验。
222200332康思梦：这次原型设计结对经历让我得到了很多锻炼，我学会了很多Figma的功能操作，能够设计出以前只能在网页上看到的功能，这让我感到非常自豪。还深刻体会到了团队协作的力量，一个人的思维会受到个人经验和观点的限制，但两个人合作时，我们可以通过交流和分享不同的观点和经验，克服这些局限性，同时两个人配合完成任务也使效率变高。

6.4 结对评价

313对332评价：拥有一个信任你的队友是非常幸运的，当然也是她对我能力的认可，她会及时和我交流沟通，会主动提出帮助我辅助我完成我还没计划好的部分，不会的操作会先去主动学习然后做出成效，减轻我的负担，是一个非常棒的队友。
332对313评价：在合作期间，杨祝竹同学展现了极高的美术素养，她设计出的原型非常的精美。在团队协作中，积极与我沟通，分配任务，我们的工作有条不紊的进行，最终完美结束。我非常期待和她下一次的合作！

[助教袁金凡]

学习如何使用工具也很主要，继续加油！