设计原本

2020/03/31 软件学

设计之模型

设计的疑问

培根爵士的结论对吗

对一种技艺进行观察,并将所思所想运用到另一种技艺中,使得诸般妙用在一人的头脑中不断反思(新思维也就不期而至了)。-—弗朗西斯·培根爵士(1605),《The Two Books of the Proficience and Advancement of Leaming》

弗朗西斯.培根爵士的猜想,也是我们所面临的挑战。设计过程本身真的有这样不变的、放诸各种设计领域而皆准的属性吗?

如果以上说法都成立,并且培根的结论也成立的话,那么即使是工作领域彼此不同的设计人员,通过对比他们的经验和洞见,也有望在其各自专长的技艺领域学到新知识。

什么是设计

英国作家、编剧Dorothy Sayers在她那本发人深省的著作《The Mind of the Maker》里,将创作过程细分为三个不同的阶段,并分别称之为构想(idea)、运能(energy)或称实现(implementation)、交互(interaction)。意思是:

  1. 将概念结构定形
  2. 在实际的领域中加以实现
  3. 在实际的应用中与用户交互

何为实在?设计理念

雷丁大学的Rachael Luck在架构会谈中提出一个原先未引起任何人注意,后来却被大家一致意识到的实体,即设计理念(Design Concept)。

毫无疑问,架构师和客户总是不断提到这个共识中的无形实体(即设计理念)。演讲者在谈及它时,常常会对着演示画面含糊地指点,但显然他们的意思并不是指整个演示画面或是画面中的某个特定事物。 而他们实际上关注的总是研发中的设计的概念完整性(conceptualintegrity)。

价值何在

识别出隐形的设计理念,并在设计对话中转化成实在的实体,是否可以带来积极的价值呢?我认为答案是肯定的。

  • 首先,伟大的设计都具备概念完整性–统一、经济、简洁。
    • 识别出设计理念这个实体, 有助于我们在独立做自己的设计时去追寻这样的完整性,有助于在团队设计时围绕它协同工作,也有助于将它传授给年轻人。
  • 其次,经常提及设计理念,对于设计团队的内部沟通也有极大的帮助。概念统一这个目标,只有通过大最的对话才能达成。

如果设计理念本身是焦点,而不是拐弯抹角的表达或残缺不全的细节,那么沟通就可以非常直截了当。

因此,电影制片人都使用故事板(storyboard)来将他们的设计讨论的关注点始终保持在设计理念上,而不会陷入实现细节。

设计面面观

系统设计vs.艺术设计

本书旨在讨论复杂系统的设计,站在工程师的视角看问题。工程师关心实用和效益,但同时也要兼顾效率和优雅。

这与艺术家和作家所完成的许多设计大相径庭,后者更强调愉悦感,以及意义的传达。当然,建筑师和工业设计师同时属千两个阵营。

例行设计、改造设计和原创设计

本书的重点在于原创设计,它不同千通过变换参数就可以一个对象接着一个对象地进行的例行设计(routine design),甚至也不同千改造设计(adaptive design),后者只是修改以往的设计或对象,以满足新的用途罢了。

理想的设计过程模型

理想的设计过程模型

工程师怎样进行设计思维–理性模型

模型概览

  • 目标。
    • 首先从主要目标或目的开始:“某人想要建一个海滨小屋,以欣赏面向大海的一块海滨场地的风景。"
  • 必要条件。
    • 和主要目标相关的是一组必要条件或者说是次要目的:“海滨小屋应该加固,以抵御腿风来袭;它应该具备至少14个人躺卧和就座的空间它应该为宾客提供令人难忘的视野”,等等。
  • 效用函数。
    • 人们会根据一些效用(或有用性)函数来为若干必要条件依其重要性加权,以对设计进行优化。
    • 到目前为止,我知道的情况是,在大多数设计师的想象中,所有的项是由线性相加的方式组合起来的,但在单独构思每一个效用函数时,则井非使用线性方式,而是以渐近曲线的方式趋千饱和。
    • 举个例子,必要条件之一是更大面积的窗户,这是在小屋设计中所需要考虑的问题。但是由每平方英尺窗户面积的额外增加所带来的效用是递减的。就电源插座的数量来说,这也一样成立。窗户面积以及插座数量的总效用,看起来却仅仅是每个项的简单之和。
  • 约束。
    • 每种设计以及每种优化都是受到一些约束限制的。
    • 其中有一些约束是二元的,只有满足或不满足的结果–”这所小屋必须位千海滨场地的边界线并再向后退至少10英尺”。
    • 其他约束则更有弹性,不过在接近限额时所付出的代价会急剧增加,例如日程表就是这样一类约束——主人可能急切地要求该海滨小屋在温暖气候来临之前完工。
    • 有些约束是简单的,例如退后尺寸的限额,而另一些约束则在不经意间隐藏着令人生畏的复杂性一”该小屋必须满足所有的建筑法规”。
  • 资源分配、预算和关键预算。
    • 许多约束的形式是固定资源在各个设计要素之间的分配。最常见的是一揽子成本的预算。但是,此类约束绝不仅仅只有这么一种,而且在特定的项目中,总预算约束也井不一定就是最大限度地决定了设计师注意力的约束。
    • 例如,在海滨小屋的楼层规划中,占支配地位的定扯因素是临海建筑距离的英尺数(甚至要精确到英寸)。
    • 在计算机体系结构的设计中,关键预算可能是控制寄存器或指令格式所占用的比特数,或总内存带宽的用量。而当人们解决软件的“千年虫”问题时,日程表上的工作天数成为了可分配资源中的关键项。
  • 设计树。
    • 这么一来,按照理性模型的思路,设计师们形成设计决策。然后,在由于该决策而缩减后的设计空间中,他又形成另一决策。在每一个节点处,他都可以选取一条或多条路径,因此设计的过程可以认为是一种对于以树型结构组织的设计空间的系统化探索。

在这样一个模型中,设计在概念上(至少在概念上)是个简单的过程。人们对以树型结构组织的设计空间进行搜索,以可行性约束为依据对每种方案进行检验,从而优化效用函数。搜索算法是众所周知的,并且可以清晰地描述。

这种清晰性仅仅是指对所有路径进行的穷举搜索,寻找一个真正的最优解。设计师们通常只去寻找一个“足够好”的满足解。 许多工程师似乎采用了某种深度优先搜索策略进行近似估算,并在每个节点上选择最有前途或最有吸引力的方案,并采用探索到底的办法来达成目的。如果遇到死胡同,他们会采用回溯的办法并尝试另一条路径。预感、经验、连贯性和审美观引导着每一次的方案选择。

瀑布模型

设计空间可以表达为树型结构的观念

设计空间可以表达为树型结构的观念

理性模型有哪些长处

  • 与“先开始编码再说,或先开始构建再说”的行为相比,任何将设计过程系统化的工作都可以视为一种长足的进步。
  • 它为设计项目的规划提供了清晰的步骤。
  • 它为日程规划和进度评估定义了明确的阶段里程碑。
  • 它为项目组织和人员配备指明了方向。
  • 它改进了设计团队的内部构通状况。
  • 而在设计团队和其项目经理之间以及项目经理和其他利益相关者之间而言,它对于沟通的改进尤为显著。
  • 新手很容易就可以上手。掌握了它,新手在面对分派给他的第一个设计任务时,就知道从何入手了。

理性模型在特定的情形下会体现出更多的长处。

  • 在项目早期就给出目标的明确陈述、相关的必要条件以及约束说明,这有助千避免团队陷于举棋不定的局面,也促使团队形成关于项目宗旨的统一认识。
  • 在开始编码或正式的制图工作开始之前做好整体的设计过程规划,就能够规避大量麻烦,也避免让许多努力付之东流。
  • 将设计过程打造成对于设计空间的系统化搜索,可以拓宽设计师个人的眼界,并远远超过其先前的个人经验。

不过,理性模型太过简化了,即使是Simon洋洋洒洒、高度成熟的版本也不免于此。因此,我们必须对其缺陷加以审查。

理性模型有哪些缺陷

现实情况是,设计师只把理性模型视为一种理想化的东西。理性模型描述了我们认为设计过是怎样的,但在现实生活中,并不是那么一回事。

在初始阶段我们井不真正地知道目标是什么

理性模型最严重的缺陷在于,设计师们往往只有一个模糊不清的、不完整的既定目标,或者说是主要目的。在此情形之下:设计中最困难的部分在于决定要设计什么。

为客户提供的最有用的服务是帮助他决定什么是他真正想要的。

快速原型是一种进行精准需求配置的必要工具。不仅整个设计过程是迭代的, 就连设计目标的设定过程本身也是迭代的。

设计师的主要任务乃是帮助客户发现他们想要的设计。

在目标迭代方面,我在这些设计领域都看到了相同的现象。越来越多的设计师们为计算机构建模拟器,为建筑构建虚拟环境演练,以此作为快速原型,从而促成目标的收敛。目标的迭代必须作为设计过程的固有组成部分加以考虑。

我们通常不知晓设计树的样子—一一边设计一边探索

设计师们会一边做着设计,一边进行设计树的探索做出某个决策,然后查看由它启发或否决的备选方案,继而依此做出排在下一个的设计决策。

(设计树上的)节点实际上不是设计决策,而是设计暂定方案

事实上,特定的设计树自身只是在树形结构中搜索的简化模型。

这意味着,在设计树的每一个节点处,设计师所要面对的不仅仅是为单独一个设计决策准备的若千简单备选方案,而是为多个设计暂定方案准备的备选方案。

此外,设计树中的决策排列顺序事关重大。

以树型结构表示的设计模型,其复杂性带来的组合爆炸是思维难以承受之重。

效用函数无法以增量方式求值

理性模型的假定是,设计是对千设计树的搜索,并且在每个节点人们可以对若干下一级分支的效用函数求值。

事实上,除非探索到所有分支的所有叶节点的程度,否则人们就很难做到这一点,因为大量的效用指标(如性能、成本等)严重依赖千随后的设计细节。因此,虽然对效用函数的求值在原则上是可行的,但是在实践上,人们会在这里再次遭遇组合爆炸。

那么,设计师该怎么做?估算!理所当然,正式的也好,非正式的也罢,都要做估算。在求精的步骤中,人们必须对设计树进行剪枝。

  • 经验。
    • 研习设计史的最有力的原因是去了解怎么样的设计方案是行不通的以及为什么这些设计方案行不通。
  • 简单估算量。
    • 设计师们经常在进行设计树探索的早期就例行地采用简单估算量。

当然,这样做的危险在于,粗略的估算有可能会将本来可行但由于某个特定的估算量所采用的估算方法将看上去不可行的分支剪掉。

必要条件及其权重在持续变化

在对权衡的沉思中,一种关千整体设计问题的新理解逐渐浮现,即它是诸多因素以错综复杂、彼此牵制而又彼此交互的方式组合的结果。由此,对于诸项必要条件的权重计算方法就发生了变化。客户方(如果有)也逐渐地接受了这种理解,以此为出发点来形成对他将得到的成果的期望以及他将如何使用这个成果的预见。

大量的必要条件和约束条件被变更和改进。加工工艺也会有演进的过程,这对千计算机设计而言就是老生常谈的事了。

由于许多必要条件(如速度)是以性价比为权重的,这就会导致另一种现象的发生。随着设计向前推进,人们会发现,在只需负担极少的边际成本的前提下,就可以增加某些特定的有用性的机会。在此情形下,在原始的必要条件清单中根本不存在的项目就会被添加进来,而这往往会使在其后的设计变更中要求保留的预算余地被挤占。

约束在持续变化

即使设计目标固定而且已知,所有的必要条件皆已枚举清楚,设计树已经刻画精确,并且有用性函数也有着明确无误的定义,设计过程仍然会是迭代的,因为约束在持续变化。

并非所有的约束变化都是增长型的。约束也经常消弹千无形。如果这种约束变化是偶发的,而不是人为的,熟练的设计师就能利用这样的新机遇,发挥其设计的灵活性,以绕过该约束。

并非所有的设计都有灵活性。更为常见的是,当我们深入一个设计过程时,就意识不到原来某个约束已经消失不见,也想不起来因该约束而之前已排除的设计备选方案了。

重要的是要在设计过程的一开始就明确地列出已知的约束,作为架构师所谓的设计任务书的组成部分。设计任务书是一个文档,需要与客户共同完成,它规定了目标、必要条件以及约束。本书的网站给出了一个设计任务书的示例。设计任务书和正式需求描述文档不是一回事,后者通常是具有合同约束力的、定义某个设计方案的可接受标准的文档。将约束明确列出,是把丑话说在前面,这就可以避免日后突然爆发令人不快的局面。这同时也是在设计师的脑海中烙下对千这些约束的印象,从根本上提高当某一约束消失时被设计师发现的可能性。

我们都是围绕着约束来做设计的,该过程要求对千设计空间中少有人问津的特角旮旯有着创新和探索的精神。这是设计之趣之所在,这也是大多设计之难之所在。

对理性模型的其他批评

  • 理性模型是一种自然的思维模型。
    • 理性模型,如上所述、如上所评,似乎看上去相当幼稚。但它是人们能够自然而然地想到的一种思维模型。其思维自然程度可以从Simon版本、瀑布模型版本以及Pahl和Beitz版本分别独立地提出而得到强烈的印证。然而,从最早的时候开始,设计界就有了对千理性模型有说服力的批评。
  • 设计师们根本不那样做事。
    • 也许对理性模型最具解构性的批评一尽管也许亦是最难以证明的一就是经验最丰富的设计师根本不那样做事。虽然已经发表出来的批评偶尔才会有“皇帝没有穿衣服!”这样指出该模型并未反映出专业实践做法的呛声,但是人们还是可以感觉到不厌精细的分析背后的这种压倒性的主张。
  • Royce对千瀑布模型的批评
    • 尽管在毗邻方块之间有反向箭头表示逆向的工作流,但是该模型仍然行不通。不过,他的对策仅仅是采取了容许逆向工作流箭头指回两个前向方块的模型。治标不治本。
  • 专业知识和现实世界的要求之间有着一道鸿沟
    • 如果这种所谓的技术化理性模型未能考虑到实践能力的“发散“情景,用了还不如不用。

对于设计活动的实证研究经常会发现,“有直感力的“设计能力是最有成效的,而且与设计的内漂性质最密切相关的。不过,设计理论的有些方面就是企图针对设计行为开发出反直觉的模型和方案来。

尽管存在诸多缺陷和批评,理性模型依然顽固存在

通常来讲,某种理论或技术的原始创意提出人都比后继的追随者更了解其作用、局限性及其正确的应用范围。由千天资有限、热忱有余,他们的一腔热情却导致了思维僵化、应用偏差和过分简化等。

在软件工程领域, 我们仍然太过盲从瀑布模型一一理性模型在我们领域的衍生品。

那又如何?我们的设计过程模型真的那么事关紧要吗

理性模型,无论以何种面目出现,都会导向一种先验的设计需求描述。它导致我们盲目相信这种需求真的是可以预先制订的。它也导致我们在对千项目一无所知的基础之上就彼此签订了合同。一种更加现实的过程模型将使得设计工作更富效率,井省却许多客户纠纷和返工问题。

瀑布模型是错误的、有害的,我们必须摒弃它。

需求、罪念以及合同

  • 一个正式的设计过程模型是必需的,目的是帮助组织设计工作、辅助项目内部以及与项目相关的沟通工作,亦有益千教学。
  • 给予设计过程模式以可视化的儿何表示至关重要,因为设计师们都擅长空间思维。他们最乐千学习、思考、分享和讨论有着明确儿何图像的模型。
  • 对工程师来说,设计的理性模型是自然而然的。的确,有人多次独立地、正式地阐述过。
  • 线性的按部就班的理性模型具有很大的误导性,它不能反映出设计师的真实工作,或者一流的设计思想家所认定的设计过程的本质。
  • 坏的模型流毒甚广。它会导致需求过早固定,从而导致过度膨胀的产品,以及灾难性的日程表、预算和性能。
  • 理性模型在实践中一直存在,尽管它有种种不足,而且对它早有大量批判。这是因为它具有诱人的逻辑简单性,也是因为构建者和客户之间需要“合同”。
  • 已经出现多个其他过程模型,我发现Boehm的螺旋模型最有前途。我们必须持续对它进行研发。

抵制需求膨胀和蠕变

在IBM OS/360的研发过程中,其需求是由来自市场部的一个大型委员会初步定的。身为项目经理,我不得不将这份需求文档断然拒绝,因为它完全不切实际,并且没有足够的架构师、市场一线人员和实现人员来组成工作组以获取项目本质(核心需求)。

  • 对千需求蠕变而言,无论是来自用户还是来自内部组员的压力,进度的紧迫性在过去往往是最好的挡箭牌。
  • 将需求蠕变作为头等大事来抓,是对付它的最有效办法。该委员会给出的第一优先的建议是:及早任命手腕强硬、经验丰富、领域知识到位的经理,并要求他们在整个初始系统交付期间全程参与。尔后,授权他们“以其认为必要的方式度身定制标准流程和步骤”。
    • 他们还敦促应用盄求追踪矩阵以确保每一个被细化、定义和列出的需求都的确是从一个或多个初始的总体需求中派生出来的一一确保它不是从某个用户代表的要求或者设计师的愿望出发而悄悄混入的,其目的则是保证结果炉火纯青、推陈出新并深孚众望。

在为新系统进行的重点技术开发开始之前, 组织良好的系统工程工作就应该开始着手进行了。并不建议初始需求规格在首个阶段里程碑之前就完成,而是在系统开发的过程中,在首个和第二个阶段里程碑之间,完成详细需求之初始表达的定义。

在首个阶段里程碑中明确的主要性能参数,以及在笫二个阶段里程碑整理的需求中定义的且经受住了头几个阶段运营考验的部分,对于实现研发阶段的高效率是至关重要的参考依据。

罪念

人类是堕落了,所以我们无法信任彼此的动机。同样因为人类的堕落,我们也无法保证沟通的到位。

合同

显然,无论是在某个组织内部还是多个组织之间,迫使目标、需求和约束在过早的阶段就确定下来是合同的要素。 每个人都清楚一个事实,那就是所有(在合同里写的)的事项在晚些时候肯定会发生变化。(这将为不良行为打开方便之门:“在合同上先让一步,等到有需求变更的时候再狠狠地抬价”。) 所以,貌似是合同的这种要素最好地解释了何以瀑布模型会在设计和构建复杂系统时能如此持久地存在。

一种合同模型

  • 客户为建筑开发一个方案,而非撰写一个规格说明书。
  • 他和建筑师签承包合同,通常按小时或完成百分比计费,用来购买他的服务,而非指定的产品。
  • 建筑师从他的客户、用户以及其他的利益相关者处探访而得出一个更完备的方案,而这个方案仍然不会落实成一个严格执行的、能在合同上写成白纸黑字的产品规格说明书。
  • 建筑师完成一个概念设计,用以估算方案的平衡点以及在预算、工期和建筑规范等诸方面的约束。这可以作为首个原型,可以让各个利益相关者能够对它在概念层面上进行验证评估。
  • 经过儿次迭代以后,建筑师就会着手进行设计研发,通常这一步会产生更加详细的图纸、3D的缩小比例模型、实物模型,诸如此类。再经过利益相关者方面的若干次迭代,建筑师将做出施工图纸和规格说明书。
  • 客户采用这些图纸和规格说明书,为最终产品签订固定价格合同。

注意,这种长期演化模型是如何将关于设计的合同和关千施工的合同分离开来的。就算两个合同是在同一组织内实施的,把设计和施工分离开来,也有助千将责任归属梳理明白。

当然,这个模型也并非是完全按部就班的。实际的施工问题以及无论是由千针对需要或设计的评估引发的后期客户变更都会导致设计变更,而频繁的施工变更又反过来要求人们不断地变更合同内容。

  • “客户—建筑师—承包商”之间存在紧密的信任关系;
  • 设计中的问题都是众所周知的;
  • 工期很紧并且压力较大, 所以风险较高也是可以理解的。

其正常流程往往被整合为并行执行的、流水线式的设计-构建过程。建筑师会重新组织他们的工作,所以设计图纸中承包商需要的相关部分会首先做出来,包括需要大的提前最的钢材、现场作业、地基。

那些需要满足逐项列出条件的系统工程,也类似地需要能够在“设计-构建“过程的基础之上进行。这里的主要挑战在千让计算机和软件制造商们识别出构造的顺序以及哪些组件需要大的提前量。

有哪些更好的设计过程模型

为什么要有一个占主导地位的模型

无论是设计师领域的实践者还是教育家,现在都十分迫切地需要知道以下问题的答案:

  • 如果理性模型真的是错误的;
  • 如果选用错误的模型真的很致命;
  • 这个错误的模型积重难返有其深层次的原因。

那么,有哪些更好的模型能够做到:

  • 强调设计需求的递进式探索和演化;
  • 能够令人印象深刻地可视化,从而使得模型可以被团队和利益相关者容易接受和理解;
  • 仍然可以在堕落的人类之间促进合同的达成?

瀑布模型的普遍存在使我明白了一个道理-是沟通的需求和学术指导的本性都意味着一个占主导地位的设计过程模型迟早会出现(暂且不谈对瀑布模型的诸多批评及其过分简化造成的损害)。总之,现在迫切需要的是采用一个具有更少误导性的模型作为替代品,而非只是为当前实践的现状再画蛇添足地弄出一个什么新模型。

共同演化模型

该模型描述如下:

看来,创新设计并不是先把问题固定下来,然后再寻找一个满意的解决方案。创新设计看起来更多的是将构造问题本身,以及寻找解法的思路这两者的研发和完善过程齐头并进,辅以分析、综合和评估过程在两个想象中的设计“空间”-问题空间和解空间一之间地不断迭代。Maher等(1996)提出的创新设计模型是基于设计过程中的问题空间和解空间的“共同演化”:问题空间和解空间是共同演化的,在此过程中信息在这两个空间之间流动.

共同演化模型

在这里使用演化一词并不是十分精确。只要是对于问题的理解,以及解法的研发在逐渐生成并正在进行评估,那么我们就说这个模型是演化模型。

截至目前,该模型尚未进行大量的后续研发工作,而且在它原始的构造形态中,并没有表示阶段里程碑和合同的节点。虽然该模型有它的闪光点,也比理性模型要好,但我并不认为它已经充分完整。

Raymond的集市模型

运作机理

在用户与生产者社区中,某个成员发现了一个需要,然后开发出一个模块来满足它,并将该模块作为礼物提供给他的同伴使用。

显然,人们编写新的模块以及修复缺陷是为了使他们可以做到想做的事。但他们又为什么将自己的工作成果分发出来呢?尤其是这么做将带来必要的测试、文档撰写以及发布等活动,这将致使人们去做大屉的额外工作。 原因就是,这样做带来的激励和回报就是在社区中的威望。

通常,多个模块以及对千同一个缺陷的多个修复会同时提供给社区。Raymond提出,这时市场机制(即使对千免费商品而言)会发挥作用。更好的工具、修复结果,会赢得更广泛的受众,而它的作者也会相应地赢得更高的威望。

模型优势

通过集市化过程生产出来的系统产品,一般在技术上优千那些由大教堂式过程中生产的同样产品。

  • 首先,从进化的视角来看,市场会选择拥有最佳设计的模块。
  • 其次,将一个新的模块同时放到数百个测试者那里,会更快地发现其中的缺陷,从而催生更加可靠的产品。
  • 最后,缺陷被修复得更好,因为市场化的选择机制同样作用千缺陷修复过程。

综上所述,集市过程是作为这样一个全新模型出现:它同时作用千产品构建和协同的过程,团队成员通过电子化手段彼此联络,天各一方、互不熟识。

什么时候可以采用集市模型

  • 集市模型的确是一种演化模型。较大的系统是通过增加组件的方式扩张的,每个组件满足一种由具有用户和设计师双重身份的人所发现的需要(如果你愿意也可以叫它需求)。
  • 这种“礼物-威望“经济学只能在有着其他收入以养活自己的人中间才行得通1换言之,给到社区使用的作为礼物的软件,其实是其他工作所带来的副产品,其他产品的收入用来支付”建造者—捐献者”的费用。
  • 由千许多这样生产出来的产品实际上是副产品,工具的数量就远比应用程序要多。产品也并不总是精雕细琢的,或经过充分调试的一它只要能够足以达成构建者所想要的目标即可。“市场”选择机制才是事实上的质址控制。
  • 尽管有关开源过程的“开放”和“自由”的文字早已是铺天盖地,但是整幢Linux大厦的建成却很难看做是只砖片瓦的随机堆砌一Linus Torvalds始终作为一个保持其概念完整性的关键首脑力量存在。此外,对千Linux来说,功能规格说明早已存在:这就是UNIX。同样重要的是,总体系统设计也是现成的。
  • 所有设计过程都共有的关键要素在于对用户的需要、希望和验收标准的发掘。用千Linux社区的集市模型所取得的突出成功,在我看来是"构建者同时也是用户”这个事实所导致的直接结果。他们的需求来自于他们自己和他们所从事的工作。他们所要求的必要条件、验收标准和鉴赏品味则本能地来自他们自身的经验。整个需求的决定是暗中完成的,因而也充满了只可意会的技巧。我强烈怀疑,如果构建者自己并不是用户,并且对千用户的需要只有间接经验,那么开源模型还能不能行得通。
  • 因此,大教堂式过程还是有市场的:仔细地做好架构,严格地控制过程,并且精心地做好测试。你难道会在构建新的国家航运控制系统时采用开源过程吗?

Boehm的螺旋模型

Boehm的螺旋模型

Boehm的螺旋模型

螺旋的形状当然表示的是过程。它将同一活动的连续反复彼此关联起来。这种几何形状很容易理解,而且令人印象深刻。该模型强调的是原型方法,它主张远在一个可以跑起来的原型成为可能之前,就从用户界面原型和用户测试起步。

该模型已经被广泛接受,它甚至被美国国防部的采购部门认可,并用千替代瀑布模型。它也经过了一些研发工作。

但是它仍然是以设计师和产品为中心,而非以用户和行为为中心。

建议通过以下的手段来加强模型中的螺旋:

  • 明确标注合同达成节点;
  • 增加有关什么可以写入合同的清晰规格说明;
  • 有哪些是必然事件;
  • 有哪些是明显的风险所在。
  • 风险管理是之后大部分工作的重点。

协作与远程协作

协作在本质上是好的吗

时至今日,团队设计才是现代标准,这样做有着充分的理由。危险就是产品丧失了概念完整性,这是一项非常严重的损失。所以现在的挑战是,在进行团队设计的同时实现概念完整性,而且实现协作的真正好处。

团队设计是现代标准

为什么工程设计从个人转向团队

  • 技术复杂性。
    • 这种对许多技术的详细窍门的爆炸式需求在一定程度上有所缓解,因为提供这种详细窍门的方式也令人吃惊地爆炸式增长:通过文档、有技能的人、分析软件,以及搜索引擎找到文档资料和可信的候选合作者。
  • 快速推向市场。
    • 经验法则表明,一类新产品中第一个推向市场的,可以合理地预期它会长期占据40%的市场份额,而其他份额由众多较小的竞争者来瓜分。
    • 为什么这种竞争时间压力比以前更大? 因为通信和市场的全球化意味着,任何地方的好想法现在都会传播得更快。

协作的成本

许多人手会让工作变得轻松-通常如此
但许多人手会让工作变得更多-总是如此

  • 分割成本。
    • 分割设计任务本身就是一项多出来的任务。简明扼要并且准确地定义子任务之间的接口就意味着大量工作,还要冒很大的风险。随着设计进行,这些接口不断需要解释,不论它记述得多么准确。理解上会产生分歧。定义上会存在不一致的地方,解读时会发生冲突。这些问题必须调解。
    • 为了简化制造,所有组件中的通用元件必须标准化,必须建立某种通用的设计风格。然后,这些分离的部分必须集成在一起-这是对接口一致性的最终测试。
  • 学习与教授成本。
    • 如果n个人协作进行一项设计,每个人都必须了解目标、愿望、约束条件、效用函数等方面的最新进展。这个小组必须对这些问题持有共同的看法,即要设计的是什么。根据粗略估计,如果一个人的设计工作包含两个部分(学习l和设计d),那么当这项工作由n人分担时,总体工作量不再是工作量= l + d,而至少是工作量= n l + d
    • 而且,具有远见和知识的人必须教授其他人,因此在教授时不能进行设计。希望专业化带来效率的人必须承担这些成本。
  • 设计中的沟通成本。
    • 在设计过程中,协作的设计师们必须确保他们的部件能够组装在一起。这要求他们之间有结构化的沟通。
  • 变更控制。
    • 必须准备好一种变更控制机制,这样每个设计师所做的变更只有两种情况:
      • 只影响他自己的部分
      • 已经与影响到的其他部分的设计者进行了协商。
    • 因为设计的许多成本实际上是修改和返工,所以变更控制的成本很显著。没有正式变更控制的代价会更大。

挑战在千保持概念完整性

我们所认为的设计中的优雅实际上在很大程度上是指完整性,即概念的一致性。

如何在团队设计中获得概念完整性

在团队设计中,确保概念完整性最重要的方式就是授权给一名系统架构师。此人必须在相关的技术领域具有能力。他必须对要设计的这类系统拥有经验。最重要的是,他必须对系统的特点和目的具有清晰的愿景,必须真正关心系统的概念完整性。

协作何时有帮助

  • 确定利益相关人的需求和愿望
    • 在研究未满足的需求或取代已有的系统时,一个小团队比单个人要好得多。常,几个人会思考许多不同类型的不同问题。许多问题意味着许多没想到的答案。协作的团队必须确保每个成员都有充分的机会来探索他自己好奇的问题。
    • 建立目标。
      • 在任何设计过程中,设计师开始都会与一些利益相关人谈话。这些谈话的内容是这项设计的目标和约束条件。最难的任务是弄清楚隐含的目标和约束条件,即利益相关人自己甚至都没有意识到的那些目标和约束条件。
      • 这个阶段的关键部分是观察用户今天完成工作的方式、使用的工具和所处的环境。用视频记录下这些观察,并一遍又一遍地观看,常常会有所帮助。在这个阶段,让协作的设计师参与是极为有用的。其他的人会:
        • 问不同的问题,
        • 发现不同的、没有说过的事情,
        • 对事情的说法有独立的或相反的看法;
        • 观察工作的不同方面
        • 促进对视频的讨论。
  • 概念探索–激进的可选方案
    • 头脑风暴。
      • 这个阶段的标准规则是“关注数量”、“不要批评”、“鼓励发散思维”、”组合并改进想法”和“勾画出所有想法让大家能看到“。更多的人意味着更多的想法。更多的人彼此刺激,可以产生更多的想法。
    • 竞争是另一种协作。
      • 在概念探索阶段,人们可以通过举行设计竞赛来利用并激发多名设计师的创造力。如果已知的约束和目标得到了具体的说明,同时仔细地去除了不必要的约束条件,这种方式就最有效。
    • 未计划的设计竞赛:产品斗争。
      • 许多产品斗争。它们有5步标准剧情:
        1. 两个团队互相不知道彼此的工作、要求、比较产品和目标市场的细节,但一致断定他们的产品之间不存在真正的重叠。两个团队都应该全速前进。
        2. 现实浮现,来自市场预测或者多疑的老板。
        3. 每个团队改变自己产品的设计,以迎合另一产品的市场,而不只是重叠的部分。
        4. 每个团队开始寻求客户、市场团队和产品预测者们的支持。
        5. 战斗发生了,直至某种强制执行力做出决定。
  • 设计评审
    • 要求多科目的小组评审。
      • 小组评审有人数上的优势,但特别的力量来自千多个科目的观点。评审团队应该比设计团队大很多。那些需要按设计建造的人、需要维护它的人、用户代表、将要销售它的人一都必须包含在内。
    • 利用图形展示。
      • 对千设计评审来说,最重要的辅助手段就是产品的普通模型。

对设计本身而言,协作何时无用

对千设计协作的幻想式概念。在计算机支持的协作工作文献中,加入了对协作设计的幻想方式。这没有什么问题,只是这种欺骗性的概念更多关注复杂的学术研究,而较少关注对协作有用的技术工具。

在这种幻想中,设计团队真实看到设计对象的模型,不论是一座房屋、一个机械部件、一艘潜艇、一张软件的白板图或是一段共享的文字。所有团队成员都会建议修改,通常是直接在模型上进行修改。其他人建议修订,讨论继续下去,设计就一点一点地形成了。

井非协作设计的方式。但这种幻想式概念并不是协作完成设计的真正方式,它与设计复查不同。

设计的每一部分在任何时候都有一个负责人。如果在这个过程中提出了一些不同的建议,但负责人没有接受,那么建议者通常会撤回建议,并完成一个可选的设计方案。然后再次召集会议,选择方案、融合方案或转向第三种设计方案。

在哪里进行设计控制?幻想式概念不能够产生设计,只能够改进设计。

协作设计的幻想式模型反映了对概念完整性明显的不关心。Jill在这里拍拍,Jim在那里推推,Jack在那边打个补丁。这很自然,这是协作,但这得到的是糟糕的设计。实际上,我们对这个过程非常了解,所以我们给了它一个带有蔑视的称谓:委员会设计(committeedesign)。如果协作工具的设计目标是为了鼓励委员会设计,那么它们弊大千利。

概念设计尤其不应该多人协作

一旦探索阶段完成,并且选定了基本主题之后,接下去概念完整性就要主导一切了。设计只能是源自一名主设计师,设计团队只能是支持,而决不能分解他的设计。

的确,用这种方式去追求概念设计的话,有可能会走入死胡同。如果真出现这种情况,那就必须选择另一种基本方案,在这种新的方案选定以后,各项协作探索工作就可以再次有序开展了。

两人团队很神奇

前面讨论的设计协作讲的是超过两个人的团队。两人团队是特例。即使在概念设计阶段,在概念完整性最重要的时候,齐心协力的结对设计师要比单个设计师更有效。结对编程的文献表明,在详细设计的时候是这样的。通常开始的生产效率不如两个人独立工作,但错误率会大幅降低。既然许多设计中40%的工作是返工,那么实际生产效率就提高了,产品会更加健壮。

对千计算机科学家意味着什么

真实团队设计的一些关键特点:

  • 真实的设计总是比我们想象的更复杂。
    • 真实的设计有着更复杂的目标和更复杂的约束条件要满足,对千满意程度的测量也更复杂。真实的设计总是爆发出无数的细节。
  • 真实的团队设计总是需要一个设计变更控制过程,以免我们左手弄坏右手创造的东西。
  • 无论多少协作都不能消除对“枯燥无味的劳作和孤独的思考“的需要。

在遇到并非基千真实经验和真实设计应用的论文时,我们的期刊应该非常小心,慎重接受。

远程协作

为什么要远程协作

  • 专业化
    • 现在技能的过度专业化导致了许多协作。
    • 对于住在哪里, 人们有强烈的偏好, 这种偏好甚至是最重要的。
  • 整天工作不停
    • 地球的自转让工作能够整天不停地推进, 团队的各个成员交替地在白天工作。
  • 成本
    • 生活成本和生活标准的不一致, 使得人们通过外包能够以极低的成本获得通用的高科技技能。
  • 政策
    • 政府支持的大型跨国公司不可避免地涉及在不同国家分派工作的问题, 因此工作地点也不一样。

就地取材

除了成千上万的电话和文档之外, 许多双边的面对面会议将这些实验室联系在一起。每年举行持续两周的全部团队成员会议, 解决悬而未决的冲突和挑战-每次会议解决大约200个这样的问题。

我们的分布式开发工作是因为那些与往常一样的原因:

  • 分布在各地的技术专家
  • 不能移动的天才人员
  • 分公司之间的政策和工作的划分

这些努力取得了极大的成功。但是不要搞错:

  • 我们的工作是分布式开发出一件统一的产品!
  • 而且,分布式开发实际上制造了许多的额外工作!
  • 我们低估了同一地点的团队工作中,非正式沟通渠道的巨大重要性,这给我们带来了痛苦,直到后来我们感觉出缺少这方面沟通。空间障碍是真实的!
  • 时区障碍是真实的,有时候比空间障碍更真实!
  • 文化障碍是非常真实的,必须加以考虑!

让远程协作有效

  • 面对面的时间很重要
    • 人们直觉上知道面对面时间的价值。所以,尽管有强大的视频会议技术,飞机仍然运送着大量商务旅客。
  • 干净的接口
    • 在远程设计的组件之间定义干净的接口是很难的工作。这项工作不是定义好就结束了,事实证明,不断问答和解释定义的语义是必需的,必须进行变更、控制变更和充分沟通。

远程协作的技术

  • 低技术常常已经足够
    • 文档。
      • 对远程协作来说,最有力的技术就是文档共享,不论是通过网络还是通过邮递。正式的文章和正式的绘图带来了准确性,督促学习,鼓励批评,激发互动。
    • 电话。
      • 文档之后就是电话,这是比电子邮件更大的突破。电子邮件用户知道它的危害,它是仓促的文字,没有语音语调的变化,没有立即的反馈。即时消息是电话的糟糕替代品。
    • 电话加上共享文档。
      • 电话加上共享文档比单独使用其中一项要强大得多。这种组合加上实时交互,可以节约了许多书面的解释,也消除了许多误解。不太容易注意的是,共享文档为电话交谈添加了许多规范和细节。必须逐字逐句地达成一致意见,这迫使大家共同面对许多问题,而在其他情况下这些问题可能会遗漏。
  • 视频会议
    • 既然现在能够提供正常的帧数, 什么样的技术优势能让体验变得更好呢?
      • 视野。
      • 更好地共享文档和演示。
      • 更好的分辨率。
      • 更好的深度暗示。
    • 何时视频会议最有价值?
      • 在面试陌生的应聘者, 选择最终人选时;
      • 在问题对一个或多个参与者来说至关重要时;
      • 当一方参与者非常不安全时;
      • 当组织文化或国家文化非常不同时。
    • 高科技视频会议。

设计面面观

设计中的理性主义与实证主义之争

理性主义与实证主义

  • 理性主义者认为,人类天生具有良好的判断能力,即使偶尔会犯一些错误,也可以通过教育来进行完善。只要有良好的教育,成熟的经验以及足够多的仔细思考,设计者完全有可能创造出完美无瑕的作品。因此,设计方法学最主要的任务将归结千如何才能学会让设计变得完美无瑕。
  • 而实证主义者则认为,人类的种种缺点是与生俱来的,这将导致他们不断犯错。人类所做的任何事情都将不可避免地烙上错误的印记。因此,设计方法学的主要任务是学会如何在实践中找出缺陷,从而在下一次迭代中提升设计的质垦。

软件设计

计算机程序究竟是否属千抽象意义上的数学对象呢?其正确性是否可证?对千这个问题,理性主义者认为答案是肯定的。

我是一个根深蒂固的实证主义者

问题的关键在千:我们如何才能采用正确的验证技术。如果程序的内核是安全而又正确的,那么因错误、漏洞以及来自别处的恶意攻击所造成的破坏也是可控的。证明程序的正确性是一个非常浩大的工程,其复杂性不亚千构建程序本身。没有任何证据能够表明程序最初的目标是正确的。

完全采用形式化的证明方式是不现实的,更极端的情况下,例如彻底摒弃系统化的验证,则可能适得其反,产生危险的后果。Mills采取了折中的方法,在采用了系统化方式的同时,又进行了非形式化的小组审查,就我个人观点而言,以这样的方式来讨论逻辑问题是个聪明而实用的选择。

其他设计领域中的理性主义、实证主义与正确性验证

在设计领域中, 除了软件工程之外, 可能都不会承担起正确性证明的责任, 不过他们还是通过大量的分析与模拟技术进行设计验证。

大量的经验总结都指向同一个结论:

设计过程将会出现越来越多的迭代。分析得越精密,就越能衡址出设计条件的满足程度以及设计约束的遵循程度。因此,对千特定目标的设计所进行验证也就变得更加单刀直入和不可或缺了。

不过我得指出,这些分析及模拟并没有侧重于目标本身的正确性,假定环境与真实环境之间的差距也很少被考虑在内。

人们是否可以仅仅通过足够的思考就能正确地设计出复杂对象呢?

很可惜,答案是否定的,测试与迭代过程都是不可或缺的。不过谨慎的思考对我们而言还是大有裨益的。

用户橾型–宁错勿淆

定义明确的用户模型和使用模型

有经验的设计师偏好千一开始就写下他们对用户的认识,用户的使用目的到底是什么,以及采取什么样的使用模式。聪明的设计师还会以同样方式写下他们不知道,但是可以假设的部门。如果不同的用户有着不同的应用需求,那么他们会清楚地计算出各自的权重,从而定义出最终的用户模型。

当假设的条件足够详细充分时,他们可以在早期的具体构思中有更为清晰的蓝本。事实上,随着设计的深入,这样的构思是迟早要进行的,趁早开始可以防患千未然。

到底有谁会真的在设计刚一开始就进行大量的额外工作?老实说,我也觉得只有非常少的人会这么做。根据我的长期观察和总结,理论上我们应该定义出更多更明确的用户及使用模型,但事实上现在我们做得还远远不够。如果真能做到这一点,那么设计的质量将有大的飞跃。

无论是应用程序模型还是用户模型,都直接源千现代设计学中几个奇怪的特性:由团队进行设计,井在设计时使用复杂的工具而不是简单的工具。

团队设计

所有的设计师都会自觉或不自觉地在脑海中构建出用户及用户模型,这是由千他们的职业习惯使然。团队设计则提出了一个全新的要求,那就是,整个团队将共享相同的用户模型以及使用模型。这就需要将模型和设定条件定义的非常明确。

通常情况下,很少有人会意识到这其实是一个很大的问题,因为大部分团队都想当然地认为,即使不经过交流,他们也能达成相同的意见。结果往往事与愿违,最终不得不任由企业领导对整个团队提出质疑甚至是责问。无可否认,团队中的每一位成员都是专家,他们都阅读过定义目标的文档。

但事情根本不会那么简单,每个人都或多或少有过使用类似系统的经验,也会因此先入为主地妄自揣测普通用户的需求。每个人也都接触过不同数最的应用程序,这方面的经验也会被套用到当前设计中的应用程序。如果整个团队不能制订出一套统一的、定义明确的设想,那么每一位设计师都会用自己固有的那套设计习惯。许多琐碎的细节,即使讨论过,最终也会变得各说各话,这么一来,根本无法保证概念完整性。

如果无法就使用模型的概念达成一致,团队设计将无可避免地出现分歧。

复杂设计。随着工具的复杂程度越来越高,定义明确的使用模型也显得更加不可或缺。更重要的是,设计越复杂,设计师就越难像相关领域的专家那样去承担用户的工作。此时,如果没有定义明确的模型,那就更加危险了。

如果实际情况难以预料,有什么对策

当设计师开始着手定义使用模型时,各种意想不到的麻烦接踵而至:他很快就会很郁闷地发现,未知的信息远比想象中的要多。要想将设计进行下去,设计师不得不询问一些细节问题,而这些问题原本是可以在很久以后才被提出的。

如果设计师下定决心,一定要定义出明确的使用模型,他该怎么办呢?

  • 猜猜看吧
    • 先解决那些看上去可以通过简单询问来获取答案的问题,一且列表上这些问题都解决之后,设计师就会开始自行猜测剩下的问题会有什么样的答案了。或者我们说的含蓄点,他会自行构造出一个完整的属性与值的集合,并且揣摩频率的分布情况,这样,就可以定义出完整的、清晰的以及可以共享的用户和使用模型了。
    • 请记住,清晰表达出来的猜测远胜于埋没在心里的假设。
    • 看似“天真”的举动,实际却带来了许多好处:
      • 猜测数值以及分布频率将迫使设计师更仔细地思考用户集合。
      • 写下数值及分布频率可以引发讨论。与创建新事物相比,评论总是更简单的,因此整个团队可以有更正确的输入信息。应该让所有的参与者都加入讨论,这样可以集思广益,原本各人脑中不同的设计理念此时将汇聚在一起。通常情况下,也会让人们发现原先没有意识到的问题。
      • 清晰地列举出所有可能的值和频率,有助千将最终的设计与用户集合对应起来。
      • 更重要的是,它还提出了以下这些非常关键的问题:哪些假设至关重要?重要程度有多深?这些对千灵敏度的分析而言,即便如蜡蜓点水般浅显,也同样会非常有价值。不过,当具体的猜测事关重大时,使用更多资源来进行更精确的估算将会取得事半功倍的效果。
      • 最后,许多假设都充满争议,同时也根本经不起推敲。主设计师必须拥有驾驭整个团队的能力,同时他还要能够向其他成员充分传达自己的意图。
  • 宁错勿淆
    • 即使是错误的假设也远胜千那些含糊不清的假设。起码错误的假设可以通过质疑来得到纠正,而含糊不清的假设则不会。

英寸、盎司、比特与美元–预算资源

何谓预算资源

如果想要让设计,尤其是团队设计,能够具备完善的概念性,设计师们必须清晰地定义出哪些资源是稀缺的,井公平、公正、公开地跟踪其使用记录,同时严格控制其使用情况。

钱不是万能的

同一种资源也会有不同风格,甚至有替代品

在设计项目中,即使成本确实成为预算中至关重要的一个环节,设计师们还是应该仔细考虑成本的多样性。

许多情况下,设计者会使用金钱的替代品作为需要列入预算的资源。

替代品有很多好处:它们通常更简单。人们可以在知晓性价比之前就用它们来进行设计。它们也更稳定,即使性价比可能产生变化,使用相同的替代品总是可以充分利用已有的设计经验。

预算资源井非一成不变

随着技术的革新,有时关键资源也会由此而变化。

在设计的中途, 预算资源同样可能发生变化, 那是因为我们会不断变得聪明起来。

那我们究竟该怎么办

  • 定义清晰
    • 在刚开始的时候,项目经理第一件要做的事情,通常就是列举出所有目标以及约束。紧接着就是清晰地定义出哪些将成为预算资源。
    • 请注意,根据我们先前已经讨论过的情况来看,这通常会是设计本身的某种资源,而非设计过程的某种资源。
      • 例如,技能分配对设计项目来说至关重要,但它本身却并不是设计的一项属性。
    • 与之相反,项目进度表可能也是非常关键的,但一般情况下它是项目的一项属性,而不是设计产生的成果。
  • 公开跟踪信息
    • 整个团队都必须时刻了解核心资源当前的预算状况。
  • 严格进行控制
    • 无论核心资源是什么,团队领导都应该保留一小部分以供可持续发展,就像将军们在打仗时总会保留一些预备队,随着战事的进行将他们投入最激烈的战场。
    • 还有一点也是非常关键的,那就是只有一个人能够拥有预算的控制权与调整权。

约束是友非敌

约束

无须讳言,约束自然是一种负担,但同样也是我们的朋友。约束会压缩可供设计者探索的空间。这样做,可以让设计者变得更为专注并加快设计速度。

去除了所有的约束之后,“设计“任务通常会变得更加困难,而非更加简单。

约束不仅仅压缩了可供探索的空间,它们同样对设计者提出了挑战,这往往是一个创新的契机。

归结千一点

在设计任务中,人为的约束很容易就会放宽。理想状态下,约束会促使设计师去探索未知的角落,从而催生一些新的创意。不过实际上,任何约束集合也有可能起到相反作用,将设计师逼入死胡同,使得他们在设计方面束手无策。

因此,我们必须谨慎地区别:

  • 真正意义上的约束;
  • 曾经真实存在,但现在已经过时的约束;
  • 被误认为是真实的约束;
  • 可以制造出的人为约束。

当你开始设计时,请时刻牢记,某些东西只是设计过程中需要的资源,而非设计的成果。

有时实现方法本身成为一种约束,那么一些更好的解决方法将被排除在外。为了产品和用户的利益,请对这些不合理的约束奋起反抗吧!

设计悖论:通用产品比专用产品更难设计

从整体上来看,如果人们更崇尚完美主义,那么后面那种设计更为合适。任何设计过程都起源千设计师对目标与约束的分析和具体化。首要任务便是缩小设计空间。在目标确定之后,约束越多,这个任务的完成程度也就越高。

既然约束对千设计者来说是友非敌,那么如果一开始设计任务看上去并没有明显的约束,我们就该仔细考虑下到底需要什么样的用户和用例模型了。这样做,我们有很大儿率可以找出一些约束,这对设计者和用户来说, 都是一个好消息。

技术设计中的美学与风格

技术设计中的美学

我们的语言系统足以通过许多方式让我们理解这种感受–当不经意间提到“优雅“的程序时,受众肯定能够理解其中的含义。

揭开逻辑之美的面纱

  • 简约
    • 简约乃优雅之本。
    • 花开两朵,各表一枝。
      • 在简约之外,还有其他重要因素。
      • 所谓的”一行代码“能实现的功能令人叹为观止。但是,我必须再次强调,这又变成了无聊的字谜游戏,而不是优雅的设计。编程语言之所以存在,正是因为它们能够减轻编写和阅读时的工作量,而不是去制造一个又一个谜团。
  • 清晰的结构
    • 简约并非一切。
      • 人们同样要求语言或者计算机架构具备一定的直观性。人们“想表达什么”和“如何表达”之间,应该有一条清晰的脉络。人类的自然语言可以满足所有的真实交流需求,不过它远远谈不上“简约”二字。
    • 结构。
      • 技术设计中的“优雅“要求基本的结构必须一目了然,另外,如果逻辑上并不那么直观,那么其结构还必须易千讲解。
    • 比喻。
      • “优雅”及可读性都能通过人们所熟知的比喻得到增强,尤其是在设计用户接口时。
  • 什么才算是好的计算机架构
    • 一致性在质最评价体系中是至高无上的。一个良好的架构应该是始终如一的,只要知晓了系统的一部分信息,那么剩余的那些也应该可以顺势推导出来。
    • 不过,真正的一致性解决方案并不是那么容易设计出来的。对千计算机架构而言,常用的标准有以下几条:
      • 系统的说明必须简明扼要,
      • 代码构建必须简单明了,
      • 对不同的实现版本要有兼容性。
    • 衍生出的准则。从一致性出发,可以衍生出三条重要的设计准则:正交性、专用性及普适性。
      • 正交性:不将无关事物耦合起来。当具有正交性的功能发生变化时,集合中的其他任意功能都应该维持原状。
      • 专用性:和无关事物保持距离。恰好可以满足需求的功能可以称为“专用的”功能。
      • 普适性:不要限制天马行空的思维。具有普适性的功能可以同时适应不同场合。它和设计者的自身专业素养紧密结合,他们通常确信用户的需求不可能超越设计者的思维,因此,用户的真实需求可能会因为他们的能力限制而被曲解。设计者应该避免将功能限制在自己划定的牢笼之内。当设计者力不能及时,就干脆放手让它自由翱翔吧。
        • 常见的实现普适性的方式包括以下几种:
          • 预留一定的扩充余地(留待将来开发),
          • 完整的功能集合,
          • 解除功能间的耦合,
          • 保持正交性以及使用组件技术。
  • 保持一致性带来的更多好处
    • 保持一致性可以让我们变得更为强大,也更加善千自我提高,因为它可以极好地锻炼我们的思维能力。除此之外,它还能让我们在易用性和易学性之间鱼与熊掌兼得。
    • 易学性要求架构简单明了,而易用性却恰好相反,要求架构复杂,正如定点运算和浮点运算的差别那样。当设计者某天领悟到其实定点运算是浮点运算的一个特例时,他对千架构的理解自然而然就会更上一层楼。

技术设计中的风格

有了风格,我们才有足够的动力去追求情趣。风格中有两个部分会影响到情趣的一致性以及自身固有的内涵。

之前我曾经说过,设计中最重要的属性莫过于概念的完整性。亳无疑问,设计中最关键的完整性来自千整体结构,它是支撑起设计的骨架。不过,细节上的一致性同样不容忽视,它是覆盖在设计表面的皮囊。

一个能够被完整应用的风格可以称为”组件”,即便对产品的概念完整性来说,它只是一件华丽的“外衣”。它不仅仅提升了情趣,还让设计更容易被人理斛。与之相辅相成的是,这又简化了最初的学习和使用,即使搁置一段时间,很快也能被重拾起来,在可维护性及可扩展性方面,它同样大有裨益。

无论对于什么样的流派,风格都具有无可取代的地位。

何谓风格

  • 细节特征。
    • 即使是同一位画家,其不同作品所对应的主题也是不同的,作曲的主题及流派亦是如此,但是它们却拥有统一的风格。
  • 异想天开:脑力劳动最省化。
    • 所有的设计及创造都需要巨量的微观决策。人们总是希望卸下抉择所带来的重负以减轻脑力劳动。如果说这是人类天性的话,那么它自然会影响到我们的创造活动。如果没有特别原因,那么我们每次碰到同样情况时都会做出相同决策。这些微观的决策能够表明我们工作本身的特质,从而让我们拥有识别能力。
  • 微观决策的一致性。
    • 人们总是希望微观决策不仅在时间维度上保持一致,同时它也能适用千一系列相似的情况。在相同的因素中,我们应该具有同样的思维方式,并以一致的方式其衡量它们。
    • Frank Lloyd Wright倾向千在装溃中使用直线型元素而非曲线型。而Seymour Cray则在他早期的计算机框架中将性能看得比兼容性更为重要。
  • 风格的清晰度。
    • 如果设计师在宏观和微观范围内保持了相当程度的一致性,那么我们就可以说其风格是清晰的,也就是说,可以用非常简洁的语言来进行描述。在同类事物中,它是如此特别,我们可以一眼就认出它来。

风格是一种不同的可重复的微观决策集合,即使所处的环境不同,但决策制定的方式是保持不变的。

再补充一点:微观决策的制定取决于相应的方式。

风格的特点

无论设计的媒介如何, 风格的特点总是相通的。

难以捉摸。想要清晰地定义出风格需要大量的文字说明。

  • 结构清晰。
    • 任何一种风格的表现形式(无论是显式还是隐式),都具有与生俱来的结构性。
  • 与时俱进。
    • 即使只是个体的风格,也会保持与时俱进。
    • 真正的鉴赏家可以轻松分辨出Turner早期作品和晚期作品之间的区别。

若要使风格保持一致,请将它写成文档

设计风格是通过一系列微观决策来制定的。一个清晰的风格必然会反衬出这个系列的一致性。理论上说,一个清晰的风格未必是良好的,但一个混乱的风格则一定不行。

毋庸置疑,无论是工程图纸、设计蓝图还是用户手册,设计团队必须用合适的方法将设计风格记录下来。他们还得时刻思索设计者的意图,这样才能让此后的维护人员不漏掉任何重要的内容。这样的最终产品才是优秀的。在维护阶段,团队还是得继续保持概念完整性,将影响最终设计的那些微观决策记录下来。

如何形成良好的风格

要有简洁清晰的观点;要有直截了当的方法;要有坚持不懈的精神。

  • 他山之石,可以攻玉。
    • 请尝试一下别的风格。这会促进设计者进行更为续密和详细的思考。
  • 公正地评价。
    • 客观地指出你所偏爱的风格以及喜欢它的原因,到底喜欢它们哪一些方面以及原因。
  • 实践,实践,再实践。
  • 修正和提高。
    • 找出并修正风格中的不统一之处。
  • 谨慎选择设计师。
    • 请为你的产品选择那些具有清晰风格并有较高品味的设计师。哪些设计师具有这样的资质?这可以从他们已有的设计作品中看出端倪。

一套计算机科学家梦寐以求的房屋设计系统

卓越的设计师

设计空间之旅:案例研究


以上总结来源于《设计原本》

Search

    Post Directory