SeraSay

本本:

一、交互设计师的“成本”意识

半年前换了产品团队，从一个处于稳定迭代期的产品，去了一个处于二次创业状态的产品。产品要摸索新的方向和模式，所有功能都处于一种“不稳定”状态，产品经理可能今天想这样做，明天就又推翻了自己前一天的想法。每一次上线都很赶，方案也没有时间打磨得很细，想到的细节优化也很多会受阻于各种视觉、开发、运营资源限制而无法实现。因为各种成本限制，上不了线的设计方案做多了，慢慢的，就开始养成了一种习惯，经手的每一个需求和初步的方案，都会在脑子里过一遍成本——视觉、开发、运营，分别需要投入多少人力去做这件事。

做设计师的往往是比较理想主义，也往往是比较完美主义的一群人，通常会希望把每一个细节都做完美。但现实往往是残酷的。如果抱持着“要么爱情，要么面包”的姿态——放在产品功能里就是，要么不做，要么做到最好，往往最后就是什么都做不了了。只怪互联网变化太快，速度就是一切。“小步快跑”的快速迭代，注定了新功能难以一次完美。如果希望功能和方案能顺利落地，而不是常常流产，成本意识是非常重要的。交互设计师是离方案最近的人，也就成为了离成本最近的人，交互设计师的成本意识，可能会直接决定这个方案的可落地性。

二、方案的实现“成本”都有哪些呢？

1.开发成本

当我最初意识到“成本”这件事时，第一感知到的是开发成本。因为它是产品功能落地过程中，对专业技能要求最高的一环。技术实现不了的方案，最容易成为飞机稿。但这个岗位的学习门槛，至少就目前而言，还是非常高的。作为技术小白，除了飞蛾扑火式地学习过一段时间iOS的OC以外，也只能在不断做项目、跟开发交流的过程中，慢慢去理解他们通常的实现逻辑了。

比如，要有“对象”的概念，要知道开发喜欢复用单元，这样可以帮他们省掉很多重复劳动。但是开发的弱项往往是对业务的理解不够深，容易把功能和业务做成耦合，这样在你下次想改变做法的时候，就很容易碰到开发跟你说，这样做的话，上次我做的***就基本等于重做了。了解了开发的工作方式，交互设计师在设计方案的时候，就可以多为开发想一步，从长远来看，相当于也是为自己多想了一步。你肯定也不希望开发GG们一天到晚都在解决代码重构的问题，而对各种各样的新方案爱莫能助。

来个例子：

   

图1是LOFTER发布器里，添加贴纸的页面，因为贴纸这种图片属性的东西，加载起来会比纯文字慢很多，用户能很明显感知到，所以需要考虑加载控制的问题，尤其是弱网环境下的情况。但是又因为，从开发上讲，很多页面都可以导向这个页面（图2、图3、图4，分别对应贴纸的不同入口），要保证体验良好，必须结合开发考虑到底在哪个节点开始加载图片，加载顺序如何，是否需要加载动效。但是同时也会出现一种情况，就是体验最佳的情况，很可能会带来更多的开发成本。因为如果从开发的角度看，不同页面进入时的加载控制方式，最好用一样的，这样代码就可以复用了。这个时候，就需要交互设计师综合考虑成本和体验，选取一个比较平衡的方式了。当然如果能考虑到未来的扩展性问题就更好了，这个就看交互对业务的理解和预判能力了。

话说回来，回头去看，这个项目里，在基本功能之外，我也过早考虑了“教育玩法”这种希望能让使用体验更好的事（这里甚至先撇开了这种方式到底是不是能带来更好的使用体验不说）。功能早期，在没能验证需求的情况下，做得越多，偏离正确的方向就越远。如果现在再让我去做这件事，可能会希望第一期先只用来轻量级地验证需求，同时兼顾好扩展性即可。

2.运营成本

在我来到目前产品团队之前，原产品团队曾做过一次改版，如下图，从 图5 改成了 图6：

 

看起并不起眼的一次变化，但是却对运营的工作方式带来了一次巨大的变革。从那之后，作为内容社区，LOFTER有了更多除摄影以外的领域，运营们的一个主要KPI，也变成了各分管领域内加精内容的互动率。这意味着长期而巨大的运营成本。

但这次改变带来的性价比，是否对得起这样的变化，至今扔需打一个问号。

3.视觉成本

下面这个例子里，只需关注头图的变化。

 

图7到图8的版本，顶部banner只是换了一个尺寸而已，看起来是很不起眼的一件事。可是版本更迭的很长一段时间内，还是带来了很大的视觉成本。

为了照顾到那些还没升级到新版的老版用户，作为对视觉表现有一定追求的LOFTER，在蛮长一段时间内，都是每个活动/专题做两个banner。

这些不起眼的小变化里，都藏着各种角色的血和汗啊。很可能只因为你做方案时的一个闪念，带来的就是别人大量或者长期的劳动。

追求细节完美是个好习惯，但作为各种资源都异常紧张的团队一员，更需要对每个方案的“机会成本”形成一定的意识。

不过，同时还需要警惕一件事，成本意识可能带来的弊端是？也许是对设计想象力的限制。重要的是，设计师本人要去平衡所有这一切，做最“合适”当下情境的设计。

三、资源受限的情况下，如何最大化地发挥设计力量？

如果设计师受限于上述种种限制，而放弃去做“改变”，也是不负责/不专业的体现。

其实很多时候，每一种设计方案，都有可能有更低成本的替代方案，即PlanB，它也许不是最优解，但往往在资源有限的情况下，能比PlanA在短期内解决更多问题。

如何寻找这样的方案呢？这就又要回归设计的本质了。作为一个产品向，而非视觉向的交互设计师，我对“设计”的理解就是——解决问题。在这个定义的前提下，需要做好下面三件事。

1.解剖问题，寻找本质

来一个具体的例子：

前段时间，运营找到我说，希望在我们现在APP的领域页面内加一个banner，问为什么，答曰目前给到活动、专题的曝光太少，影响了活动的参与量。按照这个思路解剖下去，我大致分解了一下目前域内能带来流量的渠道，如下图（不完整的草图，仅作举例参考）：

根据运营的需求，他们希望我们有更多的位置给到活动曝光。但问题真的这么简单么？

我重新去看了当下移动端发现tab的流量，和发现tab上方banner的点击情况。发现发现tab的流量非常高，但是顶部banner的点击却一直都很低。

那么问题来了，运营遇到的问题，追根溯源地讲，到底是什么呢？

带着这个疑问，我去找了某领域运营聊了下，问他为什么在看似入口流量这么低的情况下，他发起的活动每次都还是有很大的参与量。他的反馈是，因为banner位流量太有限，所以他会想尽办法，用官博和他自己的大号、以及产品特有的功能“推荐”、包括自己一直维系的领域达人群，来共同助力去完成活动推广这件事。一番沟通下来，我突然明白了，流量这个东西不是死的，尤其不是几个简单的banner位那么简单。其它运营对流量不足的抱怨，本质上也许不是真的曝光次数不够，而是有效曝光不足。从LOFTER开始走多领域运营这条路开始，就已经失去了原来垂直社区的精准度的优势。而这个问题，也许是需要我们通过其他方式去解决的。而运营对这个问题的抱怨，也正反映了他们对这个问题本质的理解可能还不够。

2.分清楚“目的”与“手段”

产品早期最重要的任务是什么？剥开问题看本质，毋庸置疑，一定是验证需求。

设计的目的——验证需求。那么用什么方式来验证呢？

做界面做久了，容易停留在自己的舒适区，依赖最熟悉最擅长的“界面”来达到一切目的。需求拿到手，就会想这个事要在哪个端做？分几个页面？每个页面大概长啥样脑子里大概就有了。却忘了“善水者溺，善骑者坠”这个看似平凡却深刻的古训。擅长用什么武器，第一反应就会一直是用这个武器，而不再去想是不是真的“合适”这件事。

3.“借力”

如换句话说，就是充分利用任何可以利用的资源，四两拨千斤。就像独孤九剑，不需内力，靠“借力”依然可以打败内力比自己强很多但对武功悟性不如自己的人。而一个拿枪的小朋友，也许就能很轻易地破了独孤九剑的法门。

武器选对了，同样是达到目的，却能少花很多力气，何乐而不为呢？

一个最近遇到的案例。

一个想做to小B海淘生意的朋友，在早期冒出这个商业idea的时候，选择了微信群这种最轻量级的方式，去验证他对市场需求的预判。得到初步验证以后，规模化以前，他依旧没有着急做自己的网站或app，而是选择了微信服务号这种也比较轻量级的开发方式，去承载他的功能需求。

这是件看似简单，却很值得回味的事。时刻提醒我，解决问题不是只有“界面”一种方式。对于一个企业来说，市场需求最合适的承载方式未必是互联网产品，互联网只是“手段”，是一个通常较好用的“工具”，却不一定是最适合当下市场需求的方式。对于个人来说，如果仅仅把自己定位于一个解决界面问题的交互设计师，自己的路会越走越窄，越来越远离“设计”的本质。

《增长黑客》里有一章专门讲MVP的，里面每一个案例都很值得仔细回味和咀嚼，各个产品的创始人为了验证需求也是大开脑洞，各种五花八门的办法都能想到。这里就不一一赘述了。

最重要的，还是要时刻保持一颗开放而谦逊的心态，不断倾听、思考、学习。

四、推荐相关阅读

1.关于开放的视角和心态：首推《人类简史》，通俗好读，以一种震撼而全新的视角去看人类文化的发展史。 
2.关于MVP最小化可行产品：《增长黑客》中关于MVP的章节。 
3.“借力”：金庸小说全系列——飞雪连天射白鹿，笑书神侠倚碧鸳 
4.理解商业：风尘棋客《商业分析能力是怎样炼成的？》知乎回答 https://www.zhihu.com/question/20603837/answer/47073613 
5.成本：各种开发者文档；各种角色的工作方式，工作量分布，KPI考核方式 
 
五、再加一个题外话：

基于MVP“借力”的思路，“产品经理到底如何去挖掘需求和机会点？”，前几天写了另外一篇文章谈了下自己的感悟：https://seraying.lofter.com/post/36979b_b272211