header_v1.7.40

UXD实战-如何践行设计驱动力【以B类全景视图项目为例】

8天前发布

原创文章 / 多领域 / 观点
阿里巴巴_B2B_UED 原创,如需商业用途或转载请与阿里巴巴_B2B_UED联系,谢谢配合。

作为设计师,在业务支持外大家都会萌生一些创意的设计想法,并希望推进其落地。希望这套设计驱动方法对大家有所裨益。作者:张晨

背景:经过全景项目组一年不懈的努力,全景图像工具已实现从0到1的迭代上线,覆盖了1688及ICBU两个业务,服务了近30000个商家。顺利完成了设计驱动业务增长、商业价值变现的过程,2.0升级蓄势待发中。

作为一名设计师,在基础业务支持外,大家都会萌生一些很有创意的设计想法,并希望通过自发项目推进其落地。而现实往往是残酷的,即使熬尽心力去推进各方,业务方仍不认可价值、开发资源一度紧缺,外部因素的各种影响最终令项目陷入一度停滞、甚至夭折。今天将B类全景视图项目中沉淀的一套设计驱动方法分享出来,希望对大家有所裨益。

几个自发项目的实战让我明白了一个道理,用设计驱动力去落地一个项目就像建造一幢建筑。一幢建筑的使用离不开地基、骨架结构、设备与装饰,地基可以保证建筑基础的稳固,梁、柱、板等主体性结构可以支撑起整个空间框架,水、电、暖甚至一些功能性家居可以增强空间的使用性。同样,一个自发项目也需要不同的结构来支撑,你需要思考并拆解一下项目的不同阶段,要重点完成项目的预先评估、前期成立、后期执行与落地等环节,以保证项目的基础、骨架及节点内容的阶段性落地。

良好的项目前提可以让你精准地评估、判断设计驱动的机会点,确保项目有一个坚实的基础;链接各方资源组建项目团队,以支撑起整个项目骨架;有效执行项目节奏及时间节点,来确保项目如期上线。

设计驱动的完成不是一蹴而就的,良好的前提会助力项目顺利起航。要学会在业务中挖掘设计驱动的机会点,预先评估好项目的各种可能性。

1.1前提一/避免自嗨,紧盯业务问题

1)认知设计价值属性

从岗位观层面来讲,设计师作为资源方,是运营及产品的下游环节,除了解决用户痛点、提升用户体验以外,还必须助力业务持续发展,实现商业价值变现。而在做设计方案时,我们有可能只从用户角度考虑,脱离当前业务现状,标榜超前的概念以及极致的效果,产出各种天马行空的方案,却不考虑数据哪里采集、内容如何生成。有些设计价值不能为数据所佐证,导致我们经常沉浸在自我的设计观内,过分夸大设计的能动性,错误地评估设计带来的价值。脱离业务现状的设计,往往不会被业务所采用,合作关系也可能陷入僵局。所以一定要端正好心态,设计在以用户为本的同时,也一定要以业务为基。

2)收口当前业务问题

很多新人设计师会遇到不知道如何梳理业务问题的情况,在这里给几点建议。首先,这块业务如果之前有人负责过,你可以咨询相应的前辈设计师,以更快地了解业务问题;其次,你还可以主动求教你的老板,对方的经验及阅历会帮助你快速起步;再次,积极链接业务同事,历年报告及规划PPT先搜罗起来,细读之后将不理解的问题罗列起来,找一个合适的时间向对方求教;当然,用户永远是你最好的沟通对象,邀约几个核心用户做下深度访谈,相信你会收获更多。在此过程中一定要保持谦虚求学的态度,多问、多听、多记,并主动思考业务遇到的问题,在业务与用户之间需建立平衡的关系,探寻能为现在的业务做什么、未来可以做什么。

1.2前提二/构建独创性解决方案

明确了具体的业务问题,又该如何提出独创性解决方案呢?你要基于业务现状深入用户,进行全面且有深度的用户调研,明确核心用户群体、核心使用场景以及切中要害的用户痛点。明晰问题后,可通过内部设计小组头脑风暴的形式来发散思维,从多重角度(如新技术、新工艺、新模式等)来考虑解决方案的多样性及创新性,从中选择具体方向深化创新。

1)结合新趋势、善用新技术

在日常积累中多关注新鲜及热点资讯,研究行业及设计趋势;分析相关或同类竞品,比对其优势及特色是哪些;随时关注新技术,例如人工智能、AR、VR、语音交互等技术的发展趋势,思考新技术是如何与现有场景融合的。当你的设计方案需要借助某项新技术来实现时,你需要提前调研该技术的可实施性,新技术的应用一般是有一定成本的,某些技术存在的壁垒可能让设计方案付诸东流。而在这一环节中,需要注意无论是设计还是技术都是为了解决用户问题而存在的,不要为了炫酷的效果而盲目在方案中硬潜入某些技术。

2)线上、线下模式转换

你还可以深挖用户场景,什么人在什么场景下做了什么,他的目标及痛点是什么,并尝试还原用户的原生场景诉求,找寻是否存在将线下模式转换线上、线上模式转换线下的机会点。举个例子,在深度认证报告改版项目中,通过几轮深度用户调研,发现B类买家与C类买家有很大差异,除了商品本身的决策因素外,还会着重考虑卖家的服务质量、供应能力、公司经营信息等内容,聚焦到具体的用户行为,很多B类买家在寻找新的供应商时,经常会去卖家的工厂、公司、店铺进行线下实地考察。而这种行为的背后其实渗透着用户的基础诉求,那就是对卖家企业实力真实情况的渴求。为了将卖家信息更好地可视化,提出了用全景技术来实现线上验厂的设计提案,方案获得了买家及业务方的一致认可。

1.3前提三/让成本可控

有了方案之后,你还要反复校验方案的可实施性。方案的实现势必需要投入各方成本,你需要评估一下设计提案的投入产出比,让业务、设计、技术甚至是三方的成本可控。这里的成本主要有两个层面,一个是运营经费成本,一个是人力成本。对于运营经费的评估,你可以做几套运营方案,从低成本低回报到高成本高回报几个维度来向业务申请运营经费,如果有低成本高回报的方案更有可能获得运营的支持。而对于人力成本而言,往往内部成本是较为可控的,可让各方按照设计提案预估出需要的人日资源。

而三方服务成本则是运营成本及人力成本交叉混合的一种形式,也是最难评估的一种类型。这里举个例子,当全景验厂自发项目起步时,需要同时考虑客户、业务及三方价值,为了让各方利益最大化,需架构出一套商业模式,商家购买全景拍摄服务、服务商上门采集商家的全景图像,平台则通过运营这套服务模式获取利润。在项目初期,为了刺激服务商团队快速增长,提高运营规模,对每个订单补贴了一定的服务经费。而为了提高全景服务的商业变现能力,必须解决一个问题,如何提高该业务模式下的营收利润率。为此,我们需要拆解一下该模式下的利润率模型,发现可以通过提高全年订单数(开源)、减少总成本投入(节流)的方式来提高利润率。因开源涉及因素较多,这里不再详细描述,重点讲一下节流的模式。而节流的关键就是在降低总成本,用全景的方式去采集工厂图像,就需要考虑三方人力拍摄成本;因工厂分布在全国各地,上门拍摄产生的差旅成本也是一笔大支出;而全景拍摄势必离不开设备,设备的投入成本更是难以预估,一台专业设备至少需要近万的价格。

(a)为了合理控制差旅成本预算,必须避免因过长旅途造成的交通成本上扬。为了解决该问题,划分了全国服务的覆盖范围,建立了区域负责制,以不同省市的中心位置来辐射服务半径,可将交通费用限制在一定范围内。

(b)为了降低设备总成本,需要先评估需要的设备数量。是不是每个服务商都必须配备一台设备呢?答案是否定的。通过核算一年的服务订购量,评估出日平均同时作业的订单数,按照合理的供需关系来配置最优资源,按需采购相应的设备数量,减少因非必需设备量带来的支出损耗。

(c)为了降低服务商的拍摄成本,需保证拍摄质量的基础上,降低服务单次时长,为此梳理了多场景下全景设备的采集规范,并组织了大规模服务商培训,以提高服务商工作效能。

所以善用商业模式、建立二方及三方共赢模式,可以撬动更多资源推动自发项目落地。


有了以上前提的铺垫,就可以开始着手项目执行阶段了。在具体推动过程中你会遇到一些问题,其实归根结底就是两类问题:一是前期项目成立的资源问题,二是后期项目执行的时间节点问题。处理好这两大问题,可对项目如期上线起到关键性作用。

2.1完成资源整合、确立多方共建

作为一个设计驱动者,承担着比设计师更深刻的责任,需要从一名需求翻译者转变为项目管理者,你需要学会协同多方业务资源实现项目共建。

1)驱动业务各方协同

项目的成功是每个项目组成员心血凝结而成的,少不了各个角色的相互配合,而业务角色的配合往往起到核心作用。

多方价值思辨: 为了更好地撬动业务资源,你需要主动去游说各方。除了提供一份独创性、有价值的设计方案之外,还需要深入思考对方需要什么。你需要对各个职能的工作内容有一个明晰的了解,需要站在对方视角将各方价值论证清楚,思考用户、平台、业务、技术价值分别是什么,你能给对方带来什么,“思其所想、破其所难”的方式更容易打动对方。

一致的目标导向:当你拿着一份自以为很满意的设计方案,业务却不感冒的时候,多数是因为你们双方的目标不对标。说的更直接一些,大家的职能不同,自然所关注的重点会不一样,利益点也就不同(KPI不一致)。运营会关注自己业务数据是否突出,产品会关注有无商业价值,设计师则更多关注体验、美感。所以要想拉到项目资源,不要总是“纸上谈兵”,要学会走出去主动咨询对方的目标是什么,能否通过一定的抓手让彼此的目标更为契合,可以对不同的对象角色(如产品、运营、技术)提出与之对应的目标方向(如产品化、品牌运营化、技术平台化)。

自身角色转换: 当业务各方已经愿意一起共建完成落地,而在实际配合过程中,可能也会因为多项目并行造成对方无暇分身,导致合作推进较为困难。这个时候,你需要摆正心态,切换一下自己的角色,以一个产品、运营的角色主动去承担一些设计以外的工作内容,在设计思维之外培养自己产品、运营的思维,辅助产品及运营完成相应任务,需要考虑如何将自己的设计方案打造成通用性产品,如何通过一些活动或渠道来树立自己产品的品牌影响力,切实推进项目发展。

2)撬动多技术共建

利用三方技术资源:在很多情况下,即使方案有价值、业务也认可,但受限于业务技术资源,项目排期一拖再拖无法上线,这种时候可以善用三方技术资源,并勇于调动内部开发来把控技术质量,顺利保证项目起航。

联动集团技术资源:而开发一般都会有几种擅长的代码语言,你所对接的技术可能受开发语言的限制,不能完成某些创新性方案的开发,这种情况下要学会利用集团的技术力量。全景视图课题刚起步的时候,内部技术并不熟悉全景实现的代码语言,而学习成本又相当大。多方咨询后了解到集团有专业的技术团队正在研究这块,我们有应用场景,对方有技术储备,几轮沟通后大家很快就明确了合作方向。所以当你最需要的技术资源内部不能满足时,要学会去联动集团其他资源,链接双方价值以实现共赢。

2.2做好时间规划、节点有效驱动

组建好项目组团队之后,又该如何保证项目节点平稳实施、保证项目如期落地呢?可主要从计划弹性制定及节点风险控制两个层面来具体执行。

1)确保计划的弹性制定

计划的弹性:在项目管理中,我们需要全面考虑产品、运营、设计、技术等各方进度,一份详细且合理的进度表有利于将项目拆解成各个节点。为了确保项目有计划地完成,可按照时间或事件等纬度来安排具体节点,并将主要节点进行重点标注,比如上线时间、大型运营活动,可通过主线Action、次线Action有弹性地牵引项目节奏。

计划的可执行性:在做设计提案的时候,我们会全面考虑用户在不同场景下遇到的问题,提出全链路设计。而在一般情况下,项目资源会受到各种因素限制,方案不可能一次性全部上线,往往需要多版本迭代完成。这就需要作为项目管理者的你,设定出合理有序的多版本方案,让每一步都可执行,先推进1.0最小可行性方案落地上线,再来快速校验数据效果,进而优化2.0版本,用不同版本迭代的方式,逐步实现较为理想的效果。

2)完成项目节点的风险管理

项目在进行过程中,往往会出现一些突发风险,导致项目迟迟得不到进展。而在这些风险处理上,作为一个项目owner不可避免地要和各方沟通来协调资源、对接需求、催促进度,可以抓住“人”这个关键因素做一些跟进及处理。

建立张弛有度的关系链接:当项目遇到一定问题或阻力时,可根据问题的轻急缓重,采用不同维度的方式来处理与项目组成员的关系。

(a)遇到问题时,不要直接把问题丢给对方,也不要盲目催促对方。要把问题梳理清楚,具体的紧急程度是多少,你需要的Deadline是什么时候,想要的效果是什么。这样才能让双方在沟通过程中更好地对焦问题,提高问题解决效率。

(b)在需要对方协助处理一些问题时,还可以通过一些互动形式来积极链接对方,以更了解对方的性格习惯和工作问题。轻松愉悦的环境更利于双方沟通,通过“小恩小惠”的形式请对方喝杯咖啡、吃个饭,倾听对方“吐槽”,了解对方在项目中遇到的难处,并疏导对方情绪,让对方乐于主动去解决问题,避免在合作过程中踩到对方的雷。

(c)在项目中也会遇到一些重大挫折,最终效果不佳影响了用户体验,对方却不能提出较佳的解决方案、甚至会影响产品上线,却碍于对方资源问题无法进行优化。这时候你要勇于找到对方老板,俗话说“擒贼先擒王”,勇于向对方老板说出你对项目的要求,甚至可以带着一份详细的项目规划及价值给到对方老板,搞定对方老板,也就搞定了你需要的项目资源。

善用技巧、让沟通更有效:在实际项目过程中,大部分同事都是多个项目并行的,各方都会有一定的业务压力,在沟通过程中难免会有些摩擦和碰撞。当你与未建立稳定合作关系的同事沟通时,其实是一种黏度很小的社交弱关系的表现。过于强硬的沟通方式可能会造成冒犯之意,甚至对合作关系起到消极作用;而过软的沟通方式会显得不够迫切与急促,可能会造成推进缓慢。你可以根据项目节点不同的紧急程度,采用力度不同的沟通方式,以下排序从弱到强。

(a)给对方分享一些与业务或生活相关的新鲜事,借着话题表达自己的关注点,委婉地提示对方“需求请尽快完成”。

(b)用一定措施来激励对方尽快解决问题,激发对方积极性。为了鼓舞项目组士气,可对项目组成员说:下周项目上线后,就请项目组一起聚个餐。

(c)直接表明自己的立场,敦促对方紧急处理。举个例子:亲,这个问题我说过好几次了,已经严重影响到用户的操作体验,造成了页面跳失率增加,请你务必解决一下。

(d)摆明态度,给对方一个最后期限:周五之前还不能解决问题的话,我要去找一下你们老板了!


除了以上内容,设计驱动项目落地时肯定还会遇到各种不可控因素,务必要保持良好的心态,用韧劲去克服重重困难,随机应变各种情况。全景视图项目行至今日,用设计驱动业务的形式已经赋能了30000个B类商家,其中也是经历了多次业务调整、项目成员几翻变化,我们一直坚守初心,积极探索多业务场景的落地,期待2.0年底与大家再次见面。设计驱动,行在路上,心在远方,与大家共勉。 

7
    没有新消息

    提示文案

    提示文案

    提示失败
    提示成功