12 章节10: 尽快获取成果
雷欧雷欧 保存 显示目录
随着开发组的研发方向越发明朗,他们开始探索构成项目的任务。在这个早期阶段不涉及整体规划是很重要的,这个工作应该留在最后完成。如果开发组已经完成了许多任务却没有一个「成果」可以点击测试,那么就很难直观地感受到项目有所进展。开发组完全有可能做了大量的工作,但是这些工作却无法组成一件「成果」,这会让他们非常地缺少安全感。
因此,他们在开工第一周前后就应该尽可能地做出一些具体的、可演示的成果。要实现这个目的,就不能把任务平摊开来完成,而需要深入其中的一部分,将它吃透。
合二为一
我们可以将项目分为两个层面:前端与后端、设计与代码。虽然从技术层面来说还应该有更多的分层,但是在大多数项目的主要挑战都集中在这两个分层中。
试想我们的项目从一大堆的设计开始,成员们可以设计各种各样的页面,甚至将它们具体到模版或者图像了,但是除非将它们和后端关联上,不然什么效果都无法展示,项目仍然停留在假设和虚构的阶段。
后端也是如此,即使有许多任务都可以勾选完成了,但是如果没有用户操作界面,这些任务的价值就无从体现。不将代码和前端设计结合起来,我们是无法测试逻辑是否正确的。
我们真正需要做的,是选取项目的一部分进行集成,在集成后,小组才会得到真正的成果来验证开发的内容是否是令人满意的的(如果是不过管的就需要重新去思考)。任何人都应该可以点击它、体验它,来确定它是否契合我们的设计初衷。
案例分析:项目访客
我们在 Basecamp3 中开发了一个新功能——允许用户邀请访客进入他们的项目,并且可以分享选中的文档、信息、任务清单给访客。我们在「安利」中对这个功能的开发确定了几处需要调整的部分:
- 访问入口:在开发这个功能前,Basecamp 只有「全部内容可见」与「全部内容不可见」两个状态。我们需要设计出一个方案来邀请一些成员,并且只允许他们看到项目的一部分,要实现这一点,需要对后端和缓存都做出调整。
- 访客管理:我们需要添加一个方式来邀请访客进入到项目中,并且能够不影响团队成员,独立地管理访客。
- 访问权限开关:项目中的每一部分内容都应该有个权限开关来设定是否向访客进行展示。
负责这个项目的开发组由一名设计师和一名程序员组成。他们研究了现有的代码后明确了他们的工作方向,设计师选择了权限开关作为最适合的优先切入点,这是项目中用户操作界面最核心的部分,也是在演示视频和用户操作中最高频的部分。
设计师不需要做出细化到像素级的完美模型,只需要在应用的 HTML 模版上测试了多种不同的交互方式和布局方案,比如权限开关应该是两个单选按键还是一个复选框,又或者是一个自定义按钮。
与此同时,程序员也没有浪费时间,他在「安利」中已经获得了足够的信息去着手调整访问模型。
当设计师明确了用户操作页面的调整方向后,就会通知程序员并向他简单地展示一下权限开关的设计。程序员也可以暂时暂缓访问模型的工作,转而对权限开关进行开发,他要让所有支持该功能的内容都显示出该开关,当用户在点击时就可以切换状态并记录到数据库中。
此时,权限开关实际上并没有真正地改变内容的访问权限,但是从体验的角度来看已经足够了。设计师可以点击它、测试它,并且测试它在临时服务器上处理真实数据效果如何。
此时的权限开关其实还有很多设计工作要做,但是程序员不需要继续参与了。随着交互视图的搭建,设计师可以继续测试复制操作、布局方案、显示的颜色、动态视图渲染等。而程序员也可以继续回到访问模型的开发或者其它更重要的工作中去。
大约在项目开始的三天后,设计师就可以向项目经理演示开关功能,他们可以进行沟通并对功能再进行数次调整,然后就可以将这个部分定义为「完成」了。这样,项目中一个核心部分就完成了设计、开发、演示、发布的流程。这种可以实实在在感受到的进展不仅会让开发组感到振奋,管理层也会和小组成员一样因为看到实际成果而更有信息。能越早地体验到交互设计,也就能越早地证明他们的设计是切实可行的。
这个简短的例子向大家例证了一个开发组应该如何在短时间内将项目的一个核心部分打造出「成果」。
不要浪费程序员的时间
核心的待调整部分应该在塑造过程中就被确定下来。所以在项目刚开始后,程序员不需要无所事事地等待设计的完成。虽然缺少前端设计让他们无法直接「完成」任何部分,但是「安利」中的信息应当足以让他们立刻开始处理后端问题。
精细化视图前的测试
程序员在进行开发前并不需要看到细化到像素级的设计图。他们只需要一些关键信息:输入元素、按键、存储数据显示的地方。这些交互内容是用户界面设计的核心。
关于字体、颜色、间距以及布局的问题可以在基本交互完成设计并且将前后端关联上以后再处理。我们要在一个浏览器或者设备上测试一个实际版本只需要内容复写、基础交互以及一些文本。有了这些,我们就可以先回答项目最根本的问题:这样做有用么?这个设计是否简洁明了?它的效果是否符合我们的期望?
当然,这也意味着设计师给程序员的第一个设计图看上去可能会非常的简陋,如下图所示。相较于一个视觉设计图或者一个精致的模型,它更像是一个面包板。
这个屏幕截图是来自于一个多日课程的注册应用,是由设计师用 HTML 手工制作而成的。这里几乎没有什么样式设计——只有足够多的视觉层级,但足以让人相信它能满足当前的使用需求以及未来的开发需求。
但这样一个看起来简陋的设计,其实是需要做出许多决策的。
- 产品询问的应该是到达时间而不是离开时间。这是对商业逻辑和价格模型进行了细致讨论后才决定的。
- 在到达时间的下拉菜单中,具体选项对应的是用餐和过夜留宿的收费规则。
- 设计师最初的草图中,到达和离开时间使用的是日历模式的日期选择器。但是这个设计在用户操作界面中遇到了问题。许多课程会持续很久(可达数周)并且分为多个阶段。标准的日历模式选择器在它的时间格中并没有空间来标注各个阶段。但是通过下拉菜单,在需要的时候,用户就可以利用选项组来标记日期组。这样用户就不需要在选择日期是还要另行参考日程表来确认。
这里还有一个案例,是一个通过访谈收集数据的应用,这里是其中最先开发的部分。
在这个早期版本中,项目名称(Basecamp)和访谈主题(Jan)都使用的是硬编码,并且基本都没有链接到其它地方。
这个设计实在是有够原始的。交互是浏览器默认的蓝紫色纯文本链接。包含了数据点的区域也几乎没有样式设计,仅仅是一个标准的黑框。粗糙归粗糙,这个设计已经可以对很多核心决策进行测试了。设计师在页面上方尽可能多地展示了数据,这样回顾访谈就变得很容易。但这里没有在用户界面各个部分都留出足够空间来添加、编辑、删除数据点。所以设计师还需要设计单独的页面来对每个部分的数据进行添加和编辑。
这是增加和编辑「拉」(该访谈中的一种数据类型)的最初设计。依旧是非常原始的设计。这里的设计仅够快速关联和测试功能。开发组的成员们可以通过点击这里来判断导航到一个独立的页面来记录数据是否是可行的。如果是可行的,他们可以在稍后布置更多的样式。如果这不可行,他们就不必浪费大量时间来细化这一版的视图了。
整洁漂亮、色彩以及排版这些内容在最初的测试中并不重要。虽然视觉样式在最后的成品中很重要,但在前期阶段则不然。开发中最大的不确定性在于它是否有效、是否吸引人以及开发难度有多大。在要素都关联起来后,我们还可以通过重新布局、重新设计样式以及重新绘制来优化这些已完成的工作。但是要先确定能用然后才能去追求美观。
恰到好处的后端程序
后段程序的开发也是如此,不要极端地追求要么全部完成要么就一点不动。有时候设计师只需要一些简单的开发内容——几个可以存储数据和代码的字段,以便于从一个根页面跳转到另一个。这样她就可以在模版中填充一组真实的数据来测试不同的展现方式(行、列、多媒体区等),从而找到最佳设计。
前期的后端工作可能是不完整的,可能连模型都没有,仅用一个控制器来展示模版。或者只是一个控制器和携带了模拟数据的部分模型,都不支持创建或者更新数据。但是至少尚未联通的页面可以通过它们之间的通路搭建在一起了。
当测试访谈应用的第一部分时,开发组清楚将会有来自真实访谈的敏感数据接入进来。他们需要建立一个认证体系来保护它。他们没有开发拥有用户名和密码体系的完整认证支持—甚至也没有接入第三方集成—他们只是采用了 HTTPAuth 来对密码进行硬编码。
这使得开发组在循环周期的前期就可以尝试添加来自真实访谈的数据,而不需要放慢速度去进行关联以验证代码,这些代码对于他们要解决的问题没有任何帮助。
关键在于设计与程序的工作要在产品同一部分来回转换。不要去一口吃成个胖子,而是在交互、代码、视觉样式间轮转处理。一步一步地推进,对于开发的功能要能实际测试以分析它的实现方式以及后续工作。
从中段切入
在上面的案例中,开发组并没有从登录系统下手。在找到如何录入访谈数据的解决方法前,他们并没有研究创建访谈项目和访谈题目的方法。而是直接切入到了最有趣的问题所在之处,并且全身心投入其中。
在这一点上,我们有三个标准来判断优先开发什么:
首先,它应当是核心内容。visibility toggle 是这个模型的核心。没有它,其他的工作都将毫无意义。将其与项目较外围的功能,比如重命名相比。两者都是「必须的」,但是其中一个更加的关键,需要在周期的前期就得到验证。在访谈应用中,记录访谈数据比新建一个访谈项目要更加核心——更加接近中心。
其次,它应该要精简。如果工作的第一部分就不够精简,那么将它从其它项目中分离出来就并没有什么优势了。进行分离的目的就是要快速的取得成果以鼓舞大家——可以实际体验的成果意味着研发的轨迹是正确的。
第三,它应该是新颖的。如果项目中有两个部分同样的重要且精简,那么不妨选择你从未做过的。在项目指派人这个功能中,用于添加指派人和用于添加普通成员的用户界面大致相同。如果从这里开始推进项目,开发组既不会学习到新的东西,也无法排出项目中的任何不确定因素。但若是能先解决 visibility toggle 的问题,就能证明新想法是可行的,这将会极大地激励组员们。