设计模式:超越软件与设计的模式语言

最近看了一本书《架构启示录》,书中研究传统的建筑工作与数字产品的架构工作之间有着怎样的联系,重点探讨了Christopher Alexander、Richard Saul Wurman、Cedric Price 与 Nicholas Negroponte 4 位建筑师的工作。
软件设计和建筑设计真的非常像,都是试图寻找一种解决复杂的问题的优雅方案。
软件设计
软件工程 
vs 
建筑设计
建筑工程
我们把软件拆解成2部分,一部分是设计,另一部分是工程。由于没有在外企工作过,在此我谈谈国内我所知道的情况。
软件设计在国内被拆解成了产品经理、体验设计师、架构师的工作范围,程序员的思维方式大部分只停留在“敲代码”的认知,认为信息架构的工作是产品经理或者设计师的工作。实际工作中,大部分的程序员甚至对设计模式的理解只停留在几种经典的模式:单例、工厂、观察者等模式。程序员基本上等于软件工程,更多的是负责软件的编码实现工作。
而建筑设计,被拆解成了概念设计、方案设计、施工图设计,甚至有效果图设计的工作范围,每个工种普遍都具备架构思维;建筑工程则是现场根据蓝图进行施工。有所差异,但是又那么地相似。
- 模式语言,经验的高度抽象

模式语言是一种经验的高度抽象,可以被快速传授,跳过了设计师/程序员(适合于任何职业)需要长年累月的经验积累这一环节。
无论是构建房屋还是编写程序,都是规模相当庞大而且也相当复杂的工作,设计者必须经过好多年的培训才能胜任。克里斯托佛·亚历山大提出了一套办法《建筑模式语言》,让我们觉得这有可能会实现,他的这套办法围绕着'模式语言’这一概念而展开。该书介绍了城市设计的 “语言”, 而此类 “语言” 的基本单元就是模式。模式中可能会包含对窗户应该有多高、 一座建筑应该有多少层以及一片街区应该有多大面积的植被等信息的描述。

复杂问题的各种解法

-> 设计规则

设计上的设计模式,更接近于设计规则(原则),如果是平面设计,如配色规则之类的;空间设计的话,就如“一池三山”此类经典空间模式;一般是可以用图纸来表达的。

-> 代码设计:伪代码

软件设计中的设计模式是常见问题的典型解决方案。设计模式常用于解决代码中反复出现的设计问题。设计模式与方法或库的使用方式不同,你很难直接在自己的程序中套用某个设计模式。你需要根据模式来实现符合自己程序实际所需的解决方案。
人们经常会混淆模式和算法,因为两者在概念上都是已知特定问题的典型解决方案。但算法总是明确定义达成特定目标所需的一系列步骤, 而模式则是对解决方案的更高层次描述。同一模式在两个不同程序中的实现代码可能会不一样。
算法更像是菜谱:提供达成目的的明确步骤。而模式更像是蓝图:你可以看到最终的结果和模式的功能,但需要自己确定实现步骤。(是不是有点像产品原型图?)
设计模式,一般常用伪代码来表达。一般我们把代码的设计模式分为3种:创建型模式,提供创建对象的机制,保持代码的灵活性和可复用性;结构型模式,解决如何将对象和类组装成较大的结构,并同时保持结构的灵活和高效;行为模式,负责对象间的高效沟通和任务调度。一张图概括设计模式:

-> 软件开发:如何设计成功的系统?

要遵循两个原理,分别是第一性原理和第二系统效应。

第一性原理

First principle thinking

第一性原理是基本的命题和假设,不能被省略和删除,也不能被违反。列举一些例子来理解:

Brandmark认为越粗的字体配填充面积越大的 icon ,是一个较好的设计;自然语言处理认为一个词的含义可以从它的上下文语境中推断出来 ;色彩关系,将一张图片中的颜色视为上下文,来推断出颜色之间的搭配关系;音乐分离,当耳朵无法分辨两种乐器时,眼睛通常会通过将每个乐手的动作与每个声音的节拍相匹配来进行调整,将每个乐手的动作通过其骨骼关键点匹配到各个声音的速度,从而分离单个长笛或小提琴声音;用户行为,就像人们可以通过将句子中的一系列单词视为上下文来训练词向量一样,我们也可以将用户行为序列视为上下文,来训练出用户行为向量。

第二系统效应
second-system effect
在完成一个小型、优雅而成功的系统之后,人们倾向于对下一个计划有过度的期待,对旧系统的遗留问题进行修正,添加新特性,结果可能造成软件过度设计,产生太多变数,过度复杂,无法达成期待,并因而失败。
类似的道理,在《交互式程序设计》书中提到:“交互系统的丰富性和实现它的难度是密切相关的:交互越是丰富,越是容易出错。” 这点深有体会,越是复杂的交互,越容易造成系统的偏离。

-> 基于机器学习的体验设计

和不太了解机器学习的设计师谈智能产品的体验设计,沟通是不通畅的,因为双方没有共同语言(这里指的是机器学习)。
设计发现
推荐系统可以帮助发现已知的未知数,甚至未知的未知数。例如,Spotify帮助用户发现音乐。至少面临三个主要的设计挑战。
首先,平衡准确性与随机性。推荐系统类似于“过滤器”,将建议(例如产品、饭店、新闻,与之相关的人)限制在严格地依赖于个人行为历史数据上。数据科学家有时必须调整算法,降低准确性,并给建议增加一定的随机性。
其次,用户可干预推荐系统的数据。例如,亚马逊允许用户删除可能对建议产生负面影响的物品。客户为他人购买了礼物,而这些礼物对于将来的个性化推荐并不一定是必需的。
最后,交互式机器学习。例如,如何在产品使用过程中,自然地融入用户手动清理数据集,或减轻机器学习算法限制?
设计决策
数据和算法还提供了个性化决策的手段。例如,为客户提供财务建议。系统考虑了帐户余额的时间演变来细分储蓄行为。通过这种技术,我们能够根据每个客户的省钱能力来提供个性化投资机会的决策建议。
设计不确定性
计算机程序遵循二进制逻辑,将明确的有限的具体可预测状态集转换为工作流。机器学习算法通过模糊逻辑改变了此流程。机器学习旨在一组样本行为中寻找模式,以概率近似这些行为的规则。这种方法具有一定程度的不精确性和不可预测的行为。
例如,预订平台Kayak根据对历史价格变化的分析来预测价格的变化。算法旨在返回对是否适合购买机票的置信度。
设计师利用此特质,提出了无缝设计Seamful design。无缝设计是关于利用失败和局限性来改善体验的一种设计方法。它使用户可以告知系统较差的情况。
·   精度分数传达了提供与所需结果完全匹配的结果的能力。
·   召回分数传达了提供大量可能的良好建议的能力。

-> 用户体验设计的一些模式

step by step 的模式到底好不好?我们很少在桌面软件看到有这种操作模式,原因是流程过长,操作起来反而不方便。
keynote的新建文件,出现的可选项:模板、空白文件。
Pinterest的返回按钮,可视化返回多路由导航。
visual studio code的workspace,在文件、文件夹的管理基础上增加了workspace的概念。
sketch的group、symbol,组件和成组的概念。

-> 抖音的工具箱模式

# 设计师&交互工程师:提出新idea
# 创意评审会:决定实现哪些idea
# 工具箱:如果idea的实现技术已经有了,直接使用
# 智能创作算法团队:idea的技术能力当前还不具备,就会专门投入研发资源,训练新的算法模型。
如此循环,新的算法更新到工具箱,源源不断地新idea被提出,这样抖音用户总有新奇的道具特效可以使用。

-> 如何让事情保持在正确的方向上?或者说掌控力如何提高?

一种解法就是把事情进行拆解,并转化为关键行动,关键行动是一种模式,可以被设计出来,具体模式可以是站会、简报、原型设计、demo等。

-> 商业模式

以前在设计行业,经常有卖盗版书的上门推销,总会买个几本图集。现在网络资源丰富,盗版书商不见了,电子资料盛行了。技术一点的做法就是 用爬虫爬各大网站的图片,汇总归类,成为图集,卖订阅会员费。

总结

设计模式是一种通用的解决方案,或者是一种规律,或者是一种经验的总结。做设计或者写代码(写文章)的时候,我们应该努力做到无意识地使用设计模式。不管是什么职业,只是所使用的工具不同而已,模式语言是类似的。


to be continued

欢迎与我交流~
实验室社群
(0)

相关推荐