设计师怎样掌握工程师思维？.pdfVIP

设计师如何掌握工程师思维 ？ 编者按 ：学会工程师思维 ，可以帮助你快速梳理简化设计流程 ，掌握 工程师沟通的最佳 方式。知己知彼 ，百战不殆 ，想拥有工程师思维 ，你得先了解工程师是如何思考问题的 ，全 文干货不吹水 ，直接给勺子 ，收。 这个问题的简单回答是 ：根本没有“工程师思维”。 当设计思维被广泛谈论的时候 ，惯性思维使然 ，出现了所谓“工程师思维” ，直觉上 ，“工程师思维”仿 佛站在了“设计思维”的对面 ，但事实上 ，工程师思维是并不存在的概念 ，设计思维 设计师这个角色 没有多直接联系。 于是 ，当你的问题是 ：设计师应该如何锻炼自己的工程师思维的时候 ，真正的问题应该是 ：如何和 工程师合作。 更好地和工程师合作并不是掌握所谓工程师思维 ，而是应该学会如何像工程师一样的思考 ，那么工 程师是如何思考一个问题的呢 ？ 工程师重要的思考习惯是从几个方面的信息中产生模式 （Pat t ern ），通过模式产生出代码 ，因此 ， 一个好的沟通模式是设计师尽可能提供足够的信息帮助工程师形成“模式”。 另一个方面 ，设计师往往喜欢从用户的角度讲述流程 ，而工程师所习惯关注地往往是“数据交互” 而非“人机交互” ，这也是设计师和工程师思考方式的不同之一。 这并不代表向工程师讲交互流程并不重要 ，而是我们需要结合“数据交互”和“人机交互”二者与工程师 进行沟通。 数据交互 设计师通常擅长讲解“人机交互” ，那么我们来看看设计师应该如何讲解“数据交互” ，我们推荐设计师 思考以下四个方面 ： 1. 条件 （Co ndit io n ） 2. 异常 （Except io n ） 3. 逻辑 （Logic ） 4 . 数据 （Dat a ） 假设我们要向工程师表达一个登录的设计 ： 1. 一个用户名输入框 2. 一个限定位数的密码输入框 3. 一个按钮 最传统的沟通方式是使用页面流图的方式 ，从用户的角度 ，把使用场景、信息架构、页面流程、交 互行为完整的展示 ，而如果我们考虑工程师的思维方式 ，我们可以体现以下信息 ： 条件 进入这个设计的触发条件是什么 ，例如登录的入口 ，点击什么内容能够触发这个登录界面 ；进入这 个设计的前提条件是什么 ，例如用户未曾登录。 异常 这里的异常通常指异常的数据输入 ，这有别于一个错误的结果 ，后者只是结果的一种 ，经过判断 逻辑 ，而前者的异常出现在逻辑执行前。 逻辑 逻辑用来处理1 ）异常的数据输入 ；2 ）正确或错误的处理结果 ；3 ）后台其他的写入逻辑。在我们 的例子中它们分别对应 ：1 ）超过位数限制的密码 ；2 ）密码交验逻辑 ；3 ）后台记录一次登录时间 。 数据 数据记录着在整个设计中 ，需要什么样的数据作为输入、需要什么样的数据作为展示 ，以及数据的 读写。 系统复杂度 系统复杂度往往是没有工程背景的设计师所难以理解的概念 ，因为大部分“以用户为中心”的设计师 通常以用户的感官设计体验 ，而非系统 ，这并不是反对“以用户为中心”的设计方式 ，而是多一种思 维习惯去理解工程师对实现的担忧。怎么感觉系统复杂度呢 ？ 其实很简单 ，当你仔细思考上面提到的条件、异常、逻辑、和数据四个方面 ，当每个分类中的需求 越多 ，复杂度自然变高 ，这样的思考也会使得你逐渐简化你的设计。 一个突破现有模式的“新模式”也会提高整个的系统复杂度 ，例如当我们已有一个模式叫做“点击某个 内容 ，弹出登录界面” ，如果要新增加一个模式叫做“点击内容超过5次 ，弹出登录页面” ，这里需要 对以前的现有模式进行修改 ，整体的复杂度也有所提升。 此外 ，数据的相关性也需要考虑 ，当数据来自于不同系统 ，或使用不同系统对已有逻辑进行数据 处理 ，系统的复杂度也会大大提升。 因此当工程师进行估算时 ，你不妨去听听他们估算的方式 ，他们的语言往往不是基于页面 ，而是举 出例子来评估系统复杂度 ，例如 ：“3个数据需要从第三方 来、调用3个接口、有10条后台逻辑 要写、5个前台逻辑、2个新页面模板、1个数据要写入其他模块、需要重构、需要修改以前的核心 业务测试逻辑”。当你面 对自己的设计 ，能够掰出手指数出影响系统复杂度的几个因子 ，在和工程师 沟通时自然能够理解他们所说的语言。 设计思维 之所以我认为设计思维的对面绝对不是工程师思维 ，是因为 ，设计思维本身就是工程师和设计师应 该共同拥有的思维习惯 ，而并不区分角色。除去“数据交互”和“人机交互” ，设计师应该帮助工程师了 解的是上下文 （Co nt ext ）。 上下文是隐藏在“数据交互”和“人机交互”之下的东西