产品设计交付物件.docx

产品设计交付物件.docx

《产品设计交付物件.docx》由会员分享，可在线阅读，更多相关《产品设计交付物件.docx（11页珍藏版）》请在冰豆网上搜索。

产品设计交付物件

产品设计交付件之一：

概念模型

明确产品的概念模型:

这里说的概念模型不同于我们通常理解上的“产品的概念”，我们认为用节点、连线来完整勾画出一个产品的体系架构可以叫做这个产品的概念模型。

而提出这样一个“概念模型”出发点也就是要通过它来明确整个项目组中对于产品完整的想法和规划，从而作为设计的基础。

这里包含的内容可以相当宽泛：

所以概念模型对于一线的项目设计人员可以起到很好的指导作用，帮助他们理解整个项目过程中产品的基调和要求，不会在后期的设计中误入歧途。

另外，对于管理者而言也能在宏观上起到很好的监督和制约，在达成对产品一致理解的基础上，整个项目的设计和运维都可以非常流畅。

如何创建你的概念模型:

第一层：

建立基础的节点和连线。

一般，节点可以被分为内容类型、人员/实体、数据元素、组/类别、事件、系统和其他一些。

而连线就是用来连接这些节点的，并且连线上可以勾划出不同的动作来丰富节点之间的关系。

第二层：

添加细节

对节点进行修饰：

节点的形状可以有很多表现形式，只要能表现概念任何形状都可以。

例如：

重要的概念可以用更大的节点来表示，以此我们可以奠定全文的基调。

对连线进行修饰：

除了在连线上增加文字，我们也可以通过变化连线的形式来展现概念模型。

当然这具体得看上下文的关系来定了。

第三层：

完善概念模型

确定了节点和连线后，概念模型基本上就可以表达应有的意思了。

如果还想再完善概念模型，剩下的工作就是对概念模型的背景进行修饰。

记住图表的背景应尽量不显眼，这是因为图表本身已经有了很多元素，视觉上的过多变化只会让看图的人分神，所以尽量让背景色淡化不显眼。

使用背景色之前，想一想它是否真的能带给图片有趣的信息。

在概念模型中，背景有助于区分内/外过程。

同时，在读者没有钻入细节前，背景也有助于他们从宏观的层次上确定该图的要点。

概念建模有哪些需要注意的地方：

1.明确建模的目的–让你的项目组成员意识到以下两点，你的建模才会让他们认为是有意义的

（a）由于术语的不一致导致成员之间沟通困难

（b）受绊于一堆错综复杂的概念，必须梳理清楚后才能继续推进项目。

要知道，如果一开始，概念模型只是用来作为把事情讲清楚的工具，那么到了后期它其实就变成了一项有力的工具，让其他人也能接受后继设计，完成这个项目。

如果让自己成为一个建模高手：

1.要有“中心思想”，让你的建模只传递需要传递的信息，删除掉和中心无关的内容。

2.从名词着手，把概念模型中的实体全部列出，然后把它们记录在纸上并用线将它们连起来，你也可以用动词表示出他们的关系。

3.节点标准化，这是又一轮的筛选。

看着你列出来的那些节点，找出无关的，再一次去掉。

方法一：

把模型中的节点限制为几个特定种类，一个文件中包含了流程、文档、事件、人员和系统五种。

那么我们可以将模型限定为只要人员和文档两种节点，同时通过连接来阐述更高层次的节点。

方法二：

找出“局部-整体”之间的连接，有些节点彼此是可以互相替代的，我们可以去掉其中之一；只要这种省略不会影响到你的概念模型即可。

（关于节点增生：

常常会有模型的一侧滋生出一簇节点，它们和其他节点关联不多，必要的话我们可以把它们独立出来建成另外一个概念模型）

4.节约你的连接，和节点的道理一样，并不是连接越多越好。

你很难保证自己的表述不会多次重复表达，通常我们可以从两个方面来考虑：

这些连接是否有利于整体信息的表达是否能增加新信息；反之，去掉这些连接会不会让涉众错过一些信息。

如果答案都是否定的，那我们可以考虑去掉它了。

需要建模，但不要教条化：

1.如果是为了澄清设计背后的假设来做概念模型，常常会发现原先的设计考虑不够充分，而在概念模型中被发现了，这会导致团队陷入无休止的调整中去，一种比较好的办法是暂时将这种差异保留，并标识清楚、说明清楚原因。

3.实用至上。

我们花了很多时间去建立概念模型，结果却发现它毫无价值，这是因为我们在建模之前缺乏足够的调研。

所以在建模工作之前，我们就该思考一下收集到的这些节点、用户的体验等等，这些因素究竟在概念模型中能得到怎样的体现，会否对概念模型带来影响？

如何向你的团队推荐概念模型：

概念模型的意义在于更好地帮助团队理解设计方案，所以向团队推荐概念模型是很有必要的。

不过如果仅仅是放在小团队中来使用，形式上可以随便一些，可以用讲故事的形式来把团队带进概念模型的氛围中，你的故事要以事实为基础，教会他们在这样的氛围中去思考。

会议结构：

1.以解决问题做切入点：

你可以和你的客户这样来解释：

虽然我们已经和公司里许多人都探讨过“政策”和“规章制度”了，不过我们还是不太明白它们是怎样融合到整个过程中的，当然我们希望设计文档中能够适当呈现这些元素，所以我们想把这个概念模型整理一下，借此澄清文档和公司关键人物的关系。

如果对方之间没有接触过概念模型，这样的介绍会受到不错的效果，因为它包含了上下文背景，同时对方也具有对节点关系一定程度上的把握。

2.节点-关系法

如果文档是从某个节点或者一系列节点延伸开来的，那我们就可以以这些节点作为焦点，然后逐渐向外眼神来介绍概念模型，

3.白板法

可以让我们在没有实际的交付件时，把一些节点或者概念写在白板上通过头脑风暴来把所有的关系找到。

你要做的一般只是把一些需要用到的节点事先标注出来。

如果你想把话题引到一个你希望的方向上，你最好能事先准备好一个概念模型。

ps：

概念建模时难免抽象、主观。

为了能保证主题的集中，也避免扼杀大家的创造力，不妨事先把会议目的的声明先写在白板上。

结束语：

产品设计交付件之二：

竞品分析

竞品分析最重要的两个方面要掌握：

a竞品的选择；b评测标准。

竞品分析最常见的格式包括了表格和示意图两种。

而一般来讲，图示的效果会更加直接易懂。

对于竞品分析文档的创建，可以分成三个步骤

第一层

1.框架

在就绪了你的竞品和评测标准这两个关键维度以后就可以开始考虑是用表格、象限图还是套帧小图来展现你的文档了。

2.数据

1）是否类评估：

确定你的主角和其他竞品后，罗列出你的评测标准；然后主角都是√配角大都是×，以此表现主角功能卓越。

这样以来我们可以直观地看到有或缺哪些功能，不过不好直接比较对应标准的各个竞品之间细微的差异。

2）评分法：

对每个竞品进行打分，例如5分制或10分制。

但是困难的是如何把握每个竞品的得分。

3）描述法：

比1）更加常用的一种办法，描述了各类竞品在评测标准下的表现。

4）2×2象限图

5）套帧小图

Tips：

4和5的特点是对比感最强烈。

一般空间设计最常用

1、4和5；功能多少一目了然，例如页面设计。

3在比较功能细节差异，无法直接图示的时候更加有用。

2和3的作用类似。

最后无论用哪种方式，我们都要在解释完毕竞品、数据以后，对情况进行分析，得出一个结论。

需要针对我们的项目给出相应的建议，如果有问题也要进行分析给出解决的方案来。

只有这样才能指出竞品分析的意义，带入更深入的研究。

第二层

1.对比多个项目

很多时候为了能更加深入地对比我们需要再增加一些内容。

例如

按评测标准组织报告：

针对某个具体的标准，给出不同竞品各自的表现。

这就不难理解为什么相同的竞品在不同标准下会有差别很大的表现了。

通过这种方式我们可以认识到具体某个问题上哪个竞品做得最好，不过带来的负面效果就是只能得到零碎的用户体验画面。

按竞品组织报告：

2.目的

竞品分析越深入，竞品缺失或评测标准不足就会表现得越明显。

不过我们只要记住开始竞品分析的目标就可以了！

对方法的选择上最好能做两手准备，因为项目背景的需求可能会有所变化。

第三层添加更多的细节

描述清楚你的分析方法，是让项目组成员更愿意接受这份竞品文档的重要一点，切记！

开展竞品分析的基本要点有哪些：

1.动机

标明分析的动机，项目组成员了解竞品分析的原因后才会体验到这份报告的重要性，才会重视你的这些数据。

因此一开始就要从动机入手。

2.时机

项目早期开始竞品分析，很可能在什么问题和特性是最需要了解的这个问题上不够完善。

因为只有在做过用户研究以后，我们才能知道是什么特性、什么问题是最需要解决的。

跟概念模型一样，竞品分析是我们理解问题的一种工具担不是重头戏。

我们可以通过它了解业界的发展。

到了项目后期，竞品分析主要会体现在具体某一个问题上的指导，为我们提供参照基准。

简单来说：

项目前期的竞品分析更加偏重于战略层的考虑，用来帮助我们发现问题、欠缺的部分；项目后期的竞品分析其实是对具体的问题找思路了。

而事实上我们用的最多的都是后一种。

3.吸引读者

冲突、紧张、决定；这些正是竞品分析吸引观众的东西。

让读者了解你的评测标准，让他们明白为何选择这些竞品同时向他们展现你最终分析后得到的结论。

值得注意的是：

竞品分析作为内部文档，一般不需要太多上下文背景的描述。

4.整理数居前的热身

文章前面已经提到，竞品分析是有很多不同的表现方法。

用什么表现方法决定了我们如何来收集这些数据、收集什么样的数据。

在熟练了以后，表现方法上我们可以有更自由地发挥。

Tips：

1.文档的开头就要说清竞品分析的结论

–有几个要解决的问题，就说明清晰几个结论。

–宏观战略上的问题，最好可以列出其中的关键点、基本的要素，在文档开始就予以说明。

2.竞品分析存在的风险

*可能你花费了不少功夫来整理你的竞品文档并争取在结论里囊括所有得到的信息，但这样以来你会使得自己的结论变成四不像。

所以我们可以先明确结论再开始归档数据，如此就有了结论作为上下文背景的支持，再来呈现数据。

*数据要有意义，有可能你的文档只有结论却没有能支持的数据，方法同上，先确定结论，然后确定支持数据，最后成文。

这两种办法都是方法论的实践。

内容详单

7.资料来源

8.格式

9.访问权限

标示出某内容是需要密码才能访问或者特定权限用户才能访问

10.遵守标准

11.其他内容

第三层：

玩转内容详单

1.“块”层次以上的内容详单

如果说以页面为单位来描述还不足以表现你的内容，那就可以考虑“内容块”这样的单位进行描述了。

2.相关信息

为内容详单制作一个介绍页面，记得包含以下内容。

范围：

定义出内容详单的范围，让读者有所了解

对列的描述

结果的总结：

在创建内容详单后，我们会对其中模板、内容的运用有一些结论，记录下来，它们会对后期项目开始运营产生巨大的影响。

版本信息：

内容详单也会跟着其他文档的变化而发生相应变化，通过规定不同的版本或者通过不同的颜色来区别可以便于日后跟踪项目进程，了解各种变化的依据。

作者信息：

便于日后问责。

在大项目中起步

1.神经xx的必要性

2.决不嫌快

很简单，如果你明确了要做内容详单，那就不要犹豫了，放手去做就好了。

3.关注电子表格的人

4.每次只构建内容详单的一个xx

·将内容和容器区分开—通过字体颜色或者背景颜色区分开具体的内容和栏目/选项。

但要注意不要在表格中使用过多的颜色，免得让自己都眼花缭乱了。

·强调重要的信息—可以用着重号，也可以用不同的颜色加以区分。

·确定问题的优先级—如果该行内容需要强调，使用高对比度的颜色可以达到不错的效果。

将内容详单分成小块

1.不同类别的内容放在不同的区域—通过xls给出的多张表格就可以做到。

设计团队会决定使用什么模板，是否要更改页面的形式；信息架构师会确定每部分内容的目的。

每次站点的清理，都会增加一些对应的信息，明确好每个部门的任务，会帮助你完善这份文档。

3.预先确定分类策略—一种是通过会议讨论出你想要的分类，当然随着项目推进，我们会发现其中的不足，有些分类不合适；另一种是建立内容详单的过程中对内容进行分类。

设计交付件之四：

线框图

和原型图相比，线框图由于在交互方面缺乏有效的表述，这使得它渐渐被很多产品人员所抛弃，不过同样作为一款能够展现终端页面样式的交付文件，它本身很多特点也一样适用于原型图，因此通过对线框图的了解，一样能够帮助我们清楚在工作中如何制作出能满足需求的原型文件。

1.不要为做线框图而做线框图

切记：

线框图的出现基本上是两个目的：

1）描述一个设计，这个设计用来解决一系列特定的业务需要和用户目标；2）帮助理解业务需要和用户目标。

这两个目的看上去似乎很矛盾，不过仔细想想，其实第一种情况是我们在尝试寻找解决问题的办法；而第二种情况，是通过表现出可能的解决方案来澄清问题，这时候我们并不是为了得到正确的解决方法，而是试图发起一个讨论，让其他人来理解问题。

2.除非确定了线框图的真实需求，否则不要建立他们

在一些时候，线框图并非最合适的表述方式或者还没有到使用线框图来表述的时候，但是你不得不去建立它，这时候需要尽可能做得灵活一些，一些内容的表述上不要限定得太死板，这样你可以通过其他交付文件来对这些遗留问题进行处理。

切记：

不要把你的线框图填满内容，这样你可能面临两种窘境：

1）不得不删除很多内容，因为会有人认为这些内容都是没有用的；2）当你应对需求修改线框图的时候，你会发现自己根本找不到可以下手修改的地方。

3.确定数量和细节

在了结了上述特点以后，我们就可以开始着手创建线框图了

1.在你开始之前列几个清单

和其他的交付件一样，在你开始动手以前，也需要有个计划。

首先，你需要列出所有的场景，根据确定的流程你需要预估大约需要多少页面、具体又是哪些页面能能达到交付的要求。

2.预估系统的复杂性

由于线框图是静态的，所以像社区首页这种页面在登录状态和非登录状态下的页面是会有很大区别的。

在制作的时候，务必确定好不同场景下的展现页面。

3.先搭框架，再钻细节

当确定了清单、流程后，制作线框图一定意义上变成了一项体力活儿，所以在细究每个页面的样式、交互之前，确保你已经把框架打好了，否则，很容易到头来不得不再对你已经辛苦做好的细节重新修改，而造成它的原因仅仅是因为你没有开一开始把握好一个页面的框架。