程序猿移交工作文档
Hand-offs have always been tricky. We’ve come a long way from “creating sprites” — if you know you know — to having tools like Zeplin and Avocode at our disposal. We’ve come a few steps further by supplementing hand-offs with (design) documentation. In some cases, extending this even further, with code (CSS, ew). These seemingly simple and disjointed pieces have created a need for better processes; processes that ensure smooth, predictable, and effective hand-offs.
上下车总是很棘手的。 从“创建sprite”(如果您知道的话)到我们可以使用Zeplin和Avocode之类的工具，我们已经走了很长一段路。 通过向交接文件(设计)进行补充，我们又走了几步。 在某些情况下，可以使用代码(CSS，ew)将其进一步扩展。 这些看似简单且不连贯的碎片导致了对更好流程的需求。 确保顺利，可预测和有效的交接的流程。
我是谁？ (Who am I?)
I work as a design consultant with SupportBee — a collaborative customer support tool. My role is to ensure that we push features we’re proud of and have everything in place to make them better with time. SupportBee is a remote-first company with five employees across four different time zones.
我是协作客户支持工具SupportBee的设计顾问。 我的职责是确保我们推出引以为傲的功能，并准备就绪以使它们随着时间的推移而不断完善。 SupportBee是一家远程第一公司，在四个不同时区拥有五名员工。
我如何确保“良好的交接”？ (How do I to ensure ‘good hand-off’?)
What I’ll write today may not apply to some of you since we’re a small team. But what we’ve realized is that there’s no foolproof way to ensure 100% successful hand-off. It’s a process that needs work, time, and feedback/participation from your colleagues.
由于我们是一个小团队，我今天要写的内容可能不适用于你们中的某些人。 但是我们已经意识到，没有万无一失的方法来确保100％成功的交接。 这个过程需要您的工作，时间以及同事的反馈/参与。
Having said that, the following points go a long way to ensure you have a few of the bases covered.
话虽这么说，以下几点可以确保您掌握一些基础知识。
- Spec (optional) 规格(可选)
- Communication 通讯
- Documentation 文献资料
We’ve all heard these terms before. For this article though, I’ll focus on documentation and how we achieve it as a remote company. But first, I’ll start by defining what the above-mentioned terms mean for us.
我们以前都听说过这些术语。 但是，对于本文，我将重点介绍文档以及如何作为远程公司实现它。 但是首先，我将从定义上述术语对我们的意义开始。
A simple visual representation of what the process looks like
流程外观的简单直观表示
Spec (optional): Writing a spec document is one of the many entry points to solving a design problem. It generally entails what we, as a team, believe are the task(s) to finish in order to solve the larger problem. These tasks can be granular or far-reaching, and depends on the problem we’re solving.
规范(可选) ：编写规范文档是解决设计问题的众多切入点之一。 通常，作为一个团队，我们需要相信完成解决更大问题的任务。 这些任务可能是细粒度的，也可能是影响深远的，并且取决于我们正在解决的问题。
Communication: While working on a design solution, we’ve made it a habit to continuously share our work. I do not wait till a solution is “complete”, because it never is. I share the “smallest understandable solution”; from rough sketches and IA, to explaining feature flows with just annotated boxes. Anything that helps us validate our idea with the team as early as possible. We repeat this process; and with each iteration, we add more details to the solutions.
沟通 ：在设计解决方案时，我们养成了不断分享我们的工作的习惯。 我不会等到解决方案“完成”，因为它永远不会。 我分享“最小的可理解的解决方案”； 从粗略的草图和IA到仅用带注释的框说明特征流。 任何可以帮助我们尽早与团队一起验证我们想法的事物。 我们重复这个过程； 每次迭代时，我们都会在解决方案中添加更多细节。
Documentation: At SupportBee, our documentation enables us to push a feature to production. It also ensures we have everything in place to make the feature better, over time.
文档 ：在SupportBee，我们的文档使我们能够将功能推入生产环境。 随着时间的流逝，它还确保我们拥有使功能更好的一切。
识别挑战 (Identifying challenges)
Writing good and clean hand-off documentation is hard. At the same time, trying to retrofit someone else’s template to your process may do more harm than good. To ensure you have a good hand-off process, start by identifying the challenges at your workplace.
编写良好而干净的交接文档非常困难。 同时，尝试将其他人的模板改造为您的过程可能弊大于利。 为了确保您拥有良好的交接流程，请首先确定工作场所中的挑战。
As a remote designer, I don’t get to be in the same room as our developer(s). I, sometimes, have to wait for hours to get feedback because of timezone differences. On account of which, our documentation needs to be crisp yet elaborate to avoid communication gaps. The more gaps there are, the harder it gets to roll things out. The slower we roll things out, the more expensive it gets for us.
作为远程设计师，我不必和我们的开发人员呆在同一个房间。 由于时区不同，有时我必须等待几个小时才能获得反馈。 因此，我们的文档需要简洁明了，以避免沟通空白。 差距越大，推出产品的难度就越大。 我们推出产品的速度越慢，对我们来说就越昂贵。
Once we identified the challenges, we worked towards developing an ‘approachable & inclusive solution’. A solution that allows anyone on our team to come on-board, contribute, and (maybe) leave.
一旦我们确定了挑战，我们就会努力开发一种“可行且包容的解决方案”。 一种允许我们团队中的任何人加入，贡献和(也许)离开的解决方案。
文献资料 (Documentation)
At SupportBee we use Figma and Notion for design hand-off. I spent time walking the team through features of both tools, teaching them how to inspect designs and leave feedback/comments.
在SupportBee，我们使用Figma和Notion进行设计移交。 我花了时间在团队中介绍这两种工具的功能，并教他们如何检查设计并留下反馈/意见。
Following is how we’ve setup our tools. Again, our goal was to make sure the tools aren’t a hindrance and the end result is effective and useful.
以下是我们如何设置工具。 同样，我们的目标是确保工具不会成为障碍，并且最终结果是有效且有用的。
Figma： 设置 (Figma: Setting up)
I foresaw a possibility of Figma getting overwhelming for our developer (Josue) to use. My approach was to add a separate ‘hand-off’ section in Figma, and invite Josue only to this section. Every file I work on, once completed, moves from my workspace(s) to the ‘hand-off’ section; and Josue has access to it. Each feature has its own file, and there’s only one instance of it throughout the system.
我预见到Figma可能会淹没我们的开发人员(Josue)使用。 我的方法是在Figma中添加一个单独的“移交”部分，并仅邀请Josue参加该部分。 我处理的每个文件一旦完成，就会从我的工作区移至“移交”部分； Josue可以访问它。 每个功能都有其自己的文件，并且在整个系统中只有一个实例。
Note: Try not to duplicate files. Duplicating gets us back to ‘_v12_final_final’ practice that we’ve managed to escape. Any improvement to an existing feature should exist as a new (separate) file. If improvements are a part of existing files, it’s easy to lose track of the progress made.
注意：尽量不要重复文件。 复制使我们回到了设法逃脱的“ _v12_final_final”实践。 对现有功能的任何改进都应以新文件(单独的文件)存在。 如果改进是现有文件的一部分，则很容易丢失进度。
For each file, we have separate pages — viz.‘internal critique’, ‘competitor references/analysis’, ‘wireframes’, ‘visual design’, ‘mobile’. In the ‘hand-off’ workspace we added an extra page, ‘for dev’, which has the latest designs and prototype.
对于每个文件，我们都有单独的页面-即“内部评论”，“竞争对手参考/分析”，“线框”，“视觉设计”，“移动”。 在“交接”工作空间中，我们添加了一个额外的页面，“ for dev”，其中包含最新的设计和原型。
批注设计 (Annotating designs)
Adding context to designs is something we incorporated very late in our process. But we see the value it provides and only wish we’d done it earlier. Sharing designs without context make them very hard to understand and navigate through.
在设计过程的后期，我们加入了设计的上下文。 但是我们看到了它提供的价值，只希望我们早点做到。 在没有上下文的情况下共享设计会使它们很难理解和浏览。
Here’s an example, in SupportBee — a collaborative customer support tool. An admin/agent can assign a support ticket to another agent.
这是一个在SupportBee中的示例-协作式客户支持工具。 管理员/代理可以将支持票证分配给另一个代理。
The design file has just enough information to tell Josue what to keep in mind while developing. Everything else, all the details, sit on Notion.
该设计文件仅具有足够的信息，可以告诉Josue在开发过程中要记住什么。 其他所有内容，包括所有细节，均位于概念上。
参与所有人并分享您的工作 (Involve everyone and share your work)
To answer this, I’ll refer to ‘Comments’ feature. ‘Comments’ in SupportBee is a first-class feature, it allows users to privately discuss a ticket with their colleagues.
为了回答这个问题，我将参考“评论”功能。 SupportBee中的“评论”是一流的功能，它使用户可以与同事私下讨论票证。
With ‘Comments’, we made some critical errors and pushed out a solution that wasn’t usable at all. We went back to the drawing board with a vigor and drive to fix this.
借助“注释”，我们犯了一些严重错误，并推出了根本无法使用的解决方案。 我们充满活力地回到了绘图板上，并努力解决此问题。
Here’s an early prototype that I shared with the team to validate some of my ideas.
这是我与团队共享的一个早期原型，用于验证我的一些想法。
A lot of what you see in the video didn’t get implemented but that highlights the importance of sharing early. Your team will help you shut-down ideas that aren’t worth pursuing and/or don’t work well with the product.
您在视频中看到的很多内容都没有实现，但这突出了及早共享的重要性。 您的团队将帮助您关闭不值得追求的想法和/或与产品搭配不当的想法。
In the prototype, I’ve also omitted a lot of the design details to focus only on what’s important. This approach is especially important for remote teams… don’t sit on perfecting an idea for weeks before you share it. Working in silos will slow your team down, and more importantly, isn’t a collaborative process.
在原型中，我也省略了许多设计细节，只专注于重要的方面。 对于远程团队来说，这种方法尤为重要……在分享想法之前，不要坐下来完善想法。 孤岛工作会使您的团队慢下来，更重要的是，这不是协作过程。
概念： 设置 (Notion: Setting up)
There are many ways to setup Notion for design-dev hand-off. Our hand-off doc looks something like this:
有许多方法可以设置用于Design-dev交付的Notion。 我们的交接文档如下所示：
- Why are we (re)designing this? 我们为什么要(重新)设计这个？
- What do we want to acheive with this (re)design? 我们要用这个(重新)设计实现什么？
- Metrics to track 跟踪指标
- Roll-out plan 推出计划
The goal with Notion, for us, is to answer the above questions with short and clear answers. Let these answers not be philosophical, be as objective as you should be. Answers should be unambiguous and communicate intentions and decisions as clearly as possible
对我们而言，Notion的目标是用简短明了的答案回答以上问题。 让这些答案不是哲学上的，应尽可能客观地做到。 答案应明确，并尽可能清晰地传达意图和决定
Taking the same example of ‘Assigning a ticket’. This is what our Notion doc looks like:
以“分配票证”为例。 这是我们的概念文档的样子：
Along with the above-mentioned questions, our notion also has the following:
除了上述问题之外，我们的概念还具有以下特点：
- Sketches 草图
- Wireframes 线框
- Hi-fidelity designs 高保真设计
- Hi-fidelity flows/prototypes (optional) 高保真流程/原型(可选)
Going back to the ‘Comments’ feature… I focus on the smaller interactions and flows rather than create one big prototype. I also add all different (annotated) scenarios. Here’s what they look like.
回到“评论”功能……我专注于较小的交互和流程，而不是创建一个大型原型。 我还添加了所有不同的(带注释)方案。 这是他们的样子。
Here are some of the flows:
以下是一些流程：
What’s important to note here is that, including the design and prototypes, we covered (almost) all use-cases for this feature so Josue has a clear idea before he begins. Leaving anything up for assumption increases the back-and-forth between me and Josue, thus increasing the time it takes to push a feature out.
这里要注意的重要一点是，包括设计和原型在内，我们涵盖了(几乎)此功能的所有用例，因此Josue在开始之前就有了一个清晰的主意。 不做任何假设就增加了我和Josue之间的来回往返，从而增加了推出功能所需的时间。
Take your time, slow down. It’s okay to work slow and make sure you push a solid product than work hastily and not push your best work.
慢慢来，慢一点。 可以慢工作，并确保您比匆忙工作要推稳产品，而不要尽力而为。
Vision without action is a daydream. Action without vision is a nightmare
视而不见是白日梦。 没有视力的行动是一场噩梦
结论 (Conclusion)
Design hand-off has been tricky for a very long time. We started with very minimal, yet flexible, documentation and kept building on what we had to get this far. And it’s only been possible because of the constant feedback I’ve received from our developers. Your colleagues will help and give you feedback, it is in their interest to do so; don’t shy away from asking them for help.
设计交接已经很长时间了。 我们以非常少而又灵活的文档开始，并且在此基础上不断发展。 这是有可能的，因为我一直从我们的开发人员那里得到反馈。 您的同事将帮助您并给您反馈，这样做符合他们的利益； 不要回避寻求他们的帮助。
If you’ve made it this far, I’d like to point you to a blog post and presentation that might help you adopt a better hand-off and documentation process.
如果您已经做到了这一点，那么我想为您指出一个博客文章和演示文稿，它们可以帮助您采用更好的交付和文档编制流程。
Priyanka Godbole’s thoughtful article on faster design-dev handoff
Priyanka Godbole关于更快的设计-开发移交的深思熟虑的文章
Hardik Pandya’s excellent presentation on how he developed his documentation template.
Hardik Pandya关于如何开发文档模板的出色演讲。
I’d like to thank @Kenneth, @kingsidharth, Steven Deobald, and Sanket Pathak for helping me push the article out 🎉
我要感谢@ Kenneth， @ kingsidharth， Steven Deobald和Sanket Pathak帮助我将文章发布出去🎉
翻译自: https://uxdesign.cc/design-hand-off-documentation-as-a-remote-company-7ef49e9eac25
程序猿移交工作文档
转播
