For a large project first think of a one-liner to description of your site (try to not use any buzzwords here). Next think of three design maxims (rules your design Should never conflict with). Then draw a few views and think up a few user cases (1 day) then work in code for 2 weeks (this will be a throw away prototype so just work as fast as you can forget about bugs and details, don't worry about code smells or design patterns, just make as much as you can), then revaluate all the steps above and throw away your two week prototype, and begin your project in a serious manner applying solid engineering and design. After a month has gone by evaluate your(team) moral and get feedback. If it all seems to be going ok, continue, you got a long ride ahead, otherwise just give up, do a postmortem, and start over with new goals.
I always start with the user interface design. I figure out what the user should be able to do and what controls I will give them to do it. Once I get that laid out in a way I like it, then I start with the code "wiring".
The cross linking features of mindmapping softwares make it lot easy. Since mindmapping is 'kind of freeform', I end up concentrating on the 'task' rather than 'representation' (e.g which type of UML diagram should I use to represent this) ?
Once initial ideas are clear then I can work on project plan, spec/design documents using UML for more low level details. This approach usually works well for me.
To see if it works for you or not, you can use FreeMind (opensource mindmaping software, good but currently limited functionality). Then You can try Mindmanager or iMindmap for mindmaping. Both integrate well with other Office products.
Usually I start out by grabbing my scratchbook and just start writing down what I want as in terms of features, this should be quite detailed. And can be quite messy with every thing scrambled together, if so, when you're done make an 'official version' of you're ideas on paper (REAL pen and paper works best for this in my opinion).
Then I start making some scetches of how the pages would look like, what information it must contain and translate that to a global database design. Then work that global design to a more advanced level where all pages come together, with relations between tables and stuff.
After that I build up the most important pages on a code framework (I always make use of a framework, if you don't then forget the framework part), and by 'most important pages' I mean in for example a blog that would be the posts. After that build the not-so-important pages, in case of a blog that could be an archive of posts.
If you have that done, put the code together with a design, or do that while coding if you do not seperate code from HTML/CSS/JS.
Oh and yes, do NOT expand your first idea along the way. Just write that down and implement that afterwards. So if, in case of the blog again, you think half way you want Youtube tags in you're BB-code, write it down. Add that later, offcourse before you're initial site releases.
That's my workflow, at least a basic basic, basic description of it.
Start with "paper prototypes", i. e. take a pencil and sketch each page very roughly. This lets you start from the user perspective, which I think is a good idea.
You can then use the sketches for a first hallway usability test and later as the basis for "wireframes" you would give a web designer to work from.
If you've gone through the complete site once, you probably have a good idea of what the backend should be able to do. You can now use your page sketches and compile a list of the actions a user can trigger by clicking on things. This is the raw material for designing the server-side API that the frontend can call.
Using the calls that need to be served, you can design the backend: What functionalities group nicely, what data needs to be fetched, what do you need to store between page calls (== Session variables) etc.
In this process, I have fared quite well by postponing technology decisions (frameworks, protocols etc.) and even class structure etc., until I've gone through the whole thing once in terms of "what things should do what to what other things" (I guess there's a better term).
I think I would start with an open-source SNS solution that comes close to what you need and then figure out how to add use-specific plug-ins, modules, and themes that achieve your purposes. There are a lot of em out there. Building from scratch is going to take a lot more effort and planning. Most SNS functionality is not worth re-inventing. Focus on what will make your site unique and build upward toward that.
I'm a fairly visual person when it comes to designing software so I sketch out dataflows, class hierarchies, UI and flow charts on whiteboards and paper first.
Butcher paper and colored pens can be particularly fun to use as it's 3 feet wide and comes in 100 foot rolls. When you've got a design that's satisfying or sufficiently complete, tear it off the roll and pin to the wall. Update as necessary.
That technique has worked for some large refactors as well as new projects.
You could start with something very simple and then add features a little at a time. You may reach a point where you want to start over, but the groundwork you did will be beneficial. Or you can try to do the whole thing at once, in which case you'll need the advice already given in the other replies.
One more idea: Specify those features you are not going to include, and other restrictions. These are called constraints, and are as important as the rest of the plan, as it gives you boundaries so you know when you're done planning!
If you work for the same company as this person, start by getting everything in writing so you aren't the one to take the fall when the inevitable happens...
发布评论
评论（10）
对于大型项目，首先考虑用一句话来描述您的网站（尽量不要在此处使用任何流行语）。 接下来考虑三个设计准则（您的设计不应与之冲突的规则）。 然后画一些视图并想出一些用户案例（1 天），然后在代码中工作 2 周（这将是一个废弃的原型，所以只要尽可能快地工作，就可以忘记错误和细节，不用担心代码味道或设计模式，尽可能多地制作），然后重新评估上述所有步骤并扔掉两周的原型，并应用可靠的工程和设计以认真的方式开始您的项目。 一个月后评估您（团队）的道德并获得反馈。 如果一切似乎都很顺利，请继续，你还有很长的路要走，否则就放弃，进行事后分析，然后以新的目标重新开始。
For a large project first think of a one-liner to description of your site (try to not use any buzzwords here). Next think of three design maxims (rules your design Should never conflict with). Then draw a few views and think up a few user cases (1 day) then work in code for 2 weeks (this will be a throw away prototype so just work as fast as you can forget about bugs and details, don't worry about code smells or design patterns, just make as much as you can), then revaluate all the steps above and throw away your two week prototype, and begin your project in a serious manner applying solid engineering and design. After a month has gone by evaluate your(team) moral and get feedback. If it all seems to be going ok, continue, you got a long ride ahead, otherwise just give up, do a postmortem, and start over with new goals.
我总是从用户界面设计开始。 我弄清楚用户应该能够做什么以及我将给予他们哪些控制来做到这一点。 一旦我以我喜欢的方式进行布局，然后我就从代码“接线”开始。
I always start with the user interface design. I figure out what the user should be able to do and what controls I will give them to do it. Once I get that laid out in a way I like it, then I start with the code "wiring".
列出该网站拥有的所有功能。
列出一些值得拥有的功能。
列出网站的弱点。
对列表进行排序并确定首先构建的项目的优先级。
确定什么是可以做的，什么是不可以做的。
与您的客户会面并展示这些结果。
Make a list of all the features that site have.
Make a list of nice to have features.
Make a list of the weakness of the site.
Order that list and prioritize the items that will be built first.
Identify what will be possible to do and what is not.
Meet with your customer and present these results.
做一个思维导图
思维导图软件的交叉链接功能使其变得非常容易。 由于思维导图是“一种自由形式”，因此我最终将注意力集中在“任务”而不是“表示”上（例如，我应该使用哪种类型的 UML 图来表示它）？
一旦初步想法清晰，我就可以使用 UML 来处理项目计划、规范/设计文档以获取更多底层细节。 这种方法通常对我很有效。
要查看它是否适合您，您可以使用 FreeMind （开源思维导图软件，很好，但目前有限功能）。 然后你可以尝试 Mindmanager 或 iMindmap 用于思维导图。 两者都与其他 Office 产品集成良好。
Usually I do a mindmap of
The cross linking features of mindmapping softwares make it lot easy. Since mindmapping is 'kind of freeform', I end up concentrating on the 'task' rather than 'representation' (e.g which type of UML diagram should I use to represent this) ?
Once initial ideas are clear then I can work on project plan, spec/design documents using UML for more low level details. This approach usually works well for me.
To see if it works for you or not, you can use FreeMind (opensource mindmaping software, good but currently limited functionality). Then You can try Mindmanager or iMindmap for mindmaping. Both integrate well with other Office products.
通常我首先会拿起我的便签本，然后开始写下我想要的功能，这应该非常详细。 如果是这样，当你完成后在纸上制作你的想法的“官方版本”（在我看来，真正的笔和纸最适合这个），并且所有东西都混在一起可能会很混乱。
然后我开始绘制一些页面外观、页面必须包含哪些信息的草图，并将其转换为全局数据库设计。 然后将全局设计提升到更高级的水平，将所有页面结合在一起，并在表和内容之间建立关系。
之后，我在代码框架上构建最重要的页面（我总是使用框架，如果您不忘记框架部分），并且“最重要的页面”是指在例如博客中，是帖子。 之后构建不太重要的页面，如果博客可能是帖子存档的话。
如果您已完成此操作，请将代码与设计放在一起，或者如果您不将代码与 HTML/CSS/JS 分开，则在编码时执行此操作。
哦，是的，不要一路扩展你的第一个想法。 只需写下来并随后实施即可。 因此，如果再次提到博客，您认为自己想要 Youtube 标签的一半是 BB 代码，请将其写下来。 稍后添加，当然是在您首次发布网站之前。
这就是我的工作流程，至少是一个基本的、基本的描述。
Usually I start out by grabbing my scratchbook and just start writing down what I want as in terms of features, this should be quite detailed. And can be quite messy with every thing scrambled together, if so, when you're done make an 'official version' of you're ideas on paper (REAL pen and paper works best for this in my opinion).
Then I start making some scetches of how the pages would look like, what information it must contain and translate that to a global database design. Then work that global design to a more advanced level where all pages come together, with relations between tables and stuff.
After that I build up the most important pages on a code framework (I always make use of a framework, if you don't then forget the framework part), and by 'most important pages' I mean in for example a blog that would be the posts. After that build the not-so-important pages, in case of a blog that could be an archive of posts.
If you have that done, put the code together with a design, or do that while coding if you do not seperate code from HTML/CSS/JS.
Oh and yes, do NOT expand your first idea along the way. Just write that down and implement that afterwards. So if, in case of the blog again, you think half way you want Youtube tags in you're BB-code, write it down. Add that later, offcourse before you're initial site releases.
That's my workflow, at least a basic basic, basic description of it.
从“纸质原型”开始，即拿一支铅笔，粗略地画出每一页的草图。 这让你可以从用户的角度出发，我认为这是一个好主意。
然后，您可以使用这些草图进行第一次走廊可用性测试，然后作为“线框”的基础，供网页设计师使用。
如果您浏览过整个网站一次，您可能很清楚后端应该能够做什么。 现在，您可以使用页面草图并编译用户可以通过单击事物来触发的操作列表。 这是设计前端可以调用的服务器端API的原材料。
使用需要服务的调用，您可以设计后端：哪些功能组合得很好，需要获取哪些数据，需要在页面调用之间存储什么（==会话变量）等。
在这个过程中，我有通过推迟技术决策（框架、协议等）甚至类结构等，直到我按照“什么东西应该对其他东西做什么”来完成整个事情（我猜有一个更好的术语）。
Start with "paper prototypes", i. e. take a pencil and sketch each page very roughly. This lets you start from the user perspective, which I think is a good idea.
You can then use the sketches for a first hallway usability test and later as the basis for "wireframes" you would give a web designer to work from.
If you've gone through the complete site once, you probably have a good idea of what the backend should be able to do. You can now use your page sketches and compile a list of the actions a user can trigger by clicking on things. This is the raw material for designing the server-side API that the frontend can call.
Using the calls that need to be served, you can design the backend: What functionalities group nicely, what data needs to be fetched, what do you need to store between page calls (== Session variables) etc.
In this process, I have fared quite well by postponing technology decisions (frameworks, protocols etc.) and even class structure etc., until I've gone through the whole thing once in terms of "what things should do what to what other things" (I guess there's a better term).
我想我会从一个接近您需要的开源 SNS 解决方案开始，然后弄清楚如何添加特定用途的插件、模块和主题来实现您的目的。 那里有很多这样的人。 从头开始构建将需要更多的努力和规划。 大多数 SNS 功能不值得重新发明。 专注于使您的网站与众不同的因素，并朝此方向不断发展。
I think I would start with an open-source SNS solution that comes close to what you need and then figure out how to add use-specific plug-ins, modules, and themes that achieve your purposes. There are a lot of em out there. Building from scratch is going to take a lot more effort and planning. Most SNS functionality is not worth re-inventing. Focus on what will make your site unique and build upward toward that.
在设计软件时，我是一个相当注重视觉的人，所以我首先在白板和纸上勾勒出数据流、类层次结构、UI 和流程图。
屠夫纸和彩色笔使用起来特别有趣，因为它宽 3 英尺，卷装为 100 英尺。 当您获得满意或足够完整的设计后，将其从卷上撕下并别在墙上。 根据需要进行更新。
该技术适用于一些大型重构以及新项目。
I'm a fairly visual person when it comes to designing software so I sketch out dataflows, class hierarchies, UI and flow charts on whiteboards and paper first.
Butcher paper and colored pens can be particularly fun to use as it's 3 feet wide and comes in 100 foot rolls. When you've got a design that's satisfying or sufficiently complete, tear it off the roll and pin to the wall. Update as necessary.
That technique has worked for some large refactors as well as new projects.
您可以从非常简单的东西开始，然后一次添加一些功能。 你可能会达到一个想要重新开始的地步，但你所做的基础工作将会是有益的。 或者您可以尝试一次完成所有事情，在这种情况下，您将需要其他回复中已经给出的建议。
还有一个想法：指定您不要包含的功能以及其他限制。 这些称为约束，与计划的其余部分一样重要，因为它为您提供了界限，以便您知道计划何时完成！
You could start with something very simple and then add features a little at a time. You may reach a point where you want to start over, but the groundwork you did will be beneficial. Or you can try to do the whole thing at once, in which case you'll need the advice already given in the other replies.
One more idea: Specify those features you are not going to include, and other restrictions. These are called constraints, and are as important as the rest of the plan, as it gives you boundaries so you know when you're done planning!
如果你和这个人在同一家公司工作，首先要把所有的事情都写下来，这样当不可避免的事情发生时你就不会承担责任......
If you work for the same company as this person, start by getting everything in writing so you aren't the one to take the fall when the inevitable happens...