Skip to main content

“我们需要停止快速设计,学会减少设计。”

我们的心态需要从一次性做完全设计转变到进行小规模设计。那么,所谓小规模设计到底要怎样做呢?这篇文章来跟大家分析一下小规模的设计是什么样,它有什么好处呢?

为什么要做小规模设计

在讨论如何做之前,我们先谈谈为什么,为什么在设计、搭建和交付中小规模思维如此重要。这并不像人们想的那样,仅仅是为了让某些设计师和研究人员扫兴,他们出于某些原因喜欢对所设计的东西有一个整体的看法。

通过最小的设计来为客户或用户提供价值,可以给我们带来很多好处。首先,我们可以把一个有潜在价值的东西直接提供给某人,让他立即开始使用,而不是让他等待设计人员开发完其他几十个不相关的功能或更新。一般来说,只需非常小的变化或错误修复就可为用户产品体验带去巨大改善。

当然,有时候,设计上的变化可能不会带去任何影响,甚至是带去负面影响,这些缺陷我们越早发现越好。更频繁地运送小型成果,对我们理念和执行的反馈也能更高效地回输。

通过递交一个小规模版本,你能尽早预测未来会发生的大问题。想象一下,如果你早就知道某些功能鸡肋的表现,你根本就不会创建这些功能!想象一下,如果你不忙于搭建无人问津的庞大版本,你本可以向用户提供多少价值。尽早交付小型的设计,你就能及时获得相关信息,这些信息可以帮助你的团队对剩余的设计部分进行取舍。

通过把设计分解成可交付的小块,我们可以尽早且频繁地向用户提供价值,同时在投入大量资源之前及时获得反馈。这听起来真是美事一桩。

唯一的缺点是,小规模设计很难做得好,如果你做得不好,那还不如一口气把所有东西都设计完。

按理来说,小规模设计不应该比大规模设计难才对,但出于一些原因,许多设计师十分不擅长处理小规模设计思维。

首先,作为设计师,我们常常被教导要从整体上考虑产品和体验。这是件好事,因为我们得了解用户对产品的整个体验。事实上,大家都知道把东西分成几块来设计可能会导致不连贯和不一致的体验。

某位与我们交谈的设计师完美地解释了这一点。她的团队任务是为一个有不同类别内容的大型网站设计信息架构。工程师们想直接开始编写搜索内容的代码,但她觉得只提供一个类别的分类法是不妥的,因为她知道,一旦她评估了系统中其他类型的内容,工程师们会发现还有更多东西同样需要搜索。毕竟,你不会用搜索鞋子或汽车的标准来搜索书籍。她不希望得到一个不完整的模型,以后还得再做改进。

与我们交谈过的许多人都说,一旦设计进入市场,他们就很少有机会进行迭代和改进。当迭代和改进环节缺失时,设计者只能尽可能多地为初代版本添加细节。

当然,对于设计者来说,知道某项不完美的功能面世,且它永远不会被改进,这是非常痛苦的。毕竟这就是我们的工作。我们希望它是完美的。我们希望它能为人们解决问题。我们想让每一项作品都无愧于心。这些都是非常合理的反应。因此当我们确信完整版本会更好时,一般不会考虑交付小规模且不完整的设计。

小规模设计的意义在哪里

小不等于坏


Jobs4Pets.com上一项小型但重要的视图功能

我们经常把某项产品的初代版本称为MVP或最小可行产品。但是,人们往往忽略了”可行”两个字,而这恰恰是最重要的。当你创建一个新功能或产品的初代版本时,尽管规模再小,它也必须是可行的。它不应该存在问题,不应该无法使用,更不应该带去糟糕的用户体验。

请记住,我们进行小规模设计,并把它交付给用户,目的是为了了解关键信息。这就是生产最小可行产品的全部意义。如果我们推出了一个糟糕的、有缺陷的或无法使用的产品,我们所了解到的无非就是人们不喜欢这个糟糕的东西! 以及我们必须弄清楚,人们之所以不使用我们的新功能是因为它不对,还是因为它虽然功能完美,但可操作性太差,以至于没有人能够坚持使用。

小不等于无关功能的混杂

小规模设计、搭建和交付的另一个困难是,我们可能会倾向于一股脑交付大量的小功能,因为这些功能可以为快速构建,所以我们就先将它们做了。

思考一下,你正在构建一个让人们搜索和申请工作的界面。有很多东西需要你来完成,例如,你需要用户能从潜在雇主那里得到带有工作描述的招聘信息;你需要一个要求求职者提交他们个人信息的界面;你需要一个能让雇主审查申请的系统。你还可能会需要某种档案或账户页面,让流程双方都将信息存储进去,这样他们就不必在每次发布或申请工作时都重复输入信息。

上述所有大系统都包含多个小功能在里面。例如,申请系统可能包含暂停功能,求职者可以暂停申请,过一会再来完成。或者,发布系统可以让雇主在需要另雇他人时重新发布工作描述。

现在,作为设计师,你可能认为你需要一次性交付所有功能才能打造一个有力的招聘网站。但事实并非如此。你要做的是,确保你搭建各项功能时采用了正确的设计顺序。比方说,重新提交招聘信息的功能应该推到后面,在此之前,应当设计首次发布招聘信息的界面。同时,应该先设计出令人们查阅各种工作的方法,然后才轮到申请工作界面的开发。

每次你设计和发布的东西都应是有用的,而且应该以合理的方式出现在现有的界面上。

小但有用

最重要的是,你发布的任何东西都应该有益于目标用户。如果你有一个非常大的用户群,你的设计可能不会立即对每个人都有用,但它应该有一定的使用性,至少足以让你得到反馈,并在下一次迭代中完善版本。

对一个招聘网站来说,最小可行产品是什么?要想交付某版本以获得用户反馈,你能做的最小努力有多少?

如何进行小规模设计

小规模设计涉及很多技巧,下面这些技巧十分实用,且可操作性强,并且仍有发展的空间。例如:

理解目标

小规模设计最重要的部分就是理解你正在创建的功能或产品的核心目标。如果你的目标太大或者你对目标理解不透彻,就很容易因为 “有人可能需要它 “而继续增加一个又一个的功能。

例如前面提到的求职网站。如果它是一个普适型的招聘网站,那么你的设计将与针对专门行业的招聘网站有很大的不同。过于宽泛的目标会影响你的搜索选项、你期望显示的工作数量,以及对申请表格的要求等等。

锁定明确的目标用户,你就已经成功了一半。设计一个小型的、有针对性的功能或产品对你来说作用更大,所谓为 “所有人 “设计的大型功能,实际上对任何人都没多大用处。

做好一件事

假设你正为你的求职网站设计信息表。你可能想广泛地构思,试图了解雇主和求职者可能需要的所有不同的报告,然后把它们都设计出来。


Jobs4Pets.com的信息报告案例

花时间研究哪些报告形式最好用是完全合理的,但不妨考虑一次只设计和搭建一种,最好先做研究,找到那些价值最大化的报告形式。为什么要把时间消耗在搭建价值最小的报告形式上呢?这样反而浪费了用户时间。用户可能根本就不需要你手头搭建的那些逊色的报告形式。通过一次只设计和发布一种类型,你会得到更快的反馈,且能定期为用户提供价值。


一次仅设计和搭建一种类型有助于为你的用户提供最大的价值

这种设计思维不只适用于报告。如果你打算发布多种类似的产品,看看是否有可能仅从一个开始,到后期再逐渐增加。

不要从代码开始

设计一个新功能或产品的方式有很多,我们可能会在会议上花大量时间来争论最佳的方式。

理想情况下,我们可以搭建许多不同版本,然后看看哪个版本更受欢迎,但这导致了另一个问题:编程和代码成本不菲。另一方面,原型和实验法可是相当便宜。

与其直接跳到设计完整的功能,让工程师们立即开始工作,不如尝试设计实验。试试礼宾服务测试或绿野仙踪实验。建立一些交互式的原型,与用户一起测试。

没有规定说设计师只能设计像素般完美的界面,我们也可以成为实验设计师。

不要立即面向广大群体

设计师在向人们交付不完美或未完成的设计时,常常很在意的一件事情是,用户可能会感到失望。毕竟,推出半成品最终可能会对产品和公司产生非常不好的影响。

但向一小群用户提供内测产品就完全不一样了。在几十个甚至几百个用户身上测试新的设计,可以为团队提供巨大的价值,即发现关键的见解和潜在的问题,同时不会有让整个用户群失望的风险。

不要再古板地认为,推出新功能必须通过新闻发布和市场推广才能实现。虽然只是在几十个测试者或一些内部人员中提供内测版本,但你仍然在向用户提供价值。如果交付对象的规模较小,你对失败的担心会少很多;如果你先在较小的受众中测试了你的设计,你失败的可能性也会少很多。

接受不完美

除了上述技巧,团队还应学会接受不完美。事实是,世界上不存在完美的产品;此外,在多数情况下,我们甚至不知道什么是完美。显然,我们不应该向人们提供无法使用、有缺陷或不安全的软件。但是我们也不需要花几天或几周的时间去纠结每一个像素和每一点抛光,特别是在连这个功能是否有用都不确定的情况下。

想想看,我们到底把多少时间浪费在所谓华丽的设计上,而对应的产品甚至无人问津。比起纠结细枝末节的完美,如果把时间花在测试想法和找到人们真正想要使用的产品上,我们的收获会更多。

允许迭代

当然,如果你要接受不完美,最好也愿意进行迭代。我们接收到设计师在敏捷软件开发团队工作时最大的抱怨之一是,团队从不进行迭代。团队会非常努力地工作,争取快速交付,然后从不反思或改进功能。有时候部分团队甚至不测试产品效果。

如果你从不回头去改进(或扼杀)你不完美的功能,那么没有人会放心地发布他们认为可能不完美的东西。我们必须致力于向用户学习,不断改进已经投放在外的功能和产品,而不是不停地向用户输送无效产品及功能。

原文链接:https://www.interaction-design.org/literature/article/designing-the-smallest-possible-thing
翻译:马克笔设计留学
如果对于设计专业留学和作品集有任何疑问,可以随时和我们联系,微信:13718574833,知无不言言无不尽!

0 0 vote
Article Rating
订阅
提醒
guest
0 评论
Inline Feedbacks
View all comments