《设计之下》书摘与笔记
设计之下：搜狐新闻客户端的用户体验设计 From：搜狐新闻客户端UED团队
前言
PIV 用户体验设计：提供用户一种适合的引导路径，以便轻松、愉悦、高效的解决问题。通过宜家的用户路线、卖场场景举例，引申到产品的路径和产品的场景化和流量再次分发。
- 产品路径对应了用户的浏览路径，及用户的操作流程，如何进行引导确实是一个用户体验的设计；
- 如何引导用户：细分用户？Where am I ？Who am I ？What can I do？How to do it ？
- 引申：核心需求得到核心功能模块，细化用户路径，梳理Feature；功能点的载体是用户路径。
交互设计
P3 交互设计师在各过程中的角色和任务
(http://okea5d3bd.bkt.clouddn.com/%E4%BA%A4%E4%BA%92%E8%AE%BE%E8%AE%A1%E5%B8%88%E5%9C%A8%E5%90%84%E4%B8%AA%E9%98%B6%E6%AE%B5%E7%9A%84%E8%A7%92%E8%89%B2.png)
- 调研与立项阶段：参与产品经理主导的产品设计中，对Idea和产品文档提出观点；解析需求，将功能点整合成环环相扣的信息架构图；将用户需求演变成操作流程；确立产品需求文档。
- 设计与开发阶段：完成原型设计和交互文档；与视觉设计师讨论并分析交互文档，与技术成员讨论实现方式，进行细节调整，验证实现效果并反馈。
- 测试与发布阶段：与视觉设计师、技术成员沟通bug，与测试部门沟通交互上的bug。
- 发布与推广阶段：向市场（渠道/运营等）提供交互相关的推广和汇报文件，接受来自对方的推广和汇报相关的需求。
- 搜狐这样的大公司与创业公司不同，产品生产部门更加细分，上游到下游的关系是：产品经理—交互设计师—技术/视觉—测试—市场/渠道/运营等。
- 在搜狐中，产品经理的职责更加上游，分别为：
- 调研与立项阶段：调研市场—调研用户—分析用户需求—得出初步产品需求文档——与交互设计讨论得出产品原型和完整产品文档。（之后充当项目经理的角色）
- 设计与开发阶段：把控整体进度，对各方产品的问题作出决断。
- 测试与发布：充当项目经理的角色，把控质量、协调时间，进行取舍、规划版本，确保准时上线。
- 发布与推广：规划版本？研究产品数据？收集用户反馈，凝练需求？准备迭代项目？（从P7可知数据等是由数据挖掘工程师和用户研究工程师来完成的）
- 可以得知，在搜狐中，产品经理的两个大角色：产品战略层和范围层的把控+项目管理；这也意味着其产品经理更加注重对市场分析、用户研究、产品定位、需求与功能规划。
项目启动
P5 在产品需求文档确定，明晰其中详细的功能点之后，则开启项目启动会。
- 在需求阶段肯定有很多想法被放弃。
- 项目启动会不等于产品启动会：产品是一个不断研究和创新的生命周期，而项目是产品不断迭代中的一个个事件；且需求是有时限的，需要通过项目来敏捷开发。
- 项目启动会：产品经理组建团队，制定合理的项目甘特图；启动会上产品经理向「交互、视觉、前端、服务端、测试负责」、「内容运营专员、市场与渠道专员、品牌推广设计师」、「数据挖掘工程师、用户研究工程师」讲解产品需求文档的功能细节和预期实现效果；确定人员配备、时间节点、协同方式。
- 从上可知，本书为交互设计师的角度，内容从得到产品需求文档开始，跳过了产品经理的市场分析、用户研究、需求分析、产品定位、features梳理。
- 本书以搜狐为例，产品经理仅得出初步的产品需求文档（仅需求list和功能list），后经交互设计师细化，得出产品的功能系统和信息框架，画出框架图、流程图和原型。
- 然后，存在公司的职能部分划分不同、想通职位负责职能不同，对于商业模式、用户研究、需求分析、原型设计、产品文档、交互设计乃至视觉设计可能由不同职员负责或某些职业负责其中几项；这衍生了产品经理、UE设计师、交互设计师、UI设计师等，而彼此之间的职能可能又存在这重合。
- 由上同理，项目的发起者可能是产品经理，可能是UE、设计师等，在产品由技术驱动的公司可能还由技术人员来主导和发起。
解析需求
P14 设计师从产品经理承接产品需求文档，先需要梳理和归纳需求，从交互模型入手，进而得出产品的功能系统和信息架构，此时在绘制原型。
- 从用户体验5要素来看，搜狐中产品经理承担战略层、范围层的工作，交互设计承接结构层、框架层的工作。
- 读得后文，交互设计承接需求，而非发现需求；那么对于用户研究、需求分析、场景设计是不是和产品经理的工作重复，甚至中间可能存在曲解的情况。
- 由此可见，产品经理更重要的能力在于需求的发现和功能框架的规划。
交互设计的“五要素”
P14 以动作为例展开：
(http://okea5d3bd.bkt.clouddn.com/%E4%BA%A4%E4%BA%92%E8%AE%BE%E8%AE%A1%E7%9A%84%E4%BA%94%E8%A6%81%E7%B4%A0.png) 用什么样的策略去做、动机是什么、流程是什么样的都值得进一步细化研究。具体到动作的一个元素流程也可以继续细分。
- 人当然对应用户，人可能按照角色划分，可以按照新老用户、不同频次用户划分。
- 目的：这反而在过程中容易忽视的部分，同时目的也可以是实现用户需求、实现功能的目的，也可以是产品所希望达成的预期效果（如形成闭环）。
- 工具则设计不同平台和不同规格设备，涉及到适配和设备操作舒适度。
- 环境：外部风吹雨打环境，设备持握方式。
阅读产品文档
- 从描述可知搜狐新闻客户端的产品需求文档为纯文字形式；文档仅列举了Feature list，但无关交互体验。
- 产品文档可能随时调整，产品文档要考虑敏捷迭代，规划一个版本应该已经能做到的界线。
- 功能需要考虑所有可能的场景。
交互模型（Interaction Model）
P18 解析需求的三个主要步骤：
(http://okea5d3bd.bkt.clouddn.com/%E8%A7%A3%E5%86%B3%E9%9C%80%E6%B1%82%E7%9A%84%E4%B8%89%E4%B8%AA%E4%B8%BB%E8%A6%81%E6%AD%A5%E9%AA%A4.png) P18 交互设计“五元素”结合搜狐新闻客户端的思考
(http://okea5d3bd.bkt.clouddn.com/%E4%BA%A4%E4%BA%92%E8%AE%BE%E8%AE%A1%E4%BA%94%E8%A6%81%E7%B4%A0%E7%BB%93%E5%90%88%E6%90%9C%E7%8B%90%E6%96%B0%E9%97%BB%E5%AE%A2%E6%88%B7%E7%AB%AF%E7%9A%84%E6%80%9D%E8%80%83.png) 依次分析各元素：
- 用户（人）：
(http://okea5d3bd.bkt.clouddn.com/%E9%98%85%E8%AF%BB%E5%9C%88%E7%9A%84%E7%94%A8%E6%88%B7%E5%85%B3%E7%B3%BB.png)
- 阅读圈（工具）：
(http://okea5d3bd.bkt.clouddn.com/%E9%98%85%E8%AF%BB%E5%9C%88%E7%9A%84%E5%9F%BA%E7%A1%80%E7%BB%84%E6%88%90.png)
- 操作（动作）：结合硬件特性；结合平台和产品设计规范；全局设计。
- 目的：是否满足用户的目的，过程是不是复合用户的期待；是否达到目的的预期效果。
- 环境：终端的因素；外在的因素。 阅读圈的交互模型：
(http://okea5d3bd.bkt.clouddn.com/%E9%98%85%E8%AF%BB%E5%9C%88%E7%9A%84%E4%BA%A4%E4%BA%92%E6%A8%A1%E5%9E%8B.png)
- 交互模型，某种程度上是产品的流程图，各个不同流程环节的整合体。
- 从交互层面上来思考，即使交互模型完整，也并不一定是好的产品。
- 上条原因如下：交互流程贴合功能需求，但是并非用户核心（潜在）需求，无法形成用户忠诚度和粘性；即使实现了功能，功能的可用性又是另一个问题，有、好用、用户乐于去使用之间差了十万八千里。
- 流程和功能，需要去反思和验证；是否真正实现，且它是如何实现的，易用性如何。
- 交互模型有什么用：了解用户实现目的的流程，从而辅助功能系统的构建。
功能系统
P23 “以用户为中心”，从行为出发，围绕交互设计的五要素研究功能系统。 从“用户”交互要素考虑，若想保持用户对阅读圈的粘性需要提高好友的数量和质量；于是衍生到了如何获取更多好友：新闻评论中相识、通过社交网站导入关系、系统推荐、朋友的朋友。
(http://okea5d3bd.bkt.clouddn.com/%E9%98%85%E8%AF%BB%E5%9C%88%E7%9A%84%E5%8A%9F%E8%83%BD%E7%B3%BB%E7%BB%9F.png)
- 增加好友的功能确实没想到，至少是推荐好友的功能，这条路保证了质量。
- 不过，其中提及从评论中相识，则路径比较复杂，所以不如造一个评论的广场？（想看的是评论还是文章内容？）
- 感觉对数量进行了一定保证，但是某种程度忽视了质量，并没有什么功能能对质量做到保证；阅读圈质量的保证：自己发高质量的，好友发高质量的，如何保证？
- 除增加好友外，分享的功能同样重要；增加好友是保证了量的前提，但分享保证了阅读圈的内容量和质。
信息架构
P26
- 信息架构的主体对象是信息，通过设计结构、决定组织方式及归类，以达到让使用者容易寻找与管理的目的。
- “搭建合理的架构，让信息顺畅地流通”，信息的流通可以体现在用户完成一个任务所经历的步骤，是否和他的预期想通，所以需要以用户为中心。
- 信息架构的资料涉及到每一种导航方式的解读、搜索的算法、页面排版等，涉及用户体验设计、前端、后台等多个行业。
- 信息架构需要从产品策略和延展性的角度考虑。
信息架构来源于技术术语，所以有些地方也提到了数据架构，涉及到数据库中所需要构建的数据，需要与技术协商，因此信息构建不仅是导航与组织，也是搜索、前端和后台。
信息架构的重点是梳理信息流动的过程，但是一个好的产品，信息的组织、导航、优先级等等同样重要。
区别于功能系统，个人感觉信息架构更注重组织、导航、优先级等；在「用户体验的5要素」中，感觉更像是结构层和框架层的结合体，在「5要素」中是将信息架构完成，然后再进行导航和信息等设计，在本文中并没有多少展开。
个人认为，信息的组织结构和导航是两个不同的概念，一个是逻辑上的数据，一个实际操作的信息流程。
原型设计
P34 原型仅仅是一个工具，是产品文档的具像化。视觉设计师以此来绘制界面、元素和考虑切图方式；工程师以此来搭建程序；测试以此来给产品的每一个细节把关。
概念设计
Idea的产物，也是Idea的载体。可结合头脑风暴使用。
- 概念模型感觉更应该是在一切的起点的东西；无论是功能更新还是产品创造，都是在交互流程和功能构建之前的东西。
- 概念模型适合做头脑风暴，但是也不适合做头脑风暴；头脑风暴还是更适合思维导图，在其中概念模型起到一个规范的作用。
低保真原型
- 低保真原型：不仅是框架图，更是流程图。
- 包含：每一个界面的布局，以及解释该布局的文案；每一个控件的操作方式，链接到下一界面的流程；不同情况下，界面发生的局部变化（如弹出框或提示语，以及无网络状态等特殊情况的处理；在低保真原型完成评审通过后补充完成）。
(http://okea5d3bd.bkt.clouddn.com/%E9%98%85%E8%AF%BB%E5%9C%88%E7%9A%84%E4%BA%A4%E4%BA%92%E6%96%87%E6%A1%A3%EF%BC%88%E9%83%A8%E5%88%86%EF%BC%89.png)
- 对于信息的组织在信息架构中并未详尽，导致在原型设计的时候增添了一些元素。
- 原型绘制的前提，是功能结构模块完善、信息架构详细；所以原型绘制的重点是架构与设计，是功能组织、信息导航、界面元素设计与排序。
- 原型绘制导航中的信息设计和信息架构中的信息设计不同，信息架构中的是内容逻辑的，而导航中的是体验行为逻辑的，一个服务于内在的组织分类，一个服务与外在的体验和行为流程。
- 原型设计的体现在于功能性和目的性，达到用户的预期，达到促进用户行为的产品预期；这需要验证产品的安全性和可用性。
- 原型设计是整个产品或模块的设计，不仅是主界面，还包含Push通知、弹出、提示、字符限制等情况的处理。
- 绘制低保真原型：流程的引导>框架界面的功能操作的规划和设计>信息元素的重要级、优先级的排序>信息元素的归纳组织、亲密度、对比、对齐、重复等>信息元素的媒体展现形式及界面排序>各元素的特殊情况处理（如数据为null、数据量过多、等情况的设计处理或用户提示）>用户体验操作（容错）验证
- 制作低保证原型的可能目的：让产品经理和交互设计师梳理思路，明确需求并确认设计方案；提供给用户测试，验证产品需求和产品设计是否合理；提供给交互或视觉设计师，进行讲解和功能等参考，供其进行UI制作、交互设计和切图；供工程师理解产品和功能点，评估开发周期，便于沟通和任务对接？？？
高保真原型-交互、视觉文档初稿
- 低保真原型明确了需求和设计方案之后，则开始交互文档。交互文档几乎包含所有的画面的线框图和说明，在比例和布局上也非常接近真实比例。
交互文档面面观
- 减少颜色使用，避免造成额外的认知负担；
- 文档信息等（标题、版本号、各环节的直接负责人、更新记录和日期等）；文档目录；页面、图片命名。
- 尽量包含所有功能和任务的相关画面，包括无内容和失败时的特殊画面（导航、标题、按钮、文案、图标等）；比例与实际比例接近；具体对象、交互细节、跳转都需要用简明扼要的文字和指向、跳转箭头辅助说明。
- 字号、字体、颜色、箭头、箭头样式；不同类型对象的说明文字位置；箭头样式、不同功能箭头的样式等：规范进行区分和统一。
(http://okea5d3bd.bkt.clouddn.com/%E8%AF%B4%E6%98%8E%E6%96%87%E5%AD%97%E4%BD%8D%E7%BD%AE%E7%BB%9F%E4%B8%80.png)
- 此节大致讲的是文档的规范化问题，但也涉及原型的注释问题，内容是交互文档的范畴了，虽然某种程度上的产品文档也可能涉及如此细节的注释和讲解。
- 所以，对于原型设计，应当制定自己独有的一套规范的模版，和实际尺寸和比例接近；依据Android和iOS的规范。
- 相对应的，注释也应当建立注释的一套说明模版。
- 文档的亿读性
布局、位置、层次
- 页面承载的内容布局：增添还是删减，做到功能和内容的克制；思考图片或文字的媒介选择与媒体样式；合理摆放。
- 位置：引导用户按照你的期望去使用产品，将重点和优先级放置在显眼位置，将关联内容进行亲密度处理。
- 层次：突出轻重。
大体来说，除了元素与功能的克制与简洁，其他使用设计的四个基本原则（对比、对齐、重复、亲密度）进行处理。
交互文档的目的与评审
- 视觉设计和程序开发的交付物；将需求具体化，易于理解，可以展现出来从而引入其他部门的反馈与更多的想法；
- 帮助理清思路，对怎么做和如何做有更系统、大局观、未来迭代兼容的认识；
- 对多种方案画不同线框原型图，以供评审从不同职能的角度展开对方案的评判、解读和选择。
选择合适的工具
- 工具要求：可同步、在线协同、版本管理、丰富且可自定义的组件库、兼容多平台终端使用或效果展示、再带网格系统、可生成流程图。
- 产品设计的不同阶段使用不同的工具，不应当将时间花在工具的学习和使用上，应该力求高效率、高效益。（无论是白板、ppt、word、Axure等）
- 交互文档方面，应该有统一的规范，无论是文档的规范，还是原型的控件库。
(http://okea5d3bd.bkt.clouddn.com/%E6%90%9C%E7%8B%90%E6%96%B0%E9%97%BB%E5%AE%A2%E6%88%B7%E7%AB%AF%E4%BA%A4%E4%BA%92%E6%96%87%E6%A1%A3%E5%BE%AE%E7%BC%A9%E5%9B%BE.png)
工具看团队的大小和习惯，能够高效率地进行团队的信息共享、沟通、协作等才是最适合的。规范同理。职能分工同理，不同交付产物也要更具团队的对内容覆盖范畴和细节量进行处理。
本文涉及其他书目：
- 《Android设计规范》
- 《Web信息架构》（倾向于理论和策略，分门别类地介绍了信息架构的基本原理和设计方法）
- 《锦绣蓝图》（倾向于实践和设计，有丰富的案例，适合执行者学习）
评论
发表评论