产品设计交付物件.docVIP

产品设计交付件之一：概念模型 明确产品的概念模型: 这里说的概念模型不同于我们通常理解上的“产品的概念”，我们认为用节点、连线来完整勾画出一个产品的体系架构可以叫做这个产品的概念模型。而提出这样一 个“概念模型”出发点也就是要通过它来明确整个项目组中对于产品完整的想法和规划，从而作为设计的基础。这里包含的内容可以相当宽泛：比如用户体验、业务 流程、网站分类结构等等。 所以概念模型对于一线的项目设计人员可以起到很好的指导作用，帮助他们理解整个项目过程中产品的基调和要求，不会在后期的设计中误入歧途。另外，对于管理者而言也能在宏观上起到很好的监督和制约，在达成对产品一致理解的基础上，整个项目的设计和运维都可以非常流畅。 如何创建你的概念模型: 第一层：建立基础的节点和连线。一般，节点可以被分为内容类型、人员/实体、数据元素、组/类别、事件、系统和其他一些。而连线就是用来连接这些节点的，并且连线上可以勾划出不同的动作来丰富节点之间的关系。 第二层：添加细节对节点进行修饰：节点的形状可以有很多表现形式，只要能表现概念任何形状都可以。例如：重要的概念可以用更大的节点来表示，以此我们可以奠定全文的基调。对连线进行修饰：除了在连线上增加文字，我们也可以通过变化连线的形式来展现概念模型。当然这具体得看上下文的关系来定了。 第三层：完善概念模型确定了节点和连线后，概念模型基本上就可以表达应有的意思了。如果还想再完善概念模型，剩下的工作就是对概念模型的背景进行修饰。记住图表的背景应尽量不 显眼，这是因为图表本身已经有了很多元素，视觉上的过多变化只会让看图的人分神，所以尽量让背景色淡化不显眼。使用背景色之前，想一想它是否真的能带给图 片有趣的信息。在概念模型中，背景有助于区分内/外过程。同时，在读者没有钻入细节前，背景也有助于他们从宏观的层次上确定该图的要点。 概念建模有哪些需要注意的地方： 1.明确建模的目的–让你的项目组成员意识到以下两点，你的建模才会让他们认为是有意义的(a)由于术语的不一致导致成员之间沟通困难(b)受绊于一堆错综复杂的概念，必须梳理清楚后才能继续推进项目。要知道，如果一开始，概念模型只是用来作为把事情讲清楚的工具，那么到了后期它其实就变成了一项有力的工具，让其他人也能接受后继设计，完成这个项目。 如果让自己成为一个建模高手： 1.要有“中心思想”，让你的建模只传递需要传递的信息，删除掉和中心无关的内容。2.从名词着手，把概念模型中的实体全部列出，然后把它们记录在纸上并用线将它们连起来，你也可以用动词表示出他们的关系。3.节点标准化，这是又一轮的筛选。看着你列出来的那些节点，找出无关的，再一次去掉。方法一：把模型中的节点限制为几个特定种类，一个文件中包含了流程、文档、事件、人员和系统五种。那么我们可以将模型限定为只要人员和文档两种节点，同时通过连接来阐述更高层次的节点。方法二：找出“局部-整体”之间的连接，有些节点彼此是可以互相替代的，我们可以去掉其中之一；只要这种省略不会影响到你的概念模型即可。（关于节点增生：常常会有模型的一侧滋生出一簇节点，它们和其他节点关联不多，必要的话我们可以把它们独立出来建成另外一个概念模型）4.节约你的连接，和节点的道理一样，并不是连接越多越好。你很难保证自己的表述不会多次重复表达，通常我们可以从两个方面来考虑：这些连接是否有利于整 体信息的表达是否能增加新信息；反之，去掉这些连接会不会让涉众错过一些信息。如果答案都是否定的，那我们可以考虑去掉它了。 需要建模，但不要教条化： 1.如果是为了澄清设计背后的假设来做概念模型，常常会发现原先的设计考虑不够充分，而在概念模型中被发现了，这会导致团队陷入无休止的调整中去，一种比较好的办法是暂时将这种差异保留，并标识清楚、说明清楚原因。2.网站的概念即使再复杂，设计也必须简单。概念模型很容易让团队只把它作为金科玉律而忽视真正的用户体验；说到底，概念模型仅仅是帮助我们识别在一定环境下的相关概念，然后让我们通过自己的设计工作避开概念带来的复杂问题。3.实用至上。我们花了很多时间去建立概念模型，结果却发现它毫无价值，这是因为我们在建模之前缺乏足够的调研。所以在建模工作之前，我们就该思考一下收集到的这些节点、用户的体验等等，这些因素究竟在概念模型中能得到怎样的体现，会否对概念模型带来影响？ 如何向你的团队推荐概念模型： 概念模型的意义在于更好地帮助团队理解设计方案，所以向团队推荐概念模型是很有必要的。不过如果仅仅是放在小团队中来使用，形式上可以随便一些，可以用讲故事的形式来把团队带进概念模型的氛围中，你的故事要以事实为基础，教会他们在这样的氛围中去思考。 会议结构：1.以解决问题做切入点：你可以和你的客户这样来解释：虽然我们已经和公司