概念模型设计
这里说的概念模型不同于我们通常理解上的“产品的概念”，我们认为用节点、连线来完整勾画出一个产品的体系架构可以叫做这个产品的概念模型。而提出这样一个“概念模型”出发点也就是要通过它来明确整个项目组中对于产品完整的想法和规划，从而作为设计的基础。这里包含的内容可以相当宽泛：比如用户体验、业务流程、网站分类结构等等。
所以概念模型对于一线的项目设计人员可以起到很好的指导作用，帮助他们理解整个项目过程中产品的基调和要求，不会在后期的设计中误入歧途。另外，对于管理者而言也能在宏观上起到很好的监督和制约，在达成对产品一致理解的基础上，整个项目的设计和运维都可以非常流畅。
如何创建你的概念模型：
第一层：建立基础的节点和连线。
一般，节点可以被分为内容类型、人员/实体、数据元素、组/类别、事件、系统和其他一些。而连线就是用来连接这些节点的，并且连线上可以勾划出不同的动作来丰富节点之间的关系。
第二层：添加细节
对节点进行修饰：节点的形状可以有很多表现形式，只要能表现概念任何形状都可以。例如：重要的概念可以用更大的节点来表示，以此我们可以奠定全文的基调。
对连线进行修饰：除了在连线上增加文字，我们也可以通过变化连线的形式来展现概念模型。当然这具体得看上下文的关系来定了。
第三层：完善概念模型
确定了节点和连线后，概念模型基本上就可以表达应有的意思了。如果还想再完善概念模型，剩下的工作就是对概念模型的背景进行修饰。记住图表的背景应尽量不显眼，这是因为图表本身已经有了很多元素，视觉上的过多变化只会让看图的人分神，所以尽量让背景色淡化不显眼。使用背景色之前，想一想它是否真的能带给图片有趣的信息。在概念模型中，背景有助于区分内/外过程。同时，在读者没有钻入细节前，背景也有助于他们从宏观的层次上确定该图的要点。
概念建模有哪些需要注意的地方：
1.明确建模的目的–让你的项目组成员意识到以下两点，你的建模才会让他们认为是有意义的
（a）由于术语的不一致导致成员之间沟通困难
（b）受绊于一堆错综复杂的概念，必须梳理清楚后才能继续推进项目。
要知道，如果一开始，概念模型只是用来作为把事情讲清楚的工具，那么到了后期它其实就变成了一项有力的工具，让其他人也能接受后继设计，完成这个项目。
如果让自己成为一个建模高手：
1.要有“中心思想”，让你的建模只传递需要传递的信息，删除掉和中心无关的内容。
2.从名词着手，把概念模型中的实体全部列出，然后把它们记录在纸上并用线将它们连起来，你也可以用动词表示出他们的关系。
3.节点标准化，这是又一轮的筛选。看着你列出来的那些节点，找出无关的，再一次去掉。
方法一：把模型中的节点限制为几个特定种类，一个文件中包含了流程、文档、事件、人员和系统五种。那么我们可以将模型限定为只要人员和文档两种节点，同时通过连接来阐述更高层次的节点。
方法二：找出“局部-整体”之间的连接，有些节点彼此是可以互相替代的，我们可以去掉其中之一；只要这种省略不会影响到你的概念模型即可。
（关于节点增生：常常会有模型的一侧滋生出一簇节点，它们和其他节点关联不多，必要的话我们可以把它们独立出来建成另外一个概念模型）
4.节约你的连接，和节点的道理一样，并不是连接越多越好。你很难保证自己的表述不会多次重复表达，通常我们可以从两个方面来考虑：这些连接是否有利于整体信息的表达是否能增加新信息；反之，去掉这些连接会不会让涉众错过一些信息。如果答案都是否定的，那我们可以考虑去掉它了。
需要建模，但不要教条化：
1.如果是为了澄清设计背后的假设来做概念模型，常常会发现原先的设计考虑不够充分，而在概念模型中被发现了，这会导致团队陷入无休止的调整中去，一种比较好的办法是暂时将这种差异保留，并标识清楚、说明清楚原因。
2.网站的概念即使再复杂，设计也必须简单。概念模型很容易让团队只把它作为金科玉律而忽视真正的用户体验；说到底，概念模型仅仅是帮助我们识别在一定环境下的相关概念，然后让我们通过自己的设计工作避开概念带来的复杂问题。
3.实用至上。我们花了很多时间去建立概念模型，结果却发现它毫无价值，这是因为我们在建模之前缺乏足够的调研。所以在建模工作之前，我们就该思考一下收集到的这些节点、用户的体验等等，这些因素究竟在概念模型中能得到怎样的体现，会否对概念模型带来影响？
如何向你的团队推荐概念模型：
概念模型的意义在于更好地帮助团队理解设计方案，所以向团队推荐概念模型是很有必要的。不过如果仅仅是放在小团队中来使用，形式上可以随便一些，可以用讲故事的形式来把团队带进概念模型的氛围中，你的故事要以事实为基础，教会他们在这样的氛围中去思考。
会议结构：
1.以解决问题做切入点：
你可以和你的客户这样来解释：虽然我们已经和公司里许多人都探讨过“政策”和“规章制度”了，不过我们还是不太明白它们是怎样融合到整个过程中的，当然我们希望设计文档中能够适当呈现这些元素，所以我们想把这个概念模型整理一下，借此澄清文档和公司关键人物的关系。
如果对方之间没有接触过概念模型，这样的介绍会受到不错的效果，因为它包含了上下文背景，同时对方也具有对节点关系一定程度上的把握。
2.节点-关系法
如果文档是从某个节点或者一系列节点延伸开来的，那我们就可以以这些节点作为焦点，然后逐渐向外眼神来介绍概念模型，
3.白板法
可以让我们在没有实际的交付件时，把一些节点或者概念写在白板上通过头脑风暴来把所有的关系找到。你要做的一般只是把一些需要用到的节点事先标注出来。如果你想把话题引到一个你希望的方向上，你最好能事先准备好一个概念模型。ps：概念建模时难免抽象、主观。为了能保证主题的集中，也避免扼杀大家的创造力，不妨事先把会议目的的声明先写在白板上。
结束语：
我们努力建造的模型，我们努力让开发人员明白的术语，对于用户来说可能永远也用不到，但是这是为了让开发设计过程变得更加容易，让概念变得更加容易得到一致的认识。事实上没有概念模型，很多设计就会无从下手，随着web系统的愈加复杂，用户交互的增多，（例如依赖搜索式导航而非浏览式导航的网站、依赖用户所贡献内容的有机增长的网站、通过内容的聚合简化了信息的传递的网站）设计之前的概念构建就显得非常必要。
相关阅读
舒舟（阿里巴巴1688事业部）：人们普遍认为，流程和工具不重要，重要的是想法和思路。话虽如此，不过我认为流程和工具也能反映一个设计师的设
大家都说后台产品难做、要求高，这是有原因的。而且这个原因会超出我们的认知，一起来看看吧。什么是后台产品后台产品也被我们称为后
1. 引言 在深度学习十分火热的今天，不时会涌现出各种新型的人工神经网络，想要实时了解这些新型神经网络的架构还真是不容易。光是
互联网优秀的产品很多，笔者只从个人力所能及的认知范围去介绍所认可的作品，就如上次写的《从京东看商城产品设计》，可能有其他优秀几
做产品的要学会分析用户心理，诱导用户按我们的意愿办事，但还得看起来像是用户做了英明的决策。该文非常多智慧的火花，收藏学习。闹得