设计师不可能和工程师一样了解自己所设计的产品的每一个技术细节。
Pelin是一名设计师,她非常在意那些能让软件拥有愉悦使用感的小细节:屏幕之间的切换效果,报错后的恢复步骤,呈现动效的时机,修正文字的基准线,对齐列表视图的图标,iOS和Android系统保持一致的体验。她花了大量时间对设计进行组织和标注,然后花了几乎同等的时间和工程师一起查看这些细节,以便最终的代码实现能向用户精准传达她的设计意图。
她与Berk密切合作。Berk也同样希望自己的代码能按照设计师的意图交付工作。但是,Pelin和Berk发现,在这份分享给工程师的设计文档中,总会遗漏一些内容。Berk认为Pelin的细节标注非常有用,但他总是需要更多信息才能进行开发工作。这常常使设计和开发陷入无休无止的反复沟通中。
为了解决这个问题,Pelin、Berk以及另外两个创始人创立了Zeplin,一个为设计师和工程师提供软件即服务(SaaS)的协作平台。他们确信自己正在解决一个痛点,但他们希望这个工具能满足更多的工作流程。于是Pelin、Berk和其他Zeplin员工与世界各地的设计师与工程师进行访谈,以了解他们之间的协作方式。他们只问两个问题:“你如何在团队内分享设计?”以及“你如何与设计师(工程师)协作?”两周内,他们与40多位有着不同协作方式的设计师和工程师进行了交流。接着,他们坐下来,对协作方式进行分析。针对每一类协作,了解用户面临的挑战,以及除用户外,还有谁对此感到不悦。
这项调研否决了他们最初想法的一半!Zeplin团队基于反馈,发布了他们的第1版产品,同时通过反馈表、测试程序和积极的客户成功团队持续倾听用户心声。朝着正确的方向,坚定地听取用户的实际需求,而非创始人的奇思妙想,使Zeplin成为设计师与工程师协作的行业标杆。
假如Pelin和Berk像很多创始人一样跳过调研环节,直接搭建产品,结果会怎样?他们可能会在第一个版本中获得类似的用户反馈。从调研入手,可以获得同样的反馈,但不必花费大量时间和精力搭建产品。有了重点和合作,他们可以快速梳理数据。因为他们遵循了规则1,做好了犯错的准备,开放的研究过程否定了大部分的想法,但也为他们斩获新的、更好的想法开辟了空间。