现在是星期三的下午 4:42。 我们计划于周一在全球发布,但我的一位支持工程师发现了有关翻译质量的严重错误,涉及我的一种产品语言。 这就像红色警报。
警报响起,自动门自动关闭。 这很重要!
但在我们进入全面紧急模式之前,这里有一些提示,可以帮助您清晰地评估产品发布场景中的语言影响,以便您能更好地决定下一步措施:
1) 第 1 步: 让我们详细查看这些主张的实际优点
通常情况下,人们在评估语言质量时不会一致。 我们看到有人将语法错误标记为严重错误。 术语和拼写也是如此。 当我们查看提出的 bug 时,它们到底是什么?它们最终如何影响用户体验?
对于语言来说,同样的事情对一个人来说可能是不可接受的和错误的,但对另一个人来说可能是可以理解的,但不正确的。 两者都可能将问题视为错误,但程度不同。 也许是前后矛盾。 不管是什么,事实是每一件人类产品都有缺陷——无论它有多好。 这就是作为人类的意义——有缺陷。 因此,在根据一个人如何对这些问题进行分类下结论之前,请让两到三位其他语言专家从用户体验的角度看待这些错误并回答这些问题:
- 这会阻止我使用该应用程序吗?
- 这会对我看待这个品牌的可信度造成不可挽回的损害吗?
如果其中任何一个的答案都是肯定的,那么您确实有一个重大问题需要在发布之前解决。 如果没有,则可以而且应该在发布后解决。 关键的收获是非常细致地分析语言学主张,以真正理解它们是如何分类的以及实际发生了什么。
2)我怎么知道我是否可以在不解决这些问题的情况下启动?
除了引发的 bug 之外,当人们使用该应用程序时,您几乎可以肯定还会引发其他问题,包括语言问题。 也许它们会包括已经提出的相同问题,也许它们将是全新的。
事实是,发布总是一个惊喜,有时在语言上大做文章只是一个简单的逃生阀,人们用它来投射他们对产品性能的整体不安全感。 这是一个很容易的目标。 即使在审查任何给定应用程序的源副本时,我们总是可以查找改进的空间,有时还会发现一些可能有害的模糊性、不一致性和其他需要解决的问题。 但问题是,什么才足够好到可以发布?
我们可以容忍和解决哪些类型的错误,而不会对产品或品牌造成伤害?粗心大意会让产品失败。 但是过度谨慎,或者更糟糕的是,过度强调对用户体验并非绝对关键的项目,可能导致整个产品团队失去对应用程序核心重要性的方向。
3)正确看待事情: 人们希望应用程序、产品或网站能够执行任务。 他们没有从利益相关者或产品经理的角度来看待它。
这很难。 几个月的时间里,你会失去对重要事情的看法。 很快,一切都很重要。 一切都很重要。 一切都是成败在此一举。 失去视角可能会比其他任何事情更能破坏产品发布。 整个团队开始处理一些并非紧急但有人高层认为重要的事情。
现在,真正关键的事情将被错过并淡入背景级别。 更糟糕的是,在游戏后期解决这些非关键错误的过程中,现在您引入了导致产品行为异常或以新的和意外的方式中断的风险。所以底线是,在游戏后期,在发布之前,每个人都会感到不安,而视角是第一个被抛出窗外的东西。 成为看穿动荡的清醒者。
明智地选择你的战斗总是很重要的,但在产品发布之前尤为重要。 构建强大、稳健的流程并信任它。 但 strong 和 robust 意味着每次迭代都会执行测试并且它们通过了。 这并不是因为您与一家出色的翻译公司、一位出色的翻译人员或一位出色的
主题专家合作,作为审校员,事情就一定会变得好。 在进行下一次迭代之前,请评估每一次迭代。 这将为您提供足够的坚固性,让您在压力下承受攻击,而不会感觉一切都在崩溃。
作者:Gabriel Fairman
Gabriel 是 Bureau Works 的创始人兼首席执行官。 他喜欢变化,喜欢吃草。