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

这个作业属于哪个课程	2023软工W班
这个作业要求在哪里	结对第一次作业--原型设计
结对学号	222000321, 222000320
这个作业的目标	基本要求，模型设计，结果汇报，效能分析
其他参考文献	《构建之法》

目录

1 原型链接

AO-UI by Figma

进入页面之后点击右上角播放键▶️进行交互式查看。

2 NABCD模型说明

N：需求

在本次项目中，用户被假定需要通过一个平台来直观地浏览2023年澳大利亚网球公开赛（下面简称“澳网”）的各种数据，包括

• 选手积分排行（男单及女单）
• 第1天到第14天每天的赛程及每场比赛的类型、得分和赢家
• 单场比赛每局（Set）每节（Game）的得分情况序列
• 树状晋级图（从第4轮开始至决赛）

由于用户先前是建立在已经使用过基于命令行输入输出的简易版本信息检索软件的基础上提出的需求，因此容易想到，用户可能还具备以下隐性需求：

• 需要简单，方便，稳定运行的平台。
• 需要人性化的交互方法，如通过点击，点选，拖拽等方式来操作界面
• 界面美观，数据可视化，易读性较高
• 需要其他用于辅助澳网信息展示的内容或页面，如澳网简介等

A：做法

基于上述需求，我们规划出以下实施方法来达成项目：

• 使用包括Vue等前端框架在内Web前端技术，使用B/S架构搭建平台
• 使用专业的原型设计工具，通过自动化布局设计、色彩管理和动画设计来构建美观合理的页面设计和交互
• 设计多组件信息融合，充分展示用户所需的信息

除了上述技术方面的做法，为了进一步考虑项目应用的潜在问题，还需要下述非技术类做法：

• 采取快速前端构建方式减少时间成本
• 通过爬取澳网官方数据来降低数据储存成本和维护风险

B：好处

通过本平台，用户能取得下述好处：

• 更加方便地浏览数据。由于是网页端，用户不需要安装软件，只需要浏览器打开网页即可访问
• 更加直观地浏览数据。数据采用图文并茂的形式展示，文字数据简单明了地展示在页面上，用户不会像查看命令行一样困难
• 获取到更多信息。由于增加了其他形式的信息和页面，用户不再只能访问到澳网的最基本的比赛数据，更可以访问到一些扩展的数据，比如澳网的简介，订票信息，选手信息，新闻资讯，比赛回放等
• 更加稳定地访问数据

C：竞争

市面上已经存在着一些能够访问或浏览澳网相关数据的平台，下面分别对各类平台举例进行竞品分析：

• 官网：AO官网。官网是目前市面上能找到的数据最全面，访问量最大，最权威的竞品平台，存在一定优势。但也存在一定缺点，包括：
  • 信息过多，用户无法直接找到想要的数据，比如比赛的详细数据等
  • 过多的推广信息，容易对用户信息的检索带来困扰
  • 海外网站，访问不稳定
• 搜索引擎：Bing和Baidu。搜索引擎能够比较直观地立刻给出用户所需的数据，通过近年来搜素引擎对数据展示技术的优化，已经逐渐成为一般用户搜索网球资讯和比赛信息的主要渠道，存在知名度和易用性优势。但也存在一定缺点，包括：
  • 信息展示不稳定。搜索引擎只能展示常用的数据，比如选手列表，比赛基本情况等。而更多的信息则无法直接获取。
  • 信息来源不明确。搜索引擎的数据来源有时不是官方，即使是官方也可能存在信息滞后问题。
  • 信息融合度低。用户可能需要多次搜索才能获取到全部信息。
• 第三方体育平台：虎扑等。这类平台在一般群体的知名度较高，但由于不是专门的信息平台，而是体育论坛，存在的缺点比较明显：
  • 功能重点偏离：平台的重心可能位于体育交流，如聊天和评论。信息的展示并非其核心模块
  • 信息环境复杂：比赛信息容易被其他信息带偏
  • 掺杂广告

D：推广

要进行商业推广，考虑到本项目本身是体育信息聚合类型的平台，可以有以下的推广方法：

• 向体育类论坛，贴吧等投放广告
• 邀请网球比赛（尤其是澳网）视频作者或短视频博主进行商业合作
• 与国内体育平台进行合作

3 模型设计

3.1 模型设计工具

本项目使用Figma原型或平面图形制作软件构建。

3.2 模型构成

根据用户需求，模型由若干页面已经页面内部的模块组件组成，包括：

• 主页

  • 头部介绍模块
    

    

  • 新闻模块
    

    

    • 新闻速览
    • 视频回放
    • 频道

  • 热点选手
    

    

• 排行榜
  

  

  • 男单积分排行
  • 女单积分排行

• 赛程信息
  

  

  • 头部Days选择器
  • 当前天下所有的赛程以及每场赛事的类别，胜者和比分模块

• 赛程详情
  

  

  • 头部单场比赛的基本信息模块（复用“赛程信息”中的）以及对局双方全名
  • 局（set）选择器
  • 当前局的胜者及当前局比分模块
  • 当前局每节（Game）比分序列模块

• 晋级图
  

  

  • 树状晋级图，从第4轮到决赛

此外，页面都需要一个导航栏来进行跳转，这个模块将位于每个页面的顶部。

3.3 模型要素

为了构建可交互的原型，并尽可能简单高效地构建原型组件，本原型设计使用了Figma中的以下概念要素来构建原型。

3.3.1 框架Frame

框架是一个原型页面的基本单位，可以利用这个概念来构建原型模型的各种实际页面和弹出式页面（组件）。

在本项目中，实现了6个Frame，包括主页、排行榜页面、赛程信息页面、赛程详情页面、晋级图页面以及一个用于局选择器的弹出式页面的Frame。

不同的Frame之间将使用下面的模型构成关系中的交互线来串接形成交互流。

3.3.2 组件Component

组件是相同或不同框架中的小的可复用模块。可以将一些总是重复出现且需要添加相同的动态交互式效果的内容（组）转化为组件。这样，模块就能进行复用和继承了。

在本项目中，使用了几组组件集合，包括

• 导航栏导航按钮，用于跳转点击和hover效果，内含需要在导航栏进行跳转的4个按钮组件
  

  

• 赛程Days切换器，用于提供在用户点击Days按钮之后可以将切换器转变成对应天的状态，共有14个切换器组件
  

  

• 赛程页面单场模块，用于提供用户在hover时可以产生边框变化效果，以及点击之后可以跳转到赛程详情页面
  

  

• 晋级图页面单场模块，用于提供用户可以在hover时可以产生边框变化效果
  

  

3.3.3 变体Variant

变体是建立在组件基础上的，当组件有多个状态且多个状态都需要被实例化，控制为相同的效果时，使用了变体。当为组件建立变体后，不同的变体就得到了统一管理。

上述组件中，切换器，和两个单场模块使用了变体。

3.3.4 实例Instance

实例是组件（变体）应用在具体Frame中的对象，继承了组件或变体的全部属性和关联，而且可以控制专属于本实例的属性，使得其表现于组件（变体）产生差异。然而，对组件的修改将影响到全部实例，在一些需要统一控制样式的情况下可以用到这个概念。

3.4 模型交互

要产生交互式效果，就要为不同的组件或Frame设计交互属性，使其状态或内容进行转变。这种转变可能是变体变换，也可以是Frame的切换。

在本项目中，在下述场景中存在交互关系：

• 导航栏，用户点击下面四个按钮时，跳转到对应Frame（但不含本身）
  • AO logo，跳转到主页
  • 赛程
  • 排名
  • 晋级
• 导航栏，用户鼠标覆盖（hover）下面三个按钮时，产生加深色彩效果（但不含本身）

• 赛程
• 排名
• 晋级
• 赛程页面单场模块，当用户点击每个模块时，跳转到赛程详情页面
• 赛程页面单场模块，当用户鼠标覆盖（hover）每个模块时，对应模块边框线条变蓝变粗

• 赛程Days选择器，当用户点击对应天时，将对应天的Days选择器替换到当前选择器来完成Days跳转效果

• 赛程详情Sets选择器，当用户点击选择器时，弹出下拉菜单
• 赛程详情Sets选择器，当用户点击选择器下拉菜单对应项时，跳转到对应Set的页面（但不含本身）

• 晋级图，当用户鼠标覆盖（hover）每个模块时，对应模块边框线条变蓝变粗

要实现上述交互属性和效果，需要使用原型选项卡的interaction，将触发对象和实现对象用线连起来，并赋予属性，来实现本项目中的需求。

属性包括：

• 触发条件。根据我们的需求选择“点击”或“鼠标覆盖”
• 实现对象位置。在页面跳转时，选择“导向”；在弹窗时，选择“显示在上方”；在变体切换时，选择“转换为”
• 动画。

使用这样的交互线，就形成了一个操作流。如果这个操作流是完备的，用户就能通过点击来体验全部页面及其切换过程。

下面是本项目的全部交互线。

3.5 美术设计

3.5.1 色彩控制

为了配合设计风格，本项目色彩以沉稳内敛简约为主，主色为AO蓝，色标取自AO logo。

在AO蓝的基础上，扩展出深蓝，浅蓝，分别用于导航栏和非明显强调色。

此外辅以不同灰度和透明度的#0色（黑色），构成文字，边框和背景。

色彩模式为sRGB。

下面是参考色标。

3.5.2 字体字形

全部使用默认字体。

根据标题层次分配不同的字形大小

根据在相同位置文字的主次关系设计透明度和灰度。

3.5.3 动画

在导航切换时不使用动画，而是立刻进行切换；

在hover和模块（变体）切换时使用溶解效果，进入时线性变换400ms。

3.5.4 阴影

对于页面仅有导航栏的情况下，在导航栏下方显示4px的外阴影。

对于页面含多级顶栏，也就是既含导航栏，也含功能栏的情况下，在最下面一级的栏下方显示4px的外阴影。

3.5.5 圆角

根据内容粒度的不同，选择从5px-27px不等的圆角。

其中全部Frame（不含弹出类）使用27px的圆角。

3.6 排版设计

3.6.1 垂直滚动

Figma支持默认的垂直页面滚动，在除晋级图的页面上都默认实现了这个效果。

3.6.2 水平滚动

在晋级图中，由于水平方向内容超出了页面范围，需要设计成可水平滚动的形式。

在晋级图页面Frame中，单独为晋级图主体设计一个Frame，将其大小调整为刚好与页面的宽度重合的状态，于是内容就可以在这个Frame中水平滚动。

为了同时支持内容的垂直滚动，必须将垂直滚动手动加在这个Frame上，而不能使用页面默认的滚动。于是直接将滚动类型选择为：同时支持水平和垂直滚动即可。

3.6.3 布局

使用手动布局。

3.7 图像图形资源

在本项目中，使用了Figma插件Iconify和HugeIcon Pro中的若干图标。

使用了AO官网的一些位图素材。

3.8 模型生成和效果

在设为标准网页大小1920px*1080px的情况下，使用从主页开始的控制流，生成了我们的模型。

下面是模型全局预览

4 困难及解决方法

4.1 困难描述

在Figma中，如何进行组件不同状态的动态变换，如何设计用户的交互操作是一大难点。在开发原型过程中，这部分内容困扰了我们很久。

在样式替换上，开始时我们没有选择使用变体，而是直接将一个已经经过改变的实例应用到原来的位置上，也就是叠加到原本的组件上方，这样就会有下述问题：

• 在第二次覆盖到上方时，原本在下方的组件并不会因为叠加了新的实例而退出，这样就会使得叠加产生一定的细微位移。在多次点击之后，叠加的位移已经不能接受。
• 在组件叠加时，由于它们本身不是同一个组件，因此因此在覆盖时会认为在组件外部的内容是不可交互的。这样就会导致用户在点击这个内容并产生一个叠加层之后不能直接切换到另外一个页面，而是要通过重新点击外侧来取消这层叠加。这违背了用户逻辑。

在组件设计上，我们开始时没有使用多组件或者说实例化方法，而是只是用成组的方法来控制模块，这就导致在需要修改样式时是必须为每一个模块都进行修改，这样相当繁琐。

在滚动布局上，开始时我们只设计了水平滚动，而没有设置这级的垂直滚动。这样就导致虽然能完成水平滚动，但是一旦滚动到脱离原来位置的水平位置时，垂直滚动不可用，直到再次水平滚动到初始位置才能进行垂直滚动。

4.2 解决尝试以及是否解决

上述三个问题都得到了解决。

在样式替换上，我们学习了变体概念，并将其作用到我们的样式上，不再直接将实例作为新的样式使用，而是先对原始的模块转化为组件，然后扩展出若干的变体，将这些变体成组，这样就可以将变体实例化。而要进行样式转化，只需要对变体之间进行连线即可，其实例全部会遵循变体组件的关系。

同时我们也通过尝试了解到popup可以自定义位置，这解决了Set选择器弹出下拉菜单时，菜单位置位于顶部的问题。

在组件设计上，我们学习了组价、实例和继承，避免直接通过复制组件组的方式来矩阵化我们的模块。由于实例化自带继承效果，我们可以做到修改一处，其他实例都被同时修改的效果。

在滚动布局上，我们通过尝试，为内部内容的Frame同时分配了垂直和水平滚动，解决了初始位置才能进行垂直滚动的问题。

4.3 收获

在本次结对之前，组内成员就已经了解过Figma，其中文稿整理者也使用过Figma来设计应用程序图标。然而，如此全面地设计原型和用户交互，这还是第一次。

设计原型不光是设计界面，还要全面考虑用户的交互逻辑，可能出现的问题，以及使用感受。这种使用专业原型软件来设计原型，而不是直接用前端来设计界面，更加地快速，纯粹，并且在用户交互的方面更加地直观，并且上手成本相对于前端语言来说比较低，全过程都可以通过可视化操作的方式来实现。

此外还进一步考验了我们对用户可能的潜在需求的挖掘能力。

5 结对、分工和评价

5.1 结对概述

在本次结对中，分工如下：

学号	分工
222000321	主页，赛程页，排行页，组件设计，文稿整理
222000320	晋级图，关系连线，页面布局调整

使用QQ、腾讯会议以及Figma在线协同的方式来进行工作配合。

5.2 结对工作过程

• QQ沟通需求
  

  

• 腾讯会议项目复核
  

  

• 讨论
  

  

5.3 评价

• 222000321：这次结对是一次很不错的体验，我们实施了多种沟通协作的方法，来共同完成整个项目，我的队友很好地完成了我们协商的分工部分。他很好，我哭死。
• 222000320：我通过本次作业学习了Figma，了解了原型设计的过程。我的队友完成了原型方面许多页面的设计，质量很好。

5.4 感受

本次结对是第一次结对，相比于6-8人的团队，2人结对在沟通上更加直接，但也带来一些分工上的问题。好在最后通过我们的共同努力，最终完成了任务。

6 效能分析

PSP	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning	计划	20	25
• Estimate	• 估计这个任务需要多少时间	20	25
Development	开发	580	825
• Analysis	• 需求分析	30	50
• Design Spec	• 生成设计方案	30	40
• Tools Learning	• 学习原型工具	60	80
• Design Review	• 设计复审	10	5
• Design	• 具体设计	400	600
• Project Review	• 项目复审	30	30
• Test	• 测试（自我测试，修改代码，提交修改）	20	20
Reporting	报告	150	240
• Design Repor	• 设计报告	120	180
• Size Measurement	• 计算工作量	10	10
• Postmortem & Process Improvement Plan	• 事后总结, 并提出过程改进计划	20	50
	合计	750	1090

在耗时方面，具体设计环节的耗时相较于估计差异较大，主要原因在于学习工具的时间不足，我们认为实际耗时应该达到120分钟，能够对具体设计环节有比较大的帮助。

可能的根本原因是，不同于编程设计，原型设计不是我们先前接触过的方向，因此必须要更多的学习成本。

报告时间也相较于预计有比较大的涨幅，在报告时，不仅需要对原型构成进行介绍，还要介绍原型工具的一些技术，这增加了实际时间。

---

Only Used For SE2023, CSC, FZU.

© Copyright 2020-2023 MarkPolo, all rights reserved.