v-show会预先渲染

by Benek Lisefski

由Benek Lisefski

预先进行Big Design的利弊-我该怎么做 (The pros and cons of Big Design Up Front — and what I do instead)

瀑布可以冲刺吗？ 灵缇犬可以放慢速度吗？ (Can a waterfall sprint? Can a greyhound slow down?)

I’ve run my own independent design business for 18 years. Starting back when waterfall was all we had, then transitioning to extreme agile, and all the variations in between.

我经营自己的独立设计业务已有18年。 从我们拥有的瀑布开始，然后过渡到极度敏捷，以及介于两者之间的所有变化。

As a freelancer, I work for a variety of clients — large and small — on a broad range of digital products: from simple brochure websites to complex web and mobile apps. I still use a BDUF waterfall process when it suits the project. Other times the atmosphere demands a highly iterative and agile approach.

作为自由职业者，我为各种规模的数字产品的各种规模的客户服务，从简单的手册网站到复杂的Web和移动应用程序。 当项目适合我时，我仍将使用BDUF瀑布处理。 其他时间，大气层则需要高度迭代和敏捷的方法。

I often switch between these polar-opposite design methodologies on a daily basis, as I shift focus from one project to another. It’s helped me adapt to both, and realise the strengths and weaknesses of each process. Practising both methodologies regularly makes me uniquely positioned to understand when one works better than the other. And it’s got me thinking about whether BDUF still has a place in the modern design and development world.

当我将重点从一个项目转移到另一个项目时，我经常每天在这些对立的设计方法之间进行切换。 它帮助我既适应又适应了每个过程的优点和缺点。 定期练习这两种方法，使我在了解一种方法何时比另一种方法更好时处于独特的位置。 这让我开始思考BDUF是否在现代设计和开发领域中仍然占有一席之地。

Before we discuss BDUF vs. Agile, let’s start with a few definitions:

在讨论BDUF vs. Agile之前，让我们从一些定义开始：

瀑布 (Waterfall)

A relatively linear sequential design approach where progress flows in largely one direction (“downwards” like a waterfall) through the phases of research, conception, design, construction, testing, deployment and maintenance.

一种相对线性的顺序设计方法，在研究，构思，设计，构造，测试，部署和维护的各个阶段中，进度主要沿一个方向(“向下”如瀑布)流动。

放大或缩小 (Zooming in or out)

In design, zooming out means focusing on the wholeness of a design system, evaluating its effectiveness, and ensuring it works together consistently and harmoniously.

在设计中，缩小意味着专注于整个设计系统，评估其有效性并确保其始终如一地和谐地工作。

Zooming in is the act of focusing on a smaller piece of the whole — a feature, page, user flow, etc.— hands-on design work that crafts individual design solutions.

放大是将重点放在整个较小的部分(功能，页面，用户流程等)上的行为，这些动手的设计工作是在精心设计单个设计解决方案。

迭代 (Iteration)

A cyclic process of prototyping, testing, analysing, and refining a product or process. Based on the results of stakeholder feedback or testing, changes and refinements are made.

原型制作，测试，分析和完善产品或过程的循环过程。 根据利益相关者反馈或测试的结果，进行更改和完善。

积分 (Integration)

An act of combining into an integral whole.

结合成一体的行为

成本，便宜，昂贵 (Cost, cheap, expensive)

In this context, it refers to the time and effort spent on design or development, not necessarily a direct relation to monetary cost.

在本文中，它指的是在设计或开发上花费的时间和精力，不一定与金钱成本直接相关。

工程，开发，编码 (Engineering, development, coding)

Used somewhat interchangeably — to draw the line between where design stops and technical implementation begins.

可以互换使用-在设计停止和技术实施开始之间划清界限。

什么是BDUF？ (What is BDUF?)

Big Design Up Front is an approach where a website, app, or software design is completed and perfected up-front, before its implementation is started. It necessitates a waterfall process, and relies on prediction. This was the prevailing methodology for decades before the advent of Agile. Websites and software used to be very expensive to build, so it was necessary to iron out as many kinks as possible before the costly engineering happened.

前端大设计是一种在开始实施之前就完成并完善网站，应用程序或软件设计的方法。 它需要瀑布过程，并依赖于预测 。 在敏捷出现之前的几十年中，这一直是流行的方法。 网站和软件的构建过去非常昂贵，因此有必要在成本高昂的工程发生之前消除尽可能多的麻烦。

Think of it like charting the course of a ship. If you already know the route, the weather, the currents and tides, you can plan the trip before you hit the water. Once you leave port you don’t have to waste time getting your bearings.

可以将其视为绘制船舶航向的图表。 如果您已经知道路线，天气，水流和潮汐，则可以在下水之前计划行程。 离开港口后，您不必浪费时间来获取轴承。

Designers who’ve been around longer than a decade — or work outside of the Silicon Valley “product” bubble — probably honed their craft using BDUF. It’s their design comfort zone.

已有十多年历史的设计师-或在硅谷“产品”泡沫之外工作的设计师-可能使用BDUF磨练了自己的Craft.io。 这是他们的设计舒适区。

BDUF假设 (BDUF assumptions)

• We can fully know the goals, requirements, and scope of design up front — and these are unlikely to experience significant changes.我们可以完全了解设计的目标，要求和范围，而这些都不大可能发生重大变化。
• Design revisions are generally harder and more expensive to make after code has been written. Efficiency is gained by sorting out as much as possible in design.在编写代码之后，设计修订通常会更困难且成本更高。 通过尽可能多地选择设计来提高效率。
• We can and must judge if a design solution is good or effective before it’s fully functional.我们可以并且必须判断设计解决方案在其完全起作用之前是好的还是有效的。
• Engineers can pinpoint development challenges while still in design, so we can find alternative design solutions before hitting code.工程师可以在仍处于设计阶段时就查明开发挑战，因此我们在找到代码之前可以找到替代的设计解决方案。
• If left to their own devices, engineers will make a mess of things. Design needs to lead the way or UX and aesthetics will suffer.如果任由自己的设备使用，工程师们将一团糟。 设计需要引领方式，否则用户体验和美学将受到影响。

BDUF的优势 (BDUF strengths)

• If you know exactly what you want, this is the most efficient way to get there.如果您确切地知道自己想要什么，这是到达那里的最有效方法。
• Since all design is done at once, there’s ample opportunity for zooming out, integrating often, and designing holistically.由于所有设计都是一次性完成的，因此有足够的机会进行缩小，经常集成和整体设计。
• User experience is designed and refined by designers, and that design documentation dictates the functionality for engineers to develop. Each role plays to their strengths.用户体验是由设计师设计和完善的，设计文档规定了工程师进行开发的功能。 每个角色都发挥自己的优势。
• Easy to cost and schedule design, as it’s a known quantity from the start.易于成本和计划设计，因为从一开始它就是一个已知的数量。

BDUF的弱点 (BDUF weaknesses)

• Not easily adaptable to changes in scope, or pivots in purpose. You may have to swim back up the waterfall to start again if goals or requirements move.不容易适应范围的变化或目的的变化。 如果目标或要求发生变化，您可能必须游回瀑布才能重新开始。
• Design is not as easily tested and validated, because no part of it is fully functional until near the end of the linear process.设计不那么容易测试和验证，因为直到线性过程快要结束时，设计的任何部分才能发挥全部功能。
• Doesn’t take advantage of new learnings or better solutions that may arise during later stages of the waterfall process.不要利用瀑布过程后期可能出现的新知识或更好的解决方案。

敏捷与新兴设计 (Agile & Emergent Design)

The agile development methodology was designed for complex, non-deterministic, non-linear projects. It prioritises being adaptive rather than predictive, reducing the leap of faith that’s needed before evidence is obtained.

敏捷开发方法论是为复杂，不确定性，非线性项目设计的。 它优先考虑的是适应性而非预测性 ，减少了获得证据之前所需的信念飞跃。

Agile aims to break a project down into smaller chunks. Cross-functional teams then use sprints with short-time frames to work through accelerated versions of the entire waterfall process — with the goal to design, produce, and test something in each sprint. Their learnings are then integrated into the project’s evolving scope, and help shape the direction of the next sprints and iterations.

敏捷旨在将项目分解为较小的块。 跨职能团队然后使用具有短时帧的sprint来完成整个瀑布过程的加速版本-目的是设计，生产和测试每个sprint中的某些内容。 然后，他们的学习将被整合到项目不断发展的范围中，并帮助确定下一个冲刺和迭代的方向。

If BDUF is a very well-documented trip planned in advance, Agile is getting your ship out of the port with only a vague idea of where you’re going, and then exploring, planning and adapting in the water. It’s a series of small bets rather than a single well-calculated wager.

如果BDUF是事先有充分记录的旅行计划，那么敏捷会将您的船驶离港口，只带一个模糊的想法，告诉您要去的地方，然后在水中进行探索，计划和适应。 这是一系列的小赌注，而不是一个经过精心计算的赌注。

The Manifesto for Agile Software Development is based on twelve principles (via Wikipedia):

敏捷软件开发宣言基于十二个原则(通过Wikipedia )：

1. Customer satisfaction by early and continuous delivery of valuable software.通过尽早连续交付有价值的软件来使客户满意。
2. Welcome changing requirements, even in late development.即使在后期开发中，也欢迎不断变化的需求。
3. Deliver working software frequently (weeks rather than months)频繁交付工作软件(数周而不是数月)
4. Close, daily cooperation between business people and developers商界人士与开发人员之间的紧密日常合作
5. Projects are built around motivated individuals, who should be trusted项目是围绕积极进取的个人建立的，应该值得信任
6. Face-to-face conversation is the best form of communication (co-location)面对面的对话是最好的交流方式(同一地点)
7. Working software is the primary measure of progress工作软件是进度的主要衡量标准
8. Sustainable development, able to maintain a constant pace可持续发展，能够保持稳定的步伐
9. Continuous attention to technical excellence and good design持续关注技术卓越和良好的设计
10. Simplicity — the art of maximizing the amount of work not done — is essential简单性-最大化未完成工作量的艺术-必不可少
11. Best architectures, requirements, and designs emerge from self-organizing teams自组织团队会提供最佳的架构，需求和设计
12. Regularly, the team reflects on how to become more effective, and adjusts accordingly团队定期思考如何提高效率，并做出相应调整

紧急设计 (Emergent Design)

Agile methodologies require a new way of thinking which has been described as emergent design. Emergent design aims to do the opposite as BDUF — minimal or no design up front so we can get to shipping, testing, and validating as quickly as possible.

敏捷方法学要求一种新的思维方式，这种方式被描述为紧急设计 。 紧急设计的目的与BDUF相反-预先设计很少或没有设计，因此我们可以尽快进行发货，测试和验证。

紧急设计假设 (Emergent design assumptions)

• We can’t fully understand the problem or its ideal solution without a lot of testing and learning. The requirements and design must be deduced, so it’s better to start building the testing ASAP.

  没有大量的测试和学习，我们就无法完全理解问题或其理想的解决方案。 必须推导出需求和设计，因此最好尽快构建测试。

• Change is cheaper in code than it is during design. (Or at least equally expensive).与设计相比，代码更改便宜。 (或至少同样昂贵)。
• Design cannot be judged or validated until it’s built and usable in the real world.在现实世界中构建并使用设计之前，无法对其进行判断或验证。
• Designers may create technically impossible or expensive solutions if their work isn’t frequently integrated and tested.如果他们的工作不经常被集成和测试，设计师可能会创建技术上不可能或昂贵的解决方案。

• Too much design up front (and any documentation) is wasted effort, as requirements will change or new solutions will emerge before that design is even implemented.

  过多的设计工作(以及任何文档)都浪费了精力，因为在实施该设计方案之前，需求将发生变化或出现新的解决方案。

新兴的设计优势 (Emergent design strengths)

• Design evolves over time and can take advantage of new learnings.设计会随着时间的流逝而发展，并可以利用新的知识。

• Design is a collaborative effort and not a solo, reclusive process. As Manuel Dahm said: “This requires the designer to move from the lonely ivory tower of creative genius into the shared apartment of the team mind.”

  设计是一种协作而不是一个单独的，隐蔽的过程。 正如曼努埃尔·达姆(Manuel Dahm)所说 ： “这要求设计师从创意天才的孤独象牙塔搬到团队思维的共同单元。”

• Design and development happen in parallel, which facilitates tremendous cross-team collaboration and rapid problem-solving. Fires can be put out at the first sign of smoke.设计和开发是并行进行的，这促进了巨大的跨团队协作和快速的问题解决。 冒烟时可以扑灭大火。
• Little is left to assumption or intuition. Design is only implemented if it’s proven by data to succeed. Uncertainty about design effectiveness is removed.几乎没有任何假设或直觉。 只有通过数据证明成功，才能实施设计。 消除了对设计有效性的不确定性。

紧急设计的弱点 (Emergent design weaknesses)

• Agile can be too output-focused, and encourages the feature factory.敏捷可能过于注重输出，并鼓励功能工厂。
• Ironically, the context of sprints allows for more frequent integration on the macro level, but provides fewer opportunities for deep, holistic design thinking. Too much narrow focus and not enough wide vision means less chance for integration on the level of design systems. This can lead to a mediocre, inconsistent design which lacks polish and wholeness.具有讽刺意味的是，冲刺的上下文允许在宏级别上进行更频繁的集成，但为深入的整体设计思想提供的机会较少。 焦点过于狭窄，视野不足，意味着在设计系统层面进行集成的机会较小。 这会导致平庸，不一致的设计，缺乏抛光感和整体性。
• Design is difficult to cost because it’s a moving target dictated by stakeholder feedback and sprint cycles. Full scope of design may not emerge until halfway (or further) through a project.设计是很难实现成本的，因为它是利益相关者反馈和冲刺周期所决定的目标。 直到项目进行到一半(或更长时间)时，才可能出现完整的设计范围。

• The sprint and repeat cycle often concludes when “good enough” design emerges. Then it ships without much opportunity to elevate design past mediocrity. Designers lose their priorities of quality control when decision are dictated by data alone.

  当“足够好”的设计出现时， 冲刺和重复周期通常会结束。 然后，它没有太多机会将设计提升到平庸。 当决策仅由数据决定时，设计师就失去了质量控制的优先顺序。

刚做好足够的设计 (Just Enough Design Up Front)

“Big design up front is dumb, but doing no design up front is even dumber.”

“前期的大设计是愚蠢的，但是前期的设计甚至是愚蠢的。”

– Dave Thomas

–戴夫·托马斯(Dave Thomas)

I used to think agile was the enemy of good design, but then I realised it’s just that bad agile doesn’t leave room for good design. I resisted embracing an agile way or working because many of my experiences highlighted the weaknesses of emergent design, and didn’t make up for them with their strengths.

我曾经以为敏捷是好的设计的敌人，但后来我意识到， 糟糕的敏捷并没有为好的设计留出空间。 我拒绝接受敏捷方法或工作方式，因为我的许多经验都强调了新兴设计的弱点，并且没有用它们的优势来弥补它们。

In Is Agile the Enemy (of Good Design)?, John Cutler says “Good” waterfall beats abused Agile any day.

在“敏捷的敌人(好的设计)中”吗？ ，约翰·卡特勒(John Cutler)说， “好”的瀑布每天都在击败滥用敏捷的人。

I would have to agree.

我将不得不同意。

Any product development methodology is trying to answer design questions when it’s cheapest to do so. Agile supporters strongly believe it’s cheapest in small increments during short sprints. BDUF works when it’s cheapest up front and considered as a wholeness. But neither of them work for designers when they don’t produce a good design result.

任何产品开发方法论都试图在最便宜的时候回答设计问题 。 敏捷的支持者坚信，在短距离冲刺期间，它以小幅增加的价格最便宜。 BDUF在最便宜的时候就可以正常工作。 但是当他们不能产生好的设计结果时，他们都不适合设计师 。

I don’t believe either BDUF or Agile find the right balance. It’s somewhere in between. Therefore my preferred design methodology is Just Enough Design Up Front (JEDUF).

我不相信BDUF或Agile都能找到合适的平衡点。 它介于两者之间。 因此，我首选的设计方法是“足够的前端设计”(JEDUF)。

JEDUF进行救援 (JEDUF to the rescue)

JEDUF recognises that some overarching design is required in order to enable more detailed work. We can’t always shoot from the hip with “cowboy development”. First, we need a few goalposts. We need architecture and design to create a foundation for our sprints.

JEDUF认识到需要一些总体设计才能进行更详细的工作。 我们不能总是用“牛仔发展”从臀部射击。 首先，我们需要一些目标。 我们需要架构和设计来为我们的sprint建立基础。

• Early design work can be rough, but should always be as good as it can be, given the available information at the time. Yes, much more design work will have to emerge later, but we don’t want to redo any design if we can get it right the first time.早期的设计工作可能很艰巨，但鉴于当时可用的信息，应该总是尽可能的好。 是的，以后将不得不进行更多的设计工作，但是如果我们能在第一时间找到正确的设计，我们就不想重做。
• Up-front design should be considered the most fundamental aspects of a project or product, so it informs the priorities to build and test during early sprints. In other terms, identify the highest risks, and then design for them first. This lays the foundation for a design system, stress-tested early and often by developed pieces of highest value. Some call this necessary up-front design the “primitive whole”.前期设计应被视为项目或产品的最基本方面，因此它可以告知在早期冲刺阶段进行构建和测试的优先级。 换句话说，先确定最高风险，然后再针对这些风险进行设计。 这为设计系统奠定了基础，该设计系统会在早期进行压力测试，并经常通过最高价值的已开发产品进行测试。 有人称此必要的前期设计为“原始整体”。

超越JEDUF (Beyond JEDUF)

My own version of JEDUF includes opportunities for design decompression and integration at various stages during the project. I call it Just Enough Design Up Front & Middle.

我自己的JEDUF版本包括在项目的各个阶段进行设计解压缩和集成的机会。 我把它叫做“足够设计” 。

JEDUF&M balances small sprints — zoomed-in focus — and opportunities for holistic design integration from a wide perspective. When a critical mass of functionality has emerged, the sprint cycle can be paused for deeper design to be considered.

JEDUF＆M可以在较小的冲刺(放大的焦点)和广泛的集成设计机会之间找到平衡。 当出现大量功能时，可以暂停冲刺周期，以考虑进行更深入的设计。

Think of it like another up-front design session, only its goals are about cohesion rather than exploration. Once the design system feels holistic and under control — integrating and harmonising the revisions from previous sprints and learnings — the next round of sprints begins. It’s up to the designer to recognise when the need for a “middle” design break is required, and not let the project get too caught up in the minutiae.

将其视为另一个前期设计会议，只是其目标是凝聚力而不是探索 。 一旦设计系统感到整体性和可控制性(整合并协调来自先前冲刺和学习的修订)，下一轮冲刺就开始了。 由设计者决定何时需要“中间”设计中断，而不是让项目陷入细节之中。

I’ve found JEDUF&M to be the ultimate design methodology. It balances the adaptiveness, quick iterations, and focus on validation which makes agile so powerful — while also allowing for periods of rest, integration, and holistic design system thinking that can get lost among sprints and feature delivery.

我发现JEDUF＆M是最终的设计方法。 它平衡了适应性，快速迭代并专注于验证，这使敏捷变得如此强大-同时还允许进行休息，集成和整体设计系统思考，而这可能会在sprint和功能交付中迷失。

If, even under this ideal balance of methodologies, you find yourself anxious about the number of uncertainties, think of it this way instead: embrace the uncertainty. Now you’re in a position to shape what those constraints become, rather than having them predetermined and dictated to you. This is more responsibility, but also more flexibility. If you handle that role with aplomb, you’ll deliver a result with no regrets or compromises, even if the process is more challenging along the way.

如果即使在这种理想的方法论平衡下，您仍然对不确定性的数量感到焦虑，那么请以这种方式思考： 拥抱不确定性 。 现在， 您可以调整这些约束变成什么 ，而不是预先确定和指示给您。 这既是责任，又是更大的灵活性。 如果您坚定地处理这个角色，即使过程中更具挑战性，您也将毫不后悔或妥协地取得成果。

BDUF还有足够的空间 (There’s still plenty of room for BDUF)

You can’t afford to dismiss this dinosaur completely. Big Design Up Front is a very valid and efficient model when used on the right projects.

您无法完全消除这种恐龙。 当在正确的项目上使用时，Big Design Up Front是一个非常有效的模型。

The benefit of up-front design increases as the system complexity decreases.

随着系统复杂度的降低，前期设计的好处也会增加。

Not all designers are working on complex, enterprise apps, with variable stakeholder goals and uncertain solutions. Not every project requires massive exploration, testing, and customer validation.

并非所有的设计师都在开发复杂的，具有不同利益相关者目标和不确定解决方案的企业应用程序。 并非每个项目都需要大量的探索，测试和客户验证。

I can’t imagine taking an agile approach to designing and building a simple brochure or portfolio website. My clients would think I’m mad. In these cases, BDUF is still alive and kicking.

我无法想象采用敏捷方法来设计和构建简单的小册子或投资组合网站。 我的客户会以为我很生气。 在这些情况下，BDUF仍然活着并在不断发展。

BDUF and Agile are two ends of a single spectrum. Identify what you need to validate before, during, and after you build, and then tailor your process to facilitate the right design at the right time. Most projects will fall somewhere in the middle of the spectrum, not the radical fringes.

BDUF和敏捷是单个频谱的两端。 在构建之前，之中和之后确定需要验证的内容，然后定制过程以在正确的时间进行正确的设计。 大多数项目将落在中间位置，而不是激进边缘。

And let’s not forget that the waterfall process doesn’t have to be as rigid and linear as its critics make it out to be. BDUF can still “deliver early and often”, collect stakeholder feedback, iterate rapidly, and evolve over time. It’s just that this evolution happens completely in the realm of design.

而且，请不要忘记瀑布过程不必像批评家所言的那样僵化而线性。 BDUF仍然可以“尽早并经常”交付，收集利益相关者的反馈，快速迭代并随着时间的推移而发展。 只是这种演变完全发生在设计领域。

We can make mini-waterfalls within our big waterfall. There are plenty of useful ways to achieve small validations and move forward without an entire cross-functional team pushing it straight into code and rushing to ship.

我们可以在我们的大瀑布内制作迷你瀑布。 有许多有用的方法可以进行小规模验证并继续前进，而无需整个跨职能团队将其直接推入代码并匆匆交付。

BDUF doesn’t mean there’s no ability to learn, adapt, and improve design through feedback and iteration. If that’s what you think BDUF is, maybe you’ve been doing it wrong all these years?

BDUF并不意味着没有能力通过反馈和迭代来学习，适应和改进设计。 如果您以为BDUF就是这样，也许这些年来您一直做错了？

Please ? clap if you found this valuable, and ? follow me for more writing like this, as I unfold 18 years of freelance design knowledge ?

拜托 c 圈，如果您觉得这很有价值，并且？ 当我展现了18年的自由设计知识时，可以花更多的钱来吸引我吗？

订阅即可在收件箱中获得我最好的文章。 (Subscribe to get my best articles in your inbox.)

This story can also be found on solowork.co

这个故事也可以在solowork.co上找到

翻译自: https://www.freecodecamp.org/news/the-pros-and-cons-of-big-design-up-front-and-what-i-do-instead-375f00542dec/

v-show会预先渲染