0%

产品开发的幕后花絮

        介绍产品专业人员用来定义问题,创建概念和选择最佳解决方案的方法。

        与关于设计师职务的争论类似,对于设计师是否应该编码,这是一个永无止境的讨论。 首先,我们谈论的是根本不同的心态。 尽管开发人员对技术流程的思考更多,但设计人员专注于用户执行的一系列操作,因为他们的目的是提出解决客户问题的方法。

        因此,产品设计师(或UX设计师,但正如我之前提到的那样,我不喜欢该职位)通常不做任何编码,仅因为我们从事的活动是专职职责。 设计师的大部分工作实际上甚至没有建立图形用户界面,而是进行了大量的交流和研究。 🔍


我们有一个问题

        通常,当我拿到设计图时,该过程已经开始。 我们的产品经理来找我解决问题。 有几种定义问题的方法,例如根据数据分析或竞争对手的活动做出的假设; 技术改进为我们提供了更多空间; 或客户的直接要求。

        第一步(也是最重要的一步)是了解问题。 假设我们盯着分析,看到用户在流程的某个特定点下降,放弃它而没有完成任务。 问题是:为什么? 提供解决方案之前,你需要确定要解决的问题。 你需要了解动机,目标,需求以及用户当前解决问题的方式。

提示:
        直接来自客户的想法可以对你的系统进行非常好的改进,但是你需要谨慎。 系统越大,用户对系统一无所知的机会就越大,这可能导致错误的假设。 他们可能不知道某些“隐藏”的细节,但是如果知道的话,他们会问一个完全不同的问题。 用户对现有系统的信念称为心理模型。 这仅表示他们基于对当前工具的了解,相信他们可以或不能使用你的工具。 心理模型可能会因教育或经验而改变,因此在你开始编写代码之前,你可能需要了解他们为什么想要特定的东西。 也许解决方案不是他们想要的,但是你可以给他们更好的解决方案。

        有几种方法可以收集有关原因的信息,而我最喜欢的两个是调查和访谈。 你可以收集所有听众提出的一些高级问题,然后发送表格。 找到适合你的问卷调查的最佳平台并不总是容易的:虽然一个渠道可以为你提供大量的答案,但另一个渠道将是死路一条。

        时间安排也很重要:你应该注意听众的时间表。 当他们太忙甚至不工作时,他们将没有时间或精力来帮助你。 进行良好调查的秘诀还有很多,但重点是你需要耐心,尝试几种方法来吸引受众,直到找到最适合你的案例。


与用户的真正联系:用户访谈

        我喜欢的另一种做法是进行用户访谈。 听起来就是这样:你与用户(最好是一对一)坐下并与他们交谈。 你需要再次准备问题,但是调查虽然可以帮助你了解很多事情,但是面试仅可以帮助你解决一些问题,但范围更广。 重要的是进行实际对话而不是询问客户:你收集的问题是面试的基础,但是当客户回答时,你可以侧身甚至完全劫持讨论(只要你谈论的是你所遇到的问题) 都想解决)。

        如果你随身携带一个记事本,这将很有帮助,这样你就可以在伴侣写下最重要的要点时全神贯注于对话。 如果你的客户同意,你可以记录下采访,以便稍后再听并写下你自己的笔记。 🗒

提示:
        重要的是要观察到广泛的用户,尤其是在组中有多种用户的情况下。 如果你只关注一个小组,那么你可能会满足这对夫妇的需求,而拒绝其他人。

        当我对问题有满意的答案时,我可以通过创建草图或基本模型来开始实际的“设计”工作。在这一点上,我并没有将重点放在外观或精度上,我只是尝试为我的想法建立一些视觉支持。有时,我什至没有构建整个功能或页面,而只是构建一个特定的部分,例如复杂的控制器,模式,表单等等。我还尝试至少提出2-3个概念。这将帮助我与团队交流思想:那是我参与开发人员的地方,因为下一步是了解技术限制。当然,如果我们无法为用户找出有史以来最好的UI元素,那也没关系。

        在收集了我们需要的所有信息之后(包括用户的必备信息,开发人员的约束以及可能的其他因素,例如设计,完整性和一致性准则等),我们的工作重点变得更加狭窄。这是我开始在像素完美的UI上工作的地方。我创建了可点击的原型,因此可以为团队提供一个快照,以显示实际软件的外观和工作方式,更重要的是,它们将成为可用性测试的核心:是的,我们将回头再回头。


可用性测试简介

        用户测试类似于访谈,你一次要与1位用户交谈,但是你可以提出任务而不是提问。你应该准备要执行的3-4个任务,就像它们已经存在时在系统中通常会执行的操作一样。这是验证你的工作,查看用户是否真的能够通过你的特定概念解决他们的问题的好方法。你如何进行这些会议的方式可能会因项目,概念因人员而异,但是以下一些重点可以派上用场:

  • 你测试用户界面而不是用户。无论他们做错了什么,不是他们的错,这是你的界面的缺陷。他们应该知道,你也知道。
  • 不要给出详细的说明,而要编写高级任务,类似于现实生活中的任务。即使他们受过使用你的软件的教育,也不会一直有人陪他们走走。为了模拟这一点,你也不能通过原型指导他们。
  • 包括与任务不直接相关的选项。如果你使用一些原型制作工具,它可能会以某种方式突出显示可点击元素。如果唯一可点击的东西是测试的控制器,他们将很容易找到解决方法。但是,如果有几个不同的可操作项目,它们将能够环顾四周,打开和关闭物品,并且一旦达成交易便会迷失方向。即使你感觉“来吧,就在那里,为什么不找到它”,也应该抵制胆量并保持沉默。对你来说也许很清楚,但对他们来说却是一个谜。这些测试的目的是发现谜语,而不是证明你的想法合理。
  • 提醒参与者在整个会议过程中大声思考,以便你了解他们为什么做自己的事情。与面试期间一样,你应该创建笔记并可能记录会话。会议结束后,你还可以与用户聊天。你可以回去问一下,如果他们在会议期间没有解释,为什么他们要做特定的事情。你甚至可以在这一点上询问他们的意见,但绝不能在会议期间提出。放弃有关UI的想法可能会使你偏离测试目标,因此请保持专注并保持参与者的专注。

        这些会议的结果将帮助你了解概念的弱点,或者只是帮助你选择最佳的概念。 你可以重新考虑一些事情,然后再进行测试,然后再继续。 测试和迭代的次数取决于你的时间和预算:根据 Jacob Nielsen 的说法,如果与5个用户一起测试,最好的方法是考虑未发现的问题的数量和会话的成本,因为一段时间后,用户会反复发现其他已经存在的问题 裸露。

        适当招募参与者也很重要。 如果你要为会计师构建应用程序,则可能不会获得机械师的宝贵反馈。 同样,如果你要改善现有服务,则最好与已经使用该服务的人联系,而不是与新员工交谈(除非你尝试弄清楚新手将如何与新功能交互)。


要避免的常见错误

        还有一种称为设计批判的做法,在这种做法中,大量的团队成员(设计师,开发人员,质量保证人员,产品经理等)坐在一起讨论设计。 你提出自己的想法,其他人则可以基于对一致性,技术约束,所有问题或简单的可用性假设的关注而提出问题并提出更改建议。 这可能真的很有帮助:当你花很长时间尝试解决问题时,可能会遇到困难。 睁开眼睛和其他角度可以帮助你摆脱困境,无论如何都要进行一些头脑风暴总是好的。

        但是,团队经常将DC会话与适当的可用性验证混淆。 为什么不能仅用它们代替UX研究有以下几个原因:

  • 详细说明     在可用性测试期间,你将执行任务并查看其他人如何与你的原型进行交互,而设计评论则是关于你自己讲述整个故事。你按照流程进行操作,并告诉团队正在发生什么以及为什么。这样很容易理解,但是如果仅UI没有解释,则可能会失败。
  • 领域知识     即使你只是在从事合同项目,与你一起工作的团队也具有丰富的领域知识。你知道系统的工作原理,知道后台发生了什么,如何传输数据,调用了什么API……用户不知道这种事情,你也不是你的用户。
  • 主观性     虽然你可能喜欢某些东西,但其他人可能不喜欢。另外,尽管你认为某些事情很清楚,但其他人可能不理解。当你说“我认为这可行”时,这只是你的观点,其他人可能会基于他们的观点对此进行争论。意见分歧可以帮助你取得进展,但是,如果保持不变,这是一个标志,你应该查看用户的反应方式,而不是争夺你的意见。
  • 自我     我并不是说它总是存在,但是这些讨论很容易变成有争议的论据,每个人都试图说服他人。我对此不够强调:你没有为自己设计(或编写代码),而是为用户设计。如果团队中的某个人有一个更好的主意,或者只是发现了一个错误,请高兴地为你提供改善产品的机会。这不是单人表演,而是团队失败或胜利。

        此外,要在没有任何实际数据的情况下通过一次演示来证明自己要困难得多。当你的设计基于推测时,可能很难捍卫一个想法,因为你无法用事实来支持它。其他人可能有不同的假设,从这一点出发,论点立足或落在参与者的说服力上。

        这并不意味着这些会议根本没有用,它们无法替代研究,因为它们以不同的方式帮助你。我也认为争论通常是好的,因为我们可以了解很多彼此的观点。我要说的是不确定性使事情变得困难,因为你只有在发表作品后才能看到结果。最好的办法是定期与团队进行研究并进行同步,以便在技术上仍可行的情况下,确保要构建的内容能够很好地为用户服务。

        你创建的所有内容都会带来用户体验。 UX不是你设计的,而是工作的必然结果。请记住这一点。 🙏


设计师应该编码吗? 开发人员应该设计吗?

        我认为存在这个永恒的问题是因为图形UI设计本身通常并不困难。 UI设计工具(例如SketchFigma)非常简单,即使没有经验也很容易使用,而无需谈论网络上成千上万的优质教程和资源。图形用户界面设计是一项技能,而成为专家意味着你还拥有许多其他有价值的技能,这些技能最终将定义你。

        由于设计师和开发人员的思维方式之间存在核心差异,因此我更喜欢将研究与设计结合起来,而不是将设计与编码结合起来。如果你对自己的系统技术知识有偏见,可能很难找到问题的抽象解决方案。这就是为什么我在多个学科的协作以及不同观点的结合中看到真正价值的原因。

        但是,以视觉方式呈现你的作品仍然是有益的,因为它可以帮助你发现潜在的盲点和缺失的边缘情况,还可以帮助连接点并查看整体图片,最后但并非最不重要的一点:它要快得多在设计工具中进行修复而不是在实际代码中进行修复。因此,虽然我不说开发人员应该设计,但某些设计技能可以很好地补充你的工作流程。

坚持原创技术分享,您的支持将鼓励我继续创作!

欢迎关注我的其它发布渠道