博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
设计师应该学习业务而非编写代码
阅读量:6702 次
发布时间:2019-06-25

本文共 1283 字,大约阅读时间需要 4 分钟。

screenshot

时下,越来越多公司在寻找优秀的设计领导力(design leadership),且愈演愈烈。她们认为,公司需要聚焦于设计思考注1,并热衷于采取更多的、以设计为中心的准则。但是每当这些公司和设计师对话时,她们听到的却是匠艺(craftsmanship)——关于品牌一致性、优美的设计、能够编写代码的设计师、风格指南、原型和测试——设计师的手艺(craft)注2。

以上提到的都是没错的——甚至是强制的。但是,为了真正理解帮助业务的最好方式,我们还得从聚焦于业务成功的因素开始。我们必须首先从宏观上理解业务。然后我们才能更好地理解,手艺在哪些地方是重要的(哪些地方过度了)。

设计师往往被看做是需要具备重要业务目标的人,而且是用最基础的方式解释给他们。其实不然,我认为,如果我们能够展开有见地的沟通、并就核心业务原则提供建议,那么,我们在设计方面所发出的声音将更有分量。

我们的当前处境

有大量设计师开始深思,他们的决定是怎样影响公司的。通常地,我们对用户研究和分析的专注,为设计师的意见可信度带来了极大的帮助。我们也看到了很 多典型案例,包括设计领导企业经营的公司 ( design-led companies )以及对重点业务的核心产生影响的设计师们在内,比如 Airbnb、Pocket、Facebook、Google、Slack,还有很多很多其它公司。

我坚持认为,那些公司之所以成功,是因为他们有一群设计师,更专注于业务需求,而不是每一个像素看起来有多完美。

转移关注点

那么我该如何着手考虑设计对业务的影响呢?

或许我们要全力以赴获取一个 MBA 学位(所认识的所有设计师都在这样做,他们在主动为业务核心贡献力量)。但是,或许过于简单了;或许和销售人员交谈是为了理解市场的情况;或许谈及交付和 完成情况是为了理解订单总是延迟一天的原因;或许看过了 Q1 规划才发现,该季度的关键战略和你重构 CSS 没有什么关系;或许是选择夜校注3,学习经济学课程;否则,或许只是在晚上用 Google 检索如何筹措资金、以及资本结构表的原理,而不是学习使用最新的 Sketch 插件。

或许,我们应该把时间投入到业务原则的学习中——如何选择业务模型、如何管理团队、如何开展竞品分析、如何制定规划等。

或许,我们应该尝试学习 CEO 或 VP 所面临的难题,并尽量使用设计帮助他们解决问题?或许,我们应该尽量搞清楚是什么让他们还在晚上坚持工作,并帮助解决他们的问题——而非我们的问题。

未来

我不是说,我们就可以开始交付糟糕的设计体验。我们不得不保持成长,并聚焦于手艺。如果我们做不到,其他人也就做不到。但是,我们应试着理解我们所 在公司的业务,以及为了业绩增长,我们需要做什么。如果我们能够做到,我们将持续赢得更多的影响力,持续创造更有影响力的产品——无论是为了我们的公司, 还是为了使用产品的人们。

====================================分割线================================

文章转载自 开源中国社区[

你可能感兴趣的文章
1-3 - C#语言习惯 - 推荐使用查询语法而不是循环
查看>>
flask cookies 对象
查看>>
OpenStack服务启动故障排除经验
查看>>
实战开发经验: 软件中的错误收集策略
查看>>
让你的 Qt 桌面程序看上去更加 native(五):QDialog
查看>>
Python 简单的多线程执行命令
查看>>
AD活动目录问题总结
查看>>
linux下软件的彻底更新
查看>>
.NET简谈事务、分布式事务处理
查看>>
“有容乃大”的Cisco“无边界网络”
查看>>
再次成功解决苹果XSAN 7TB双RAID5+软RAID0的数据恢复
查看>>
SQL Server编程系列(1):SMO介绍
查看>>
《hadoop进阶》基于hadoop和hive的微博热词跟踪系统
查看>>
Flex与.NET互操作(十六):FluorineFx + Flex视频聊天室案例开发
查看>>
phpMyAdmin的安装及排错
查看>>
Oculus和虚拟现实的无限可能
查看>>
Silverlight自定义数据绑定控件应该如何处理IEditableObject和IEditableCollectionView对象...
查看>>
删除所有的binlog后打不开
查看>>
SATA 250GB*8 RAID数据恢复过程记录
查看>>
装了正版XP的感受
查看>>