团队|准备交接！如何确定开发支持？( 二 )

请别孤军奋战——您需要有人来帮助您。

二、工程师们想看什么？有意义的可交付物当涉及到可交付成果及其演示时，一个好的做法是提前考虑您的受众。想想谁将使用您正在创建的交付物，以及哪些内容对他们来说是重要的。设计师的一个常见问题是，把大量时间和精力花在跨功能团队中没人使用的交付物上。如果问自己”为什么”，您得到的最直接答案是——因为它没用。那么，该如何让它有用呢？
让我们退一步，想想设计交接会议是怎样进行的。通常，设计师会展示设计/原型的最终版本，然后解释整体愿景、功能和设计选择。之后，轮到开发团队提出澄清性问题，有时这些问题会变成一整套不确定因素，如：

这个返回按钮会跳到哪里？
如果用户没有管理员权限会怎么样？他们能看到这个选项吗？
如果我们将来引入更多菜单选项会怎么样？我们如何在 UI 中兼容它？

这样您就明白了，有用的设计交付物的关键，是覆盖整个用户/客户体验。但是，我们如何确保设计涵盖一切？说实话，您可能不会覆盖所有用例，尤其是边缘用例，只要弄弄清楚主流程即可。
开发团队是分析型结构。他们依赖信息和事实，对于他们来说，拥有无需解释的可交付物至关重要。为了清楚地理解设计交付物背后的设计理念和基本原理，它需要具体且切中要害。
1. 端到端用户故事您需要弄清楚的第一件事，是端到端用户故事或设计计划。端到端用户故事的范围比 Jira 的发展故事更广，后者通常针对较大流程中的特定功能或小型任务。它通过为特定用户角色遵循的用例、边缘案例和分步场景提供线索，从而提供整个用户体验的视图。这意味着UX 包含在早期产品概念定义阶段，并确保作品中的功能/产品能够使用户实现其目标。
2. 快乐和不快乐的道路工程师们正在寻找的另一件事是快乐和不快乐的道路。作为需求收集和 IA 阶段的一部分，在项目开始时就规划可交付物是有好处的。快乐路径可以用作检查表，以查看设计中是否涵盖了所有用例。而不快乐路径通过提供错误状态和替代或恢复行程，来帮助开发产品的错误处理策略。
不用担心，这并不意味着您需要映射设计中的每一个错误状态，只需确保精确定位影响用户任务完成的关键路径即可。
3. 资产和组件设计交接的另一个重要部分是资产和组件规范。现在，可以通过像 Figma 这样的端到端设计平台来轻松管理。
允许您使用同一工具进行资产交付、线框图和原型设计。组件和资产易于管理，工程师可以直接从设计文件/库中下载。
不要忘记列出组件度量、填充、大小、状态和使用规则，以便开发团队能够明确说明如何开发它们。FigmaTokens 是一个有用的插件，它可以显示边框半径、颜色、间距单位等，并且可以动态更新您的设计。
4. 原型和动画最后但并非最不重要的是，不要忘记原型和动画（如果有的话）。
在模拟功能或产品开发后的行为时，原型非常有用。这也是测试您的假设和设计假设的好方法。一个好的方法是通过为每个功能制作动态流程，使原型基于功能。您还可以提供有关用户及其角色、假设和场景的一些上下文。这样，您将确保涵盖所有用户用例，并且您已经提前回答了工程师的大部分问题。
5. 技巧

尽量不留任何解释——为使用您设计交付物的受众提供足够多的上下文和明确的指导。
可以向您的团队询问有关可交付物的反馈，并找出哪些最有用，集中精力提供这些。
了解您的产品。作为产品设计师，您有时需要身兼数职并兼顾各种责任。您拥有的跨职能部门的背景越多，您就可以做出更好、更明智的决策。
- 上一页
- 1
- 2
- 3
- 下一页