ThoughtWorks项目情况及设计师职责

Please note: this is the first one of a series of articles on my experience working at ThoughtWorks China design team. Since the articles are meant for young designers who are interested in potentially working for ThoughtWorks China, they are written in Chinese for easier understanding. 

这是《在ThoughtWorks的中国设计团队是什么样的体验?》系列文章的第一篇。系列介绍可以点击链接阅读

如前所述,这篇文章主要回答以下几个问题:

  • TW UX这个岗位的工作场景

  • 项目介绍(包含项目类型、周期、地点)

  • 英文要求和海外出差机会

首先需要指出的是,目前TW已经没有UX(User experience designer)这个说法了。设计团队中的职位有两类,分别是体验设计师(Experience designer) 和视觉设计师(Visual designer)。在团队60多位设计师中,有2位是视觉设计师,其余为体验设计师。TW长久以来对设计师的要求一直是“全栈”,即能够深度参与软件从规划到落地的全生命周期,最近一年才开放视觉设计师职位,所以目前人数相对较少,本系列文章的讨论核心也会围绕体验设计师这个角色。


体验设计师的工作场景

简而言之工作场景有两种情况:on-project 和 on the beach.

作为一名体验设计师,我们归属于PS(Professional service)业务线,也就是说我们工作的常态是为不同的客户提供专业服务,这时我们是on-project,或称之为“在项目上”;此时我们是“billable”;即我们的产出会给公司带来直接经济收益。在没有项目安排的时候,我们就是“on the beach”,或简称为“beach”,此时我们是“non-billable”,即不能带来直接经济收益。

On-project

On-project的情况我在下一节中会详细说明。

On the beach

Beach的时候设计师不是无所事事,而是有各种工作可以进行。高效利用beach时间能对设计师的能力成长起到至关重要的作用。我将在beach时可以进行的工作分为学习、分享和支援三种类型。

学习

每个人已经拥有的能力是有限的。我们在平时工作过程中会积累很多想要深入探究的课题,这可能是同事分享的一篇行业报告、通勤时读到的一种没用过的调研方法、市面上新设计软件的使用方式、甚至是前端页面开发的框架等;beach的时间可以用来集中补充我们的设计知识,拓宽能力的边界。

我自己的体会:在第一次独立主导的交付项目时,对提高大型系统的设计效率产生了兴趣,于是开始研究设计系统的工作原则,这从根本上改变了我思考设计“对象”的逻辑,为以后的设计产出打下了良好的基础。

分享

在每个项目之后,设计师应该都有自己的总结和沉淀。这可能是项目中做得好的地方、值得借鉴的工作方法,或是有待改进的地方、以后可以规避的风险等。不管是前者还是后者,都可以整理成一个session*分享给团队,或者在公司内外发表一些文章。

我自己的体会:接着上面设计系统的例子。在有了一定理论基础之后我开始在交付项目上实践设计系统工作模式,发现有些团队同事对这种思维方式还不太了解,于是进行了为期8周的设计系统实践分享。这不仅提高了团队沟通效率和产出质量,我自己的演讲能力也得到了不错的提升。

支援

TW每个人的项目安排都是可以即时查询的。当其它团队发现你目前是beach的时候,有时会询问你愿不愿意为他们正在进行的工作提供帮助。这可能包括进行项目售前**、策划参与社区活动、培训新人、给正在进行的交付项目提供支持等等。

我自己的体会:在beach时最多被问到的就是能不能参与项目售前,常常需要在1-2天之内快速了解客户的行业状况和具体需求背景,产出有针对性的提案,对桌面研究能力是不错的锻炼。另外还组织了诸如深圳2018 Global Service Jam这样的活动,一起参与策划的同事都是下班之后投入了额外的精力,活动本身也占据了整个周末;累是肯定的,同时也非常有成就感。

我认为有良好规划能力的设计师需要结合自己的目标,平衡学习、分享、支援这三种类型的beach工作。这里虽然没有黄金比例推荐,但最好围绕自己最想培养的能力或者最想钻研的领域。举例而言,如果我想增长自己知识输出和公开演讲的能力,我就会更多参与session分享、文章撰写和社区活动;如果我想培养自己制定服务设计解决方案的能力,我就会更多参与相关售前工作、进行领域和行业研究。

项目类型、周期,及对设计师的能力要求

ThoughtWorks中国区设计团队创始人熊子川在2016年的一篇知乎回答中对ThoughtWorks的项目定义与介绍在今天依然大部分是适用的,所以本节内容会在对这篇文章的引用基础上进行补充说明。

按照项目对设计师的经验要求由低到高排序,ThoughtWorks的项目可以分为3大类:设计交付,设计启动,产品洞察与创新。

设计交付(Delivery)

先来看看设计交付是什么:

——————以下为引用———————

2008年加入的时候,我们并没有设计业务自然也就没有能力,在我工作的前三年里,我的工作就是在「纯敏捷交付」环境中为每一个用户故事(User Story):

  • 跟客户确定解决什么问题;

  • 自己给出解决方案,以及解决的思路和过程;

  • 将解决方案转化成开发团队能够实施的步骤;

  • 在出现反复(如复杂度过高)的情况下和客户协商,寻找最合理方案;

  • 进行验收和演示与客户确定(Signoff);

  • 跟踪缺陷的情况进行修正。

这些都是最纯粹的敏捷交付中一个设计师需要完成的任务,远在2008年,我们就已经开始进行这样的工程或设计实践。而这项工作依然是我们目前设计团队的工作内容,通常是一个初级设计师进阶的开始。

——————以上为引用———————

我在ThoughtWorks的第一个项目就是设计交付。项目背景是为一个跨国集团在中国区几百家经销商打造销售平台,包括手机端和 Web 端,涵盖前台接待、销售顾问、销售经理、后台配置等多个角色。产品支持用户完成从进店到交车的所有业务流程,并提供数据支持与报表分析。

项目的人员配置是2位体验设计师(包括我在内),4位业务分析师(BA),20位以上前后端开发人员(Dev),1位Tech Lead(TL),1位Project Manager(PM)。我加入时已经开发了近一年的时间,是ThoughtWorks的核心项目之一,这样的人员配置规模是常规交付项目的2倍。

我在项目上面临的第一个挑战是快速了解项目上下文,明确已经开发和规划的各个功能模块,同时熟悉客户的业务流程。在项目开始之前,我申请了项目文档的访问权限,阅读了项目启动时期的产出以及各个迭代的showcase材料。同时下载了已上线的手机端App进行了解。下面是我在入场前用MindNode这款软件梳理的App信息架构和部分流程图,并在项目中进行了持续完善。

我在ThoughtWorks的第一个交付项目入场前梳理的部分产品信息架构和用户流程

我在ThoughtWorks的第一个交付项目入场前梳理的部分产品信息架构和用户流程

项目开始之后,有更senior的设计师一起工作,不懂的地方都可以请教,工作内容和熊子川文中提到的基本吻合。印象比较深的一点是:交付项目对每个细节的要求都非常高,很多信息需要反复确认。

例如,销售经理在卖车的时候可以给客户赠送一些礼品,而这些礼品都需要在APP中进行记录,我们需要设计相应的表单去完成这项操作。下图是开始设计之前和BA确认的表单信息:

设计赠品功能前需要确认的字段信息

设计赠品功能前需要确认的字段信息

附赠礼品是在整个售车流程中非常小的一个环节,但这个需求从确认、设计、开发到验收完成花费了差不多2周时间。其中用在真正产出设计图的时间可能只有1个小时,其它时间都是在做准备、沟通和确认工作。这也是我在交付项目中学到的重要一课:做任何设计之前都要搞清楚这个需求为什么做、该怎么做。如果只是一味对着屏幕画图,只会陷入无休止修改和重做的漩涡。

说到这里,就不得不提及设计师必备的沟通能力。在ThoughtWorks任何项目上,沟通都是重中之重。在交付中需要频繁和BA沟通,确认客户需求;和Dev沟通,确保设计可执行性;还要和客户沟通,理解需求背后的原因,并能够清楚地传达自己的设计方案。关于沟通能力的提升需要另外一篇文章单独说明,这里就不作展开。但我认为除了能力以外,本质上更为重要的是“沟通的心态”,即意识到设计不是一个人做出来的,而是团队协作的结果。只会闷头做设计的人不适合ThoughtWorks的业务模式。

另外一项非常重要的能力就是判断各项任务优先级并进行高效处理的能力。上面提到附赠礼品表单这个功能做了2周的时间,并非是2周里只处理这一件事情,实际交付中往往有多个需求条线并行。每个需求可以拆分为几个步骤、每个步骤需要花费多少时间、有哪些人员和资源的依赖、需求之间的相对重要程度等等因素,设计师都需要有自己的考虑。

能够做到这两点,作为一个ThoughtWorks初阶设计师的能力就算过关了。与此同时,设计师的基础能力也需要持续打磨,包括:熟练运用设计模式、给出设计方案、产出交互稿和视觉稿等等。

我在这个项目上工作了3个半月,后来回到home office加入了一个设计启动项目。Delivery项目的时长在3个月至数年不等,设计师在其中的工作周期一般以季度为单位,工作满1个季度之后,可以和项目一起评估是接着做下去,还是换一个别的项目尝试。

设计启动(Inception)

能够在设计交付阶段做到得心应手,ThoughtWorks的设计师就就有机会参与设计启动类项目。以下是熊子川对设计启动的描述:

————以下为引用————

这样的工作环境(设计交付)使得我能够处理多种场景下的沟通、和程序员的、和架构师的、和测试的、和项目经理的、和客户的、和客户其他部门的等等。这种技能的磨练使得设计师能够更游刃有余的适应不同的场景,在当下做出最合情合理的决断,而不仅仅从设计本身。

这使得我接触了大量项目的设计启动,大概从2010年开始我主持了多个大型产品的启动,做的最多的,就是Inception启动活动,关于Inception可以参考我之前的文章《Inception的核心逻辑》。大体来说,就是以下这个过程:

这个过程需要设计师面对客户强大的控场能力、以及对设计实践的深入理解。

————以上为引用————

前面提到在Delivery期间设计师所需要的核心能力包括:需求理解、沟通、处理多线程任务,及设计产出。在Inception阶段除了要做到上述几点,最关键的是要有全局观。Inception的人员标配是2个XD加2个BA(后期会加入1个TL),这个4人团队需要在2周时间内(也有1天或3天的精简版Inception)针对产品的6项核心假设进行快速验证(决策者、业务需求与设计范围、技术实现、交付时间、产品有效、和可运营性)。

这个时候设计师的工作是广义的设计,即我们通常倡导的设计思维中设计、商业和技术的全盘思考。当然一个人很难在这三个领域都拥有完善的能力,所以才会有上文提到的团队配置。惯常的工作模式的XD主导设计,BA主导业务,TL主导技术;但团队中每个角色都需要对其他角色的工作范畴深度参与,互相支持。

做了好几次Inception之后,我的感受是这个过程有点像炒菜。公司已经有了一套标准化流程,这是菜谱;项目资源(包括人员、时间、客户成熟度等)是食材;项目现场的控场和应变能力是火候和调料。照本宣科按照流程走并不能保证Inception的成功,关键还是看食材和火候。

其中火候是最难掌握的。这中间没有什么捷径可走,只有靠不断的经验积累和反思。例如在进行工作坊的时候,有经验的设计师会要求客户在讨论环节不要坐着,站立的姿势更能激发人的创造力和促进参与度,能有效避免冷场。但作为主持人怎么做到在需要坐和站的不同环节中自然地进行引导和切换,就需要一番功夫了。

产品洞察与创新(Disovery)

在Inception之后,设计师还有第三种项目选择,那就是Discovery。还是先看一下引用:

—————以下为引用—————

在另外一个场景中,客户对于要做的事情极为不确定,他们也许手握资源,也许手中有个战略咨询公司包装的方案,但如果你足够资深,你就知道,这离真正开始还有相当长的距离。这也是我们设计师工作的一个主要场景。

我们会和客户一起,参与一个关于洞察和创新的过程,这个过程中我们通过发现、研究、设计、原型、测试、总结、学习、反馈、演进等过程不断打磨我们的产品想法,最终进入到交付阶段。

—————以上为引用—————

是不是感觉和Inception有点像?那这两种项目的区别到底是什么呢?沿用上文中的比喻,Inception基本是按照菜谱来,而Discovery是基本不可能有菜谱。因为不确定性很高,设计师需要准确判断自己手握的食材(资源),了解客户的口味,自己去编写优秀的菜谱(项目计划),再通过火候和调料的掌握去把这盘菜给做出来。换句话说,Inception一般有章可循,不管是1天、3天还是1-2周,都有比较明确的假设范围和可以参照的执行计划;而Discovery项目中设计师需要自己去明确核心假设的范围,再以此为基于去制定执行计划。

这个时候团队构成还是以XD和BA为主,可能有2-4人不等,项目周期一般为1-2个月,比Inception更长。在这个期间非常关键的是保证客户参与,不断确认项目方向。Inception失败的原因是菜炒得难吃,Discovery失败的原因却可能是菜本身不错,但完全不是客户想要的那盘。

关于项目种类就先写这么多。最近几年ThoughtWorks的Discovery类型的项目有很大的发展,我从去年底开始参与过3个,分别是智能汽车产品创新、出行服务生态规划和HMI交互探索;以后有机会再展开写。

ThoughtWorks 的设计流程

ThoughtWorks 的设计流程

英文要求和海外出差机会

我揣测对英文能力的疑问有两种出发点:一是自己英文不怎么好,对能不能正常完成工作感到担忧;二是觉得自己英文还不错,想在工作中充分发挥优势。接下来我会从这两个出发点分别回答。

英文要求

参加过托福考试的同学都知道,测试分为听、说、读、写四个环节。在ThoughtWorks的工作环境中,对这四种能力都有一定要求,按照重要程度递减就是读>写>听>说。

我们对“读”的要求最高,作为英文为第二语言的人,掌握读也是相对最容易的。我们的工作中有两类情景会用到这项能力:一是日常事务处理,二是项目需求。首先,ThoughtWorks作为一个跨国公司,通行的沟通媒介是英文,公司内很多公示类的邮件都是英文撰写,平时常用的办公系统(报销、timecard等)也是英文。其次,出于项目需求,我们时常需要阅读英文的文献。例如在进行行业技术调研的时候,我参考过美国NHTSA机构关于自动驾驶安全的论述。

所以,ThoughtWorks对于英文的最低要求是基本能够无障碍阅读专业领域的文献资料,如果做不到这一点,ThoughtWorks可能不太适合你。

从本小节开始就是加分项了。因为我们客户中有很多跨国企业,在中国本土的不少项目的产出语言也是英文。换句话说,平时做项目的时候大家说的是中文,但写材料和作汇报的时候需要用英文,因为最终对项目拍板的核心干系人是从其它国家外派过来的。

这个时候我们就需要能够用精准的措辞和正确的语法撰写报告,熟练掌握相关领域的英文词汇,将项目产出准确无误地呈现给客户。

很对人觉得从读到写是很难逾越的一大步。我认为这是从量变到质变的积累,读得多了,自然就会写了。

之所以把“听”和“说”分开讲,是因为有的工作场景只具备“听”的能力也能够派上用场。第一是干系人访谈和用户访谈,第二是汇报后的核心干系人反馈。在这两种情况下,口语能力优秀的同事会负责沟通,而听力能力过关的同事可以帮忙记录要点。

到这里就没什么好讲的了,大概就是能做到“愉快地用英文交谈”,大家自行想象一下吧。

另外多说一句,做到这一点我觉得重要的不在于发音标准也不在于词汇量丰富,而在于有自信心。

海外出差机会

海外出差的情况主要分两种,短期(数天至数周)和出海(3个月至无限期)。

短期

短期项目的由来一般是海外客户因为人员或者成本的考虑,希望把项目开发放在中国做。于是就需要中国员工参与Inception,了解客户需求。只要能力满足要求,参与这类项目的机会是很多的。我认识一位同事在过去一年中到海外出差了10次,成功练就1天内倒时差的超能力。

出海

对于有意在国外长期工作的员工,也可以选择时间较长的外派项目。目前开放的国家有美国、德国、澳大利亚和新加坡。

据我所知,符合要求的人只要有意愿,基本都能入选。但基于对入职时间有2年以上的硬性要求,应届毕业生还是暂时不要想了。

关于ThoughtWorks项目情况的介绍就到这里,在下一篇文章中会说明设计师在ThoughtWorks的成长体系和发展空间。

注释:

*围绕某个特定主题的分享,例如”如何在项目中管理复杂的干系人关系“ “如何进行低成本的商业模式验证” “如何做好keynote文档设计”等等。一般时间为1小时,多在午休和下班后时间进行,可邀请任何人,现场或通过视频会议远程接入。
**即向新客户介绍我们的服务内容和服务方式,用来促成新项目的产生