做有价值的设计

博客分类: 设计 阅读次数:

做有价值的设计

工作小半年,学习了许多,成长了许多,走过一些弯路也踩过一些坑,到目前对我影响最大的还是标题那句话:做有价值的设计。有时候看起来很棒的设计方案、漂亮的设计稿并不是真正有价值的输出,设计师应该学习练就明亮的眼睛,在需求进来的时候就判断哪些需求该做,哪些不该做,哪些只需要原本完整输出原型20%的工作量能达到目的,哪些是真正需要紧密配合输出高保真原型。对于价值的判断需要大量的工作经验和业务知识的支撑,而我也是在刚起步的路上,抛出该话题也是为了提醒自己需要注意和谨慎。

两个小故事

1.某次组会,有个项目需求是给产品换一套深色主题的皮肤,leader了解到后,立马制止了组员直接做该需求。大意是说,换肤的工作量对设计来说是很大的,需要梳理许多变量、不断和前端确认等等,并不是不能换深色皮肤,而是现在项目还在功能完善阶段,设计人力已经投入了许多,换肤在目前不管是对项目还是对设计师来说都不是一个有价值的事,所以我们不应该现在做这种事,而是应该先将精力放在功能与交互上。当时一番说教让人深以为然,而最后leader也推动此事,最后的结果是先支持在特定的页面换肤。

2.某次自己对接项目,产品提到分布在好几个平台的近20个页面需要迁移到新平台,希望UED做优化,页面大体内容都是同质性的。我看到这20个页面时想的是既然页面都是同质性的,那只要了解了具体的需求做起来应该会很快。而带我的前辈却提醒我,我应该先将20个页面子功能和元素梳理归类,因为分布在不同的平台,会有许多功能相似但表现方式不一致的组件,先抽取出组件再重设计,先评审组件,最后拿这些组件拼成一个个页面,才能最好地保证一致性和效率,说白了就是组件化思维。而实现上也可以抽2~3个页面做设计示范,评审好的组件交付给产品,让产品用我们提供的组件依葫芦画瓢自己把剩下的页面绘制成原型直接进入开发,而不再让设计师跟产品再一遍遍沟通梳理每一个页面的需求细节,大幅提升了效率。

设计的价值

上面两个工作中的小故事提醒我,设计不只是最后交付的设计稿,也可以体现在提高项目效率、提醒上下游可以有更好的方式方法。有些需求设计师不需要全力投入,具体可以体现在下面几点。

1.对不合理的需求说不

设计的结果最终是落地于项目,设计师不能什么需求都接,接需求的时候首先应该考虑需求合不合理,符不符合产品的目标,需不需要通过额外的用研来验证需求,敢于质疑需求的合理性,对不合理的需求说不。

2.对已有成熟的设计模式的简单需求不介入设计

有许多需求都已经有了成熟的设计模式,如简单的表单页面、查询页面,这些小需求产品经理自己基本能自己根据需求输出原型,在已有组件规范的基础上,设计师可以考虑不介入设计,对设计做跟进的工作即可。常常一个需求,特别是B端产品涉及复杂的业务,设计师介入的话需要花许多时间沟通了解业务、内容、字段等信息,如果可以套用设计模式的简单需求,则大可省去需求沟通的成本。让设计师把精力放在更需要设计与探索的需求上。

3.需求进来时提前确定合理的配合方式

需求进来时设计师大概能知道需求的复杂度、需不需要用研、视觉支持等等,再结合项目排期,可确定一个较为合理的配合方式,如果需求流程较为明确,则可一次性输出高保真;如果需求不明确,则可能需要配合用研;如果项目时间紧,需求又没有很明确,则可以采用快速输出低保证并迭代验证的方式…配合方式可以有很多,因项目而各异,但是选择配合方式一定是基于效率和效果的,在需求还在不断探索明确的时期,设计师上来就吭哧吭哧画高保真实际是一种浪费。

4.复杂需求?

复杂的有挑战性的需求当然设计师要花80%的精力处理啦>-<打上鸡血冲呀喂~

show