为什么开发人员和用户体验设计师应该一起工作

一则或许对你有用的小广告

欢迎加入小哈的星球 ,你将获得:专属的项目实战 / Java 学习路线 / 一对一提问 / 学习打卡/ 赠书活动

目前,正在 星球 内带小伙伴们做第一个项目:全栈前后端分离博客项目,采用技术栈 Spring Boot + Mybatis Plus + Vue 3.x + Vite 4手把手,前端 + 后端全栈开发,从 0 到 1 讲解每个功能点开发步骤,1v1 答疑,陪伴式直到项目上线,目前已更新了 204 小节,累计 32w+ 字,讲解图:1416 张,还在持续爆肝中,后续还会上新更多项目,目标是将 Java 领域典型的项目都整上,如秒杀系统、在线商城、IM 即时通讯、权限管理等等,已有 870+ 小伙伴加入,欢迎点击围观

苹果到橙子还是苹果到梨?

软件开发人员和用户体验设计师对事物的不同看法不会让任何一个学科的成员感到惊讶。

在某种程度上,这是由于我们制作界面的方式发生了文化转变:从早期的“可用性工程师”到现在的“用户体验设计师”,这意味着从基于工程的研究科学向设计艺术的转变.随着这种转变而来的是专业化,因为开发人员和设计师所属的学科在从事相同项目时逐渐远离。

但这两者真的相差那么远吗?显然,这两个群体都有“游戏中的皮肤”,我将提出这样的论点,即开发人员和设计人员应该在开发周期中更有意义、更早地相互参与。

在这篇文章中,我将用户体验设计定义为一个迭代解决问题的过程,一种达到目的的手段。

那么,在其概要中,这种设计过程似乎与软件开发兼容;然而,对于开发人员来说,最重要的是可能会担心硬约束、部署时间表、边缘情况等。在构思和构建之间,软件开发有时会在中间有一个艰难的中断。那么,这两个群体何时以及如何会面并利用彼此提供的资源呢?

通过进程连接

团队将受益于可用性测试中共享经验的基础。在这里,负责设想可能性的设计师和负责实施该工作的开发人员拥有彼此宝贵的合作伙伴,就像左手和右手一样。此外,可用性测试能够将每个团队的基本事实传递给另一个团队。

开发人员不能希望在不进行可用性测试的情况下了解用户如何与前端交互,因为即使是最好的仪器也只能提供需要上下文的数据。设计人员通常具备提供该上下文的能力,而可用性测试是了解上下文对项目的影响的最佳场所。例如,设计师在管理任务负荷指数评估时从该学科的独特认知镜头中汲取灵感,该指数衡量用户在任务完成期间的负担——一条可能被证明很重要的信息。

但是,如果设计师掌握了用户的上下文,开发人员就会帮助定义什么是可能的。线人通常会在测试期间产生新的想法,阐明以前未发现的需求,或发现边缘情况。如果开发人员在场,那么他们会更早地了解正在提议的解决方案,并有机会参与进来,帮助确定提议的开发方向的可行性,并提高对潜在效率的认识。开发人员可以帮助设计人员在短冲刺中测试从“野外”可用性测试中得出的原型和概念。

无论是开发人员了解她的用户的新知识,还是设计人员开始意识到后端的硬约束,对于两个团队来说,将孤立的信息片段转移到共享流程中都是有好处的。通过保护和指导生产工作,团队可以共同缩短部署之间的时间。

为了适应这种共同努力,该过程的成员应该接受一些基本价值观:

  • 在项目的 早期就伸出援手 ,甚至在团队成立时就伸出援手。
  • 通过邀请同行参加相关会议 来创造对话空间
  • 分担 产品的责任,永远不要将“交接”作为推卸责任的方式。
Josh Teague 的聚会演讲“ 让工程团队参与设计 ”是本文的灵感来源。感谢他的精彩演讲。