线框图是否过度规划？
37 Signal 的《Getting Real》让我相信，线框图和编写功能规范文档对于构建 Web 应用程序和动态网站来说是不必要的中间人步骤。
这些步骤的开销值得吗？ 在 HTML/CSS 甚至 PhotoShop 文档中制作原型（以便设计人员可以直接对其进行处理）是否比使用 Visio 等软件更好？ 就我个人而言，我倾向于后者，但不确定。
37 Signal's Getting Real convinced me that wireframing and writing functional specification documents are middleman steps unnecessary for building web applications and dynamic websites.
Is the overhead for these steps worth its weight? Is prototyping in HTML/CSS or even PhotoShop documents (so designers can work on them directly) a better option than using software like Visio? Personally, I am swaying towards the latter but am not sure.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
“没有计划就是计划失败”——或者类似的话。
线框图不仅限于网络应用程序； 它广泛用于任何需要对任何系统进行高级概述的地方（它只是被称为其他名称）。
功能规格，当您知道要做什么时 该怎么做，确实有点大材小用了。 一张关于你的意图的高级图表就足够了。 而且它永远不会是不必要的。 它主要帮助您专注于您想做的事情的范围和意图/目标。
重点应该放在防止浪费精力上——中途发现一些重要的、影响所有其他对象的东西缺失了，这并不是你想要发现的。 在这种情况下，线框图将有助于检测大多数主要的功能需求。 您只需要在绝对需要的地方详细说明功能规范。 使用 Photoshop 来设计你的作品也将是“浪费精力”——使用 CSS/HTML 的进化原型（RAD 技术）要好得多——但仍然用笔和纸来模拟你的意图。
"Fail to plan is plan to fail" - or something like that.
Wireframing is not limited to web-apps; it is pervasively used wherever a high-level overview of any system is needed (it's just called something else).
Functional specs, when you know what is to be done & how to do it would indeed be overkill. A high-level diagram of your intentions would suffice. And it will never be unnecessary. It primarily helps you focus on the scope and intent/target of what you want to do.
The focus should be on preventing wasted effort - finding out half-way through that something essential, that impacts on all other objects, are missing is not what you want to discover. Wireframing in this case would assist in detecting most major functional needs. You would only need to elaborate on functional spec where absolutely needed. Using Photoshop to design your will also be 'wasted effort" - far better to use evolutionary prototyping (RAD technique) with CSS/HTML - but still do pen & paper mock-up of your intentions.
37Signals 主张甚至跳过 Photoshop，直接使用 HTML。 请参阅 http://www.37signals.com/svn/posts /1061-为什么我们要跳过 Photoshop。 我同意他们对预先规划的评估。 我认为从长远来看，当你花时间用 HTML/CSS/JS 构建一个工作原型时，这是不值得的。
37Signals advocates skipping even Photoshop and going right to HTML. See http://www.37signals.com/svn/posts/1061-why-we-skip-photoshop. I agree with their assessment of pre-planning. I don't think its worth the time in the long run when you could be spending time building a working prototype in HTML/CSS/JS.
在现实生活中，您希望避免寻找“理想”的做事方式。 相反，使用您所理解的内容来实现明确且具体的目的。
模型可以节省您大量的时间和精力。 因为它们可能只是您花在创建和维护它们上的额外时间。
现实生活中的例子#1：模型挽救了局面。 对于政府的大系统来说，最后期限是荒谬的。
原因：花费了几个月的时间来制作各种架构文档，这些文档实际上完全没有必要，因为硬件和软件架构都固定在最微小的细节上，并且实际上已经存在。
解决方案：与客户一起疯狂创建模型 20 天，直到我们将带有注释的屏幕交给开发人员。 开发人员确实必须要求一些澄清，但凭借固定的架构和清晰可视化的需求，他们能够立即开发出所需的大量功能。
现实生活中的例子#2：模型毁了这一天。 “认识到”模型需求的大型政府系统。
这表明人类（或企业？）有能力将世界上最好的事情变成一场噩梦。
大型政府机构要求大型咨询公司带领大型IT公司解决问题。 政府机构还成立了一个由政府主题专家组成的大型特设机构，以帮助和加快这一进程。
几个月过去了，在决定使用合适的方法和正确的使用方法方面，已经过去了几个月的时间。 当然，我们做出了各种妥协，不是为了伤害任何人的感情或重要性。
结果：Sw 架构将成为包括模型在内的一切的源泉。 首先要设计，然后绘制。 映射来自 OOAD 和序列图的操作，制作 UX 图，然后识别 UI 逻辑对象和内容包，绘制实际屏幕并将其合并到正式用例中，在每月一次的正式研讨会上向用户展示 UC，这些研讨会兼作需求验收会议，因为有人发现时间正在流逝。
在这些研讨会上，即使强制客户也无法理解（高度正式，有大量描述数据属性等的表格）UC，每个 UC 大约有 30 页长。 当客户收到一些反馈时，都是在模型上。 但反馈不被鼓励，因为模型中的任何更改都会导致更改序列图、组件图、操作模型、UX 图、检查可追溯性矩阵、更新 UC 文本等。而且只是为了获得更多反馈。 （“该死的顾客，他们永远不会满意。”是摩托）。 在功能有限的 v1.0 推出之后，没有人再关心文档了，文档太多了。 开发人员正在为自己的生命而战，每天都会进行无数的小更改，只是为了让系统启动并运行（在昨天的一批更改导致其他东西损坏之后）。
这不是使用模型的方法。 该项目比原计划持续了近两年。
换句话说，不要寻找理想的方法论。 或者任何你不明白的方法论。 你现在的目标是什么？ 您知道实现该目标最快的方法是什么（其他方法不算）？ 大胆试试吧。
In real life you want to avoid looking for the "ideal" way to do things. Instead use what you understand for clear and specific purpose.
Mockups can save you TONS of time and effort. As they can be just extra time you spent on creating and maintaining them.
Real life example #1: Mockups saved the day. Big system for the government, deadline is ridiculous.
Reason: Months have gone by in producing all kinds of architecture documents which are in fact completely unnecessary because both HW and SW architecture are fixed in stone to the tiniest detail, and in fact already exist.
Solution: 20 frantic days of creating mockups together with the customer, until we simply handed the screens with our notes over to developers. Developers did have to ask for some clarifications but with fixed architecture and clear and visualized requirements they were able to crank out required tons of features in no time.
Real life example #2: Mockups ruined the day. Big government system that "recognized" the need for mockups.
This one shows human (or corporative?) ability to turn the best thing in the world into a nightmare.
Big government agency asked the big consultant company to lead the big IT company to solve a problem. Government agency also established a big ad-hoc body of government subject matter experts to help and speed up the process.
Months have passed in big words and in deciding on appropriate methodologies to use and proper ways to use them. All kinds of compromises were made, of course, not to hurt anyone's feelings or importance.
Result: Sw architecture was to be the source of everything including mockups. Which were to be designed first and drawn second. Mapping the actions from OOAD and sequence diagrams, UX diagrams were made, then UI logical objects and content bundles were recognized, actual screens were drawn and incorporated in formal Use-cases, UCs were presented to users in once-a-month formal workshops, those workshops doubled as requirements-acceptance meetings since somebody figured out time is slipping by.
On those workshops, even by force customers couldn't be made to undestand (highly-formal, with lot of tables describing data attributes and such) UCs, each approximately 30 pages long. When customers had some feedback it was on the mockups. But feedback was discouraged, because any change in mockup resulted in changing the sequence diagrams, component diagrams, operational model, UX diagrams, checking the traceability matrices, updating UC texts, etc etc. And only to get more feedback. ("Damn the customers, they are never satisfied." was the moto). After the rollout of v1.0 with limited functionality, nobody cared about documentation any more, there was so much of it. Developers were fighting for their lives, making myriad of small changes daily, just to get the system up and running (after yesterdays batch of changes made something else break).
This is NOT the way to use mockups. The project lasted almost 2 years longer than planned.
In other words, don't look for ideal methodology. Or any methodology you don't understand. What's your goal at the moment? What's the quickest way you know (other ways don't count) to achieve that goal? Go for it.
这可能取决于你和谁一起工作。 如果是你和设计师，那么功能规格可能会很麻烦。 但是，在我的工作中，管理人员想要准确地知道他们在项目结束时会得到什么，因此我们在实施迭代开发方面遇到了很大的困难。 通常迭代是用线框图、功能规格和模型来定义的……:)
It probably depends on who you're working with. If it's you and a designer, then a functional spec might be too much trouble. But, in my job, the executives want to know precisely what they're going to get at the end of a project and so we've had a real hard time implementing iterative development. Usually the iterations are defined with wireframes, functional specs and mock ups..:)
制作线框图的主要目的是澄清需求。
清晰地记录需求始终是可取的，没有比可视化需求更好的方法了。 线框图在这里发挥了很大的作用，它让产品所有者（客户）清楚地了解对最终产品的期望。 在获得产品负责人的批准后，它还可以让开发团队更清楚地了解要开发的内容。在某种程度上，它节省了大量的开发时间并避免了冲突。
在我看来，即使项目很小，线框对于项目的顺利执行总是有用的。
The main purpose of doing wire-frames is to clarify requirements.
Clearly documenting requirements is always advisable and there is no better way than visualizing a requirement. Wireframes help in a great way here, it gives the product owner (client) clear idea of what to expect from the end product. On approval from product owner it also gives clearer picture to development team of what to develop.In a way it saves lot of development time and avoids conflicts.
In my opinion wire-frames are always useful for smooth project execution even when project is small.
我相信这取决于您对自己想做的事情的理解程度。 如果您为客户工作并且他们没有以需求的方式表达太多，您可能需要一种迭代速度极快的方法。 如果你已经有了很好的理解，并且可以产生更实质性的东西，而不用担心因为方向错误而将其扔掉，那么可以花更多的时间。 无论哪种方式，可点击的原型都可以在很大程度上确定真正的网站最终需要什么。 如果您可以就原型达成一致，那么当您的应用程序与原型匹配时，您就知道它已经完成。
I believe it depends on how well you understand what you are trying to do. If you are working for a client and they haven't expressed much in the way of requirements you may want an approach with extremely quick iterations. If you already have a good understanding and can produce something more substantial without worrying about throwing it away because it was the wrong direction then more time can be spent. Either way, a clickable prototype can go a long way in determining what the real site needs to be in the end. If you can get agreement on the prototype, then when your application matches the prototype you know it is complete.
这取决于。 线框是绘制布局蓝图的机会，包括实现屏幕要求和用户目标所需的顺序和组件。 如果您仍在作为一个团队解决一些问题，那么直接进行开发或高保真模型是有风险的。 您可能会浪费时间和精力专注于隐藏真正挑战的细节。 然而，如果您对解决方案有强烈的认识，您对业务和用户研究都有明确的要求，和/或如果您有一个已经在使用的设计系统，那么跳过线框图不仅是合适的，而且是拥有这些流程和工具的好处。
It depends. Wireframes are an opportunity to blueprint the layout, including the order and components needed to achieve a screen's requirements and user goals. Going straight to dev or high-fidelity mockups is risky if you're still working out some questions as a team. You could waste time and effort focused on details that hide the true challenge. However, if you have a strong sense of the solution, you have clear requirements coming from both the business and from user research and/or if you have a design system already in-use, skipping wireframing can be not only appropriate but one of the benefits of having those processes and tools in place.