注意:以下“设计”是指用户体验设计,而不是架构或系统设计。

软件开发过程中有很多东西可以并且应该并行完成。例如,我很长时间认为要求和设计(再次,用户体验设计)被交织在一起,应该一起完成。我不喜欢产品经理的旧瀑布模型做“要求”并将其交给互动设计师,这些设计师“设计”。我在别的地方写了一些关于为什么这是一种过时的产品开发。我遇到的大多数球队似乎都明白了这一点。

我还认为,软件工程团队已经学习了并行测试的价值的软件工程团队进行了巨大进步。工程师写作软件的旧模型然后将其移交给QA人测试实际需要更长,结果不太可靠。像XP这样的敏捷方法了解实现和测试的值。

也就是说,许多团队尝试并行进行的一件事,但不应该是用户体验设计和实现。

有几个原因:

首先,软件团队中有一个动态,重要的是识别。也就是说,一旦实施开始,就会越来越困难地通过您的设计理念工作可能是必要的。部分这是技术 - 工程团队必须基于关于要求和设计的假设基于对需求和设计的假设,而这些早期决策是重要的,并且具有许多后果。部分这是心理 - 一旦团队转移到实施方式,就会有一种心态发生,并且倒退就会激励。部分这是实用的 - 时钟正在滴答,返工并搅拌只是复合球队的压力。因此,即使像敏捷一样的方法倡导着“拥抱改变”,您很快就会发现一些更改比其他更改更多。

其次,用户体验设计对既有可用性和可取性的非常困难的问题,并且为了提出既可用和可取的设计,您需要提前和经常尝试想法。一个共同的响应是“我们在测试期间获得反馈”,或者有敏捷的团队,“我们会在Sprint的尽头测试这个想法。”不幸的是,等待测试一个想法太长了。一个良好的用户体验设计师将在几天内尝试几十个想法和方法,并且甚至在2到4周的冲刺的频率上等待的想法将被衰弱,因为频率也是一个数量级慢。

第三,并与上面有关,我认为要试试一个想法,你需要高保真原型。有些人会争辩说,可以将Beta释放视为原型,或者可以将Sprint的结果视为原型。但即使超出了上面的重点,即将到达那么长时间用于该软件可用于测试,重要的是要意识到原型软件远远不如生产软件。原型软件需要真正一次性。在几个小时内,它需要大大改变。生产软件所必需的是拖动船锚的原型。您还可以发现不同类型的人喜欢编写原型与生产软件。

第四,虽然它往往使释放释放到几个迭代来实现(这降低了风险,提高了质量,并且简化集成),但用户体验往往不是可以在碎片中设计的东西。您必须全面查看用户体验。它必须对每个版本的用户有意义。虽然它很容易“stub out”软件尚未使用,但对于用户体验而言,这并不容易。

Finally, user experience designers don’t necessarily require a lot of time (just as with software engineering, it depends on the methodology they are using, the particular product requirements, and the skills and experience of the specific people), but they do require some time. Even if it’s only a week or two.

如果您尝试在设计的同时开始实施,这就是您几乎肯定会看到的:设计师将在几天内尝试做几周的工作;工程师随着他们等待设计师给他们的东西而焦虑;很快,设计师会不情愿地训练一些猜测,让工程师进入,然后尝试在工程师走得太远地走向路径之前获得一些体面的东西。然而,当他们终于有一些东西时,它会为时已晚,工程师会说“我们可以在下一轮进入它”,但当然,下一轮都有自己的优先事项。设计师对建造和发货的内容感觉不擅长,而且客户也不喜欢结果。

在最糟糕的情况下,设计师得出结论,他们需要为一家优先考虑用户体验的公司工作。

但是,这真的不是一个难以解决的问题。关键是在实现开始之前需要发生用户体验设计。这是一个顺序重要的一种情况。要求和设计在一起,然后实现和测试可以一起发生,然后实现和测试可以一起发生。对于敏捷团队,Sprint应开始定义要求和用户体验设计(仍然处于尽可能少的增量)。它需要对积压中的内容有点更丰富的定义,但团队将更快乐,产品会更好。

请注意,规则的例外是工程师有很多后端基础架构工作的工作。在这种情况下,在定义用户体验时,工程团队可以在此操作。会有一些相互依赖性,但它们可以管理。如果您的用户体验设计师即将撤销,您的工程师将在释放周期或两者上工作,因为这为设计师提供了创建良好设计的积压的时间。

Note also that even though I’m advocating that the requirements and design are done before implementation begins, you will still need at least someone from engineering to review the design work from the start, as it’s critical for them to assess feasibility and costs along the way. This is necessary to inform the design process. Remember that the objective is to ensure that you’ve come up with a product definition that is usable, desirable, and feasible.

根据融合良好的设计,今天有一种显着的混淆,特别是随着敏捷方法的许多团队试验。我认为这是不幸的,只有一些警告和调整,敏捷方法可能是前面使用传统瀑布方法的团队的巨大一步。我保证更多地谈论即将到来的关于这种混乱的根本原因的文章以及如何获得两个世界的最佳原因。

分享这个