User-flow first : you're building software FOR the user. Once you know what you need to do (the whole picture) then you can think about how you want to do it.
Some systems don't even have a UI! Therefore, you can't reasonably expect a single, universally applicable answer to this question.
In many systems there are actually distinct object models for Business Logic layer and UI layer, and indeed there may well be more than one UI. For example a Customer UI delivered in a Browser and Thick Client App for the Customer Support team.
Also Use Cases and UIs are not the same thing. The first questions can be: "Tell me about what you need to happen when you create a new Wibble." No need to talk about UIs at all at first. You can model the scenario just in terms of "I want the system to ...".
Pragmatically when you draw screens you are probably building up a mental model of Business Objects. In a simple business case you may not need to document that model immediately. In more complex scenarios, especially when dealing with legacy back-end systems, you pretty soon find the need to capture some of that model : "So this screen is about Wibbles? And about their Zetules? Does each Wibble have its own Zetule? Oh, Several! And can we change them, pass them to other Wibbles? Oh only Blue Zetules are transferable?"
As has been said before it's going to be interative and creative. The first cut screen model will change. You will discover more and more gnarly bits.
My explicit answer is: the best use of time up front is to locate dragons. Dragons hide in the unknown. Big dragons are a risk, and hide in gnarly places. Gnarlyness is specific to projects, sometimes its UI sometimes it's not. When dealing with legacy systems in particular it's not usually the UI that bites you. Spend the time where the risk is.
I would certainly suggest laying out the user-flow first, in this case, because it is so specific. With a more common UI, it would be easier to plan/guess the objects. However, since you have a detailed spec for application flow, deal with that first, as planning objects too early will certainly miss the target for a good deal of the spec.
These can happen in parallel, and need not be finished before coding begins.
With iterative development, you will not necessarily design up-front either the whole software on paper or the whole class model.
User interactions impact the class model. However, you may have enough information to begin designing some architectural layers before user interaction design is complete. For example, the data model may be known in whole or part before you've begun designing specific interactions.
Schedule concerns may make working in parallel more desirable, especially if you have multiple staff contributing from the beginning.
发布评论
评论（4）
用户流程第一：您正在为用户构建软件。一旦你知道你需要做什么（整体），你就可以考虑你想如何去做。
User-flow first : you're building software FOR the user. Once you know what you need to do (the whole picture) then you can think about how you want to do it.
我在这个问题中看到了错误的选择。
有些系统甚至没有 UI！因此，您不能合理地期望对这个问题有一个单一的、普遍适用的答案。
在许多系统中，业务逻辑层和 UI 层实际上有不同的对象模型，而且实际上很可能有多个 UI。例如，在浏览器和胖客户端应用程序中为客户支持团队提供的客户 UI。
此外，用例和用户界面也不是一回事。第一个问题可以是：“告诉我创建新 Wibble 时需要做什么。”一开始根本不需要谈论 UI。您可以仅根据“我希望系统......”来对场景进行建模。
实际上，当您绘制屏幕时，您可能正在建立业务对象的心理模型。在简单的业务案例中，您可能不需要立即记录该模型。在更复杂的场景中，尤其是在处理遗留后端系统时，您很快就会发现需要捕获该模型的一些内容：“那么这个屏幕是关于 Wibbles 的？关于它们的 Zetules？每个 Wibble 都有自己的 Zetule 吗？哦，几个！我们可以改变它们，将它们传递给其他 Wibbles 吗？哦，只有 Blue Zetules 可以转让？”
正如之前所说，它将具有互动性和创造性。第一个切屏模型将会改变。你会发现越来越多的粗糙点。
我明确的回答是：预先利用时间的最佳方式是找到龙的位置。龙隐藏在未知之中。大龙是一种危险，并且隐藏在粗糙的地方。粗糙度是特定于项目的，有时是 UI，有时不是。特别是在处理遗留系统时，困扰您的通常不是用户界面。把时间花在有风险的地方。
I see false alternatives in this question.
Some systems don't even have a UI! Therefore, you can't reasonably expect a single, universally applicable answer to this question.
In many systems there are actually distinct object models for Business Logic layer and UI layer, and indeed there may well be more than one UI. For example a Customer UI delivered in a Browser and Thick Client App for the Customer Support team.
Also Use Cases and UIs are not the same thing. The first questions can be: "Tell me about what you need to happen when you create a new Wibble." No need to talk about UIs at all at first. You can model the scenario just in terms of "I want the system to ...".
Pragmatically when you draw screens you are probably building up a mental model of Business Objects. In a simple business case you may not need to document that model immediately. In more complex scenarios, especially when dealing with legacy back-end systems, you pretty soon find the need to capture some of that model : "So this screen is about Wibbles? And about their Zetules? Does each Wibble have its own Zetule? Oh, Several! And can we change them, pass them to other Wibbles? Oh only Blue Zetules are transferable?"
As has been said before it's going to be interative and creative. The first cut screen model will change. You will discover more and more gnarly bits.
My explicit answer is: the best use of time up front is to locate dragons. Dragons hide in the unknown. Big dragons are a risk, and hide in gnarly places. Gnarlyness is specific to projects, sometimes its UI sometimes it's not. When dealing with legacy systems in particular it's not usually the UI that bites you. Spend the time where the risk is.
在这种情况下，我当然建议首先布置用户流程，因为它非常具体。使用更通用的 UI，可以更轻松地计划/猜测对象。但是，由于您有应用程序流程的详细规范，因此请首先处理它，因为太早规划对象肯定会错过大部分规范的目标。
I would certainly suggest laying out the user-flow first, in this case, because it is so specific. With a more common UI, it would be easier to plan/guess the objects. However, since you have a detailed spec for application flow, deal with that first, as planning objects too early will certainly miss the target for a good deal of the spec.
这些可以并行发生，并且不需要在编码开始之前完成。
通过迭代开发，您不一定要预先设计纸上的整个软件或整个类模型。
用户交互影响类模型。但是，在用户交互设计完成之前，您可能有足够的信息来开始设计一些架构层。例如，在开始设计特定交互之前，数据模型可能全部或部分已知。
日程安排问题可能会让并行工作变得更加可取，特别是如果您从一开始就有多名员工参与工作。
These can happen in parallel, and need not be finished before coding begins.
With iterative development, you will not necessarily design up-front either the whole software on paper or the whole class model.
User interactions impact the class model. However, you may have enough information to begin designing some architectural layers before user interaction design is complete. For example, the data model may be known in whole or part before you've begun designing specific interactions.
Schedule concerns may make working in parallel more desirable, especially if you have multiple staff contributing from the beginning.