设计是什么?

最近重看《深泽直人》,在书里看到了我觉得最准确的定义——

设计是为情景寻找合适的答案。

根据我工作以来的理解,我想大概有这么几层意思:

1. 设计是用来解决问题的,问题必须是切实存在的,而不是主观臆想出来的;

2. 设计不只有唯一的答案,所以才要「寻找」,好的设计是找到问题的最优解。或者说,好设计是试出来的。为什么好设计那么少?因为寻找的过程会受到很多客观限制:时间、资源、信息以及设计师当时的眼界,所以设计师给出的答案是在种种限制下找到的相对优的解决方案;

3. 设计最重要的是要关心「情景」,脱离情景谈设计没有意义。设计过程中最重要的是去了解用户实际使用产品的场景,然后再去为这个特定的场景设计方案。

好设计是什么样的呢?深泽直人说,好设计是可以让用户凭借日常无意识的经验中所产生的认知经验,就可以使用的设计。书里说「设计并不是我所创造出来的,它原本就在那里,我所做的一切,只是将它呈现出来。」,好设计是融于情景之中的,甚至不会让人感受到「设计」的存在。

对用户来说,好设计是那种让用户说出「我一直都希望拥有这样的东西」的设计。

还有要注意的是,情景是会变化的,设计的最优解也会跟着一起变化,所以想留下「经典」设计才会那么难。

加油吧!

a

2016 移动设计趋势

以下都是瞎扯——

1. 全方面的个人数据整合 

iOS 和 Android 都在系统层面提供了基本健康数据监测功能,层出不求的智能硬件也使得个人的数据更加完善,为了全方面的个人数据整合提供了基础。

在之前《2015 酷设计》中介绍的 Gyroscope 已经对用户的多项数据进行整合,数据主要分成运动信息、位置信息、多媒体信息三类。但它本身并不记录任何数据,而是通过连接不同的 APP 以及智能硬件获取数据,包括下面这些数据来源:

image

连接了上面的工具之后,你就可以精准的知道,你在某一天说过哪些话、发了哪些照片、去过哪里、工作了多久以及效率如何、走了多少步、跑步或骑行的运动量以及路线、还有体重血压和其他个人健康数据情况。而且会自动进行月度、年度统计。

image

当这些数据汇集到一起的时候,就组成了你在智能时代的个人日志,你看到的不只是每日的情绪和事件,而是全方位关于你的数据,你只管使用这些服务,统计的任务将自动替你完成。

相比之前每个产品只监测特定的某项数据,之后会有更多的数据被整合到一起,甚至这些数据将应用到现实生活中,例如健康医疗等领域。

再到年底,你可能就不满足于「微信年度报告」统计那些简单数据了。


2. 更复杂的交互手势

image

来源:Apple

iPhone 6s 加入了 3D touch  这种新的交互手势,让移动端操作更加多样化,虽然对大部分用户来说有一定的学习成本,但为高级用户提供了更加有效率的操作方式。

3D touch 主要用作进入主页面前的快捷操作入口,以及省去了应用间跳转返回的过程。虽然目前大部分的应用都是围绕前者设计的,但我觉得后者可能才是一个更重要的改变。从智能机出现以来,多任务处理的问题其实一直也没有很好地被解决,使用过程中总会在不同的 APP 中切换,举个例子,你在和朋友通过信息聊天约定晚上吃饭的地点,你想去地图里看看位置离你远不远。

Keep reading

#设计#分享
a

2015 酷设计

2016 已经过了 1/24,才回过神来,一年又过去了,时间消失的速度总比想象中快得多。

和往年一样,年初写的美好计划当然大部分都没完成,改个年份就能接着用。不过还是想总结一下,把一年中见过用过的产品中设计够「酷」的列出来,几年过后就能看到设计在以何种趋势发展。

提前要说明的是,列出来的产品都是在过去一年使用过的,但并不一定是去年才出现的。另外也没有固定的评选标准,完全不客观,不过能列出来的产品或者是视觉设计风格鲜明、充满美感,或者交互形式有独特的创新,或者兼而有之。



1. Gyroscope

image

Gyroscope 是个人数据管理工具,数据主要分成运动信息、位置信息、多媒体信息三类。但它本身并不记录数据,而是通过强大的数据整合能力,连接不同的 APP 以及智能硬件获取数据,包括下面这么多工具:

image

连接了上面的信息之后,你就可以精准的知道,你在某一天说过哪些话(Twitter)、发了哪些照片(Instagram, Twitter)、去过哪里(Foursquare, Moves)、工作了多久以及效率如何(RescueTime)、走了多少步(Fitbit, Jawbone, Moves)、跑步或骑行的运动量以及路线(RunKeeper, Strava, Jawbone)、还有体重血压和其他个人健康数据情况(Withings, Google, Apple)。

image

这些数据加起来可能就是智能时代的个人日记吧,和传统日记的区别是,你看到的不只是每日的情绪和事件,而是全方位关于你的数据,而且把汇总的过程也省略了,你只管使用这些服务,统计的任务自动替你完成。

Keep reading

#设计#分享
a

资深设计师资深在哪?

Julie Zhuo 在 Medium 上用几副小画说出了初级设计师和资深设计师的差别,很有意思,道理也不限于设计领域,后来被改成其他职位继续流传。

下面是其中一个对比:

image
image

除了上面文章里列出的几点外,在我看来,初级设计师和资深设计师的差别还在于设计方法上的区别,简单说就是初级设计师按照做问答题的方式做设计,资深设计师则是按照解选择题的方式做设计。

解释一下,设计师和很多需要创造力的岗位一样,视野是基础。设计是一个匹配内容(功能、产品属性)与形式(交互、视觉等)的工作,而且更偏向于形式的创造,所谓好的设计就是形式与内容相得益彰的产品。

形式 X 内容 = 设计

作为设计师,视野的宽窄决定了你是否能找到最佳匹配的形式。初级设计师往往对设计形式没有足够的了解,所以在尝试设计方案时,很容易为产品创造出一个解决方案,运气好的话会出现一个独特的方案,运气差就重复造了一个别人已经造过轮子,而且是否与产品内容相符也是疑问。如果把同样的任务交给眼界开阔的资深设计师,他会把自己头脑中的形式过滤一遍,最后从多个内容与形式的组合中,选择最合适的一个。

可能有朋友会问,那还有「原创设计」吗?

Keep reading

#设计#分享
a

Lean UX 与团队协作

——《精益设计》读书笔记 & 团队协作的思考

几乎国内大一点的互联网公司都会设立独立的用户体验团队,虽然名称上各家稍有差别,不过在协作上多数还是传统瀑布式流程:设计部门从上游产品部门获得需求,完成交互和视觉设计之后,再交付给技术和测试等下游环节,交付完成后再来应付下一波产品需求,要是遇到些问题还需要反复修改的话,下游的进度也会一并耽误。

这样的协作流程把整个流程中各个部门的职责分的很开(包括办公位置也是),所以各个部门的人也会理所当然的给自己部门画出一个隐形的「职责边界」:产品只负责产出需求、交互负责产出原型、技术只负责开发… 每个人只对项目中的一个环节负责,对职责边界以外的事情就放手不管了,于是整个团队中只能看到只对自己的环节负责的人,却找不到对整个产品负责的人。

在这种协作模式下,很多时候遇到职责边界不那么明确的事情,又没有及时沟通,就很容易出现各部门互相推诿的情况。即使这次的问题被明确到某个部门的职责边界中,下次出现个其他不明确的问题,这样的情况依然会往复发生。

那么问题出现在哪呢?公司的产品是按照「项目」划分的,但是却不是按照项目整体推进的,完成项目的方法是一环接一环的传递,参与项目协作的人也分散在各个部门,所有人对项目并没有整体的概念,例如项目的目标、价值、成员所做事情的意义等等。而且项目成功了并不带来好处,失败了也不会影响绩效,所以大家只能埋头做好自己的分内工作,就好了。

把产品协作的各个环节作为独立部门,会带来很大的浪费,包括冗长流程带来的效率浪费,还有各部门对项目缺少整体的理解带来的沟通浪费。

Lean UX 就是为了减少这两部分浪费提出的。

协作的本质是沟通,环节越长、团队越分散,沟通成本就越高,就不能保证信息传递的准确性和及时性,Lean UX 就是通过精简环节、注重沟通来提升效率。

Lean UX 的精髓在于跨职能小团队和集体决策——确定项目后,把参与项目的成员聚集在一起,建立跨职能小团队。小意味着快,因为沟通的环节减少了,沟通的成本下降了,效率自然会提升,然后通过团队集体快速决策 、简化流程和交付物等方法使协作的效率最大化。而且以「项目」驱动的小团队更能明确集体目标,会有更强的参与感和责任心,也会让团队成员有更强的意愿参与决策,产品在做之前团队成员就已经达成了一致,而不像瀑布式的流程开发中经常出现的下游环节对上游决策的质疑。

这样的跨职能团队一定是以目标驱动的,团队有权力直接针对业务问题设计解决方案。也就是说,由团队自主决定用哪些功能来实现公司的目标。产品需求也必须从成果的角度来谈:我们希望通过这个产品达成什么目的?设计也是如此。

Lean UX 涉及到的另外两个概念是精益创业的 MVP(最简可行产品)和敏捷开发中的 Scrum 方法。

精益创业法使用了“开发-评估-认识”的反馈环来降低风险,让团队可以快速开发和认清现实。精益创业团队开发出最简可行产品(MVP)之后,就迅速把产品推向市场,以便及早地认识市场。

Scrum
一种敏捷方法论,推崇限时迭代,自行组织,具有高度团队责任感。Scrum是运用最广的敏捷方法论。大多数Scrum团队都把两周算作一个 sprint,sprint 的目的是交付可用的软件。

建立跨职能小团队后,融合 Scrum 工作方法进行快速迭代,然后通过 MVP 快速验证产品方向,然后根据用户的反馈继续调整方向,开始下一个迭代……

另外 Lean UX 也是有理论依据的,罗伯特·戴利(Robert Dailey)在20世纪70年代末做过一次研究,称为“论团队和任务特征对于研发团队协作式问题解决和生产效率的作用”(The Role of Team and Task Characteristics in R&D Team Collaborative Problem Solving and Productivity)。在这次研究中,戴利发现团队解决问题的效率和四个因素有关,他称之为“四个预测因素”:任务的明确度,任务的独立程度,团队的规模,团队的凝聚度。

所以你看,落实到团队协作中,Lean UX 提到的工作方法基本也是以上几点的延伸。另外说一句,虽然介绍 Lean UX 这本书叫《精益设计》,不过里面的方法多数是围绕团队协作展开的,推荐阅读。

如果懒得翻书,就先看看我的书摘吧。

#读书#设计#分享
a