有工程师思维吗？
当设计思维被广泛谈论的时候，惯性思维使然，出现了所谓“工程师思维”，直觉上，“工程师思维”仿佛站在了“设计思维”的对面，但事实上，工程师思维是并不存在的概念，设计思维跟设计师这个角色没有多直接联系。
于是，当你的问题是：设计师应该如何锻炼自己的工程师思维的时候，真正的问题应该是：如何和工程师合作。
更好地和工程师合作并不是掌握所谓工程师思维，而是应该学会如何像工程师一样的思考，那么工程师是如何思考一个问题的呢?
工程师重要的思考习惯是从几个方面的信息中产生模式(Pattern)，通过模式产生出代码，因此，一个好的沟通模式是设计师尽可能提供足够的信息帮助工程师形成“模式”。
另一个方面，设计师往往喜欢从用户的角度讲述流程，而工程师所习惯关注地往往是“数据交互”而非“人机交互”，这也是设计师和工程师思考方式的不同之一。
这并不代表向工程师讲交互流程并不重要，而是我们需要结合“数据交互”和“人机交互”二者与工程师进行沟通。
数据交互
设计师通常擅长讲解“人机交互”，那么我们来看看设计师应该如何讲解“数据交互”，我们推荐设计师思考以下四个方面：
- 条件(Condition)
- 异常(Exception)
- 逻辑(Logic)
- 数据(Data)
假设我们要向工程师表达一个登录的设计：
- 一个用户名输入框
- 一个限定位数的密码输入框
- 一个按钮
最传统的沟通方式是使用页面流图的方式，从用户的角度，把使用场景、信息架构、页面流程、交互行为完整的展示，而如果我们考虑工程师的思维方式，我们可以体现以下信息：
条件
进入这个设计的触发条件是什么，例如登录的入口，点击什么内容能够触发这个登录界面;进入这个设计的前提条件是什么，例如用户未曾登录。
异常
这里的异常通常指异常的数据输入，这有别于一个错误的结果，后者只是结果的一种，经过判断逻辑，而前者的异常出现在逻辑执行前。
逻辑
逻辑用来处理1)异常的数据输入;2)正确或错误的处理结果;3)后台其他的写入逻辑。在我们的例子中它们分别对应：1)超过位数限制的密码;2)密码交验逻辑;3)后台记录一次登录时间。
数据
数据记录着在整个设计中，需要什么样的数据作为输入、需要什么样的数据作为展示，以及数据的读写。
#p#
系统复杂度
系统复杂度往往是没有工程背景的设计师所难以理解的概念，因为大部分“以用户为中心”的设计师通常以用户的感官设计体验，而非系统，这并不是反对“以用户为中心”的设计方式，而是多一种思维习惯去理解工程师对实现的担忧。怎么感觉系统复杂度呢?
其实很简单，当你仔细思考上面提到的条件、异常、逻辑、和数据四个方面，当每个分类中的需求越多，复杂度自然变高，这样的思考也会使得你逐渐简化你的设计。
一个突破现有模式的“新模式”也会提高整个的系统复杂度，例如当我们已有一个模式叫做“点击某个内容，弹出登录界面”，如果要新增加一个模式叫做“点击内容超过 5 次，弹出登录页面”，这里需要对以前的现有模式进行修改，整体的复杂度也有所提升。
此外，数据的相关性也需要考虑，当数据来自于不同系统，或使用不同系统对已有逻辑进行数据处理，系统的复杂度也会大大提升。
因此当工程师进行估算时，你不妨去听听他们估算的方式，他们的语言往往不是基于页面，而是举出例子来评估系统复杂度，例如：“3 个数据需要从第三方来、调用 3 个接口、有 10 条后台逻辑要写、5 个前台逻辑、2 个新页面模板、1 个数据要写入其他模块、需要重构、需要修改以前的核心业务测试逻辑”。当你面对自己的设计，能够掰出手指数出影响系统复杂度的几个因子，在和工程师沟通时自然能够理解他们所说的语言。
#p#
设计思维
之所以我认为设计思维的对面绝对不是工程师思维，是因为，设计思维本身就是工程师和设计师应该共同拥有的思维习惯，而并不区分角色。除去“数据交互”和“人机交互”，设计师应该帮助工程师了解的是上下文(Context)。
上下文是隐藏在“数据交互”和“人机交互”之下的东西，它通常包含很多方面，例如市场变化、客户习惯、应用趋势、行为数据等等。例如“点击内容超过 5 次，弹出登录页面”背后的上下文可能是：用户停留在“发现页面”上的时间很长，但是一旦点击一个内容弹出对话框后页面离开率很高。
通常的情况下，这样的信息甚至连设计师都无法掌握，更不用说传递给工程师了，而设计师真正应该做的，是将这“双头冰山”水上和水下的部分统统展示出来，这也是设计思维的真正体现。
真正的修炼
归根结底，真正的修炼在于“去体验程序员做的事情”，例如抽象模式、归纳逻辑、建立假设、建立标准。有人说，过度追求逻辑和模式可能使设计缺乏“人”的因素，事实上，大部分的设计师连“追求”都谈不上、还不需要担忧“过度追求”。
以前的文章《体验设计师该学习的一点前端技术》中曾经提过关于网页工程方面的技能积累，除了掌握一定的前端知识之外，培养自己的系统思维能力也是必不可少，培养系统思维主要分：
- 系统内部的关系
- 系统外部的关系
了解系统内部关系帮助我们看穿一个看似封闭的系统(用户通常无法感知也是以用户为中心的设计无法解决的)。小时候特别喜欢看《鲁布·戈德堡机械》，看似平常物之间奇妙的互动最后完成一个平常的任务，这就是系统的乐趣所在，此外仔细研究几个著名的“系统故事”也可以逐渐培养你的逻辑和系统思维，例如“囚徒困境”、“啤酒游戏”。
了解系统外部的联系帮助我们在更高的角度理解整个生态系统，这里联系除了工程师更多关注的数据联系，包含经济、人文、文化、政治、环境等诸多联系，这并不意味着设计一个登录界面需要考虑对环境有什么影响，这只是一种思维方式，这样的思维方式帮助设计师与工程师进行沟通和协作。
#p#
从设计师到营造者
建筑师(Architect)一词在希腊语词源 arkhitekton 中包含两个意思 arkhi-， chief + tekton, builder，也就是 Chief Builder，通过与工程投资方和施工方的合作，在技术、经济、功能和造型上实现建筑物的营造，他们兼具艺术家的审美眼光、工程师的力学和材料知识、还要有说服商业投资者的商业头脑。在这里，他们并不是“设计师”(Designer)，而是“营造者”(Builder)。
在软件领域，也有“程序员(Developer)”和“架构师(Architect)”
的区别;有趣的是在我们所说的设计领域(数字产品设计)，却鲜有“Architect”的概念，有的最多是“产品经理”这样的角色(残缺的)。相信在不久以后，我们所在的领域，也会出现这样的角色，他们拥有：
人机交互设计师对于信息、界面、交互、视觉表现优秀的审美;
工程师对于逻辑、流程、数据、系统的思维方式;
对商业、环境、文化、人因、政治诸多因素的审视。
我们经常陷入一种误区，害怕某种思维方式会影响我们现有的思维方式，例如过多的逻辑思维会不会影响我对人和直觉的关注，最后影响我的设计，当设计越来越不是一个单独的技能而进化为一个“整体营造行为”中的一部分时，我们所执着的思维方式也需要演进。
这并不意味我们需要掌握并不存在的“工程师思维”、使用它和工程师进行合作，而是将工程师看待设计的方式融入到我们自己的思维习惯中，这也将帮助我们完成从设计师到营造者的转化，作为“营造者”，你必将超越工程师、产品经理、和现在作为设计师的你。
