Thoughts on Web Projects- UPDATED
Evan put together this nice little digram on his thoughts on a how a web project should flow. I thought I'd share and see if anyone has any other thoughts or ideas on his digram.
8 Comments
I think 'presentation' could also be comfortably placed in the center somewhere near style as well. Being able to visually see how it's going to look and interact with the users helps me before I start I any PHP. Also, was there a reason you used the colors that you did?
I wish Bear would update his Flickr photo to reflect the more recent changes.
I think the former version is valid if you look at "presentation" as the main touch-point between the visitor and the site/application. But within the context of a process, it doesn't make as much sense.
Take a look at the PDF version I uploaded, and you'll see I moved it back into the spheres of style and development.
Maybe I'm biased as someone who forsook a career as a web programmer, but I would make "development" circle smaller. I view technology as somewhat of a commodity (unless it is a prohibitively expensive one to implement, like building stealth fighter planes). I would argue that content and design, in that order, contribute more to the user experience than the platform or technology that the site is built upon.
(I just hope Jimmy C doesn't hunt me down, now...)
Perhaps I was being diplomatic with the area allotted for development. On the other hand, if you go by the proportion of dollars typically spent on development versus design, I think a couple things become apparent. Firstly, it seems as though clients feel more comfortable investing in nuts-and-bolts development work. Perhaps this is because it's viewed more as an asset, more concrete, more scalable. Secondly, there also seems to be a general proclivity amongst the uninitiated to developing first and "making it pretty" afterward. In other words, building without a blueprint because it's cheaper in the short term and can be improved later with a more significant re-investment. This approach is like nails on a chalkboard to me. But it demonstrates why the development circle is similar in size to design: many projects are not well-thought-out and hence require a lot of clean-up re-development on the back end. And we all know that clean-up projects (much like your local Superfund site) are ugly, expensive and not much fun to work on.
I think this is a nice way to look at the overall project from a web developer point of view. But one thing that seems to be missing is what action(s) is the website looking for visitors to take?
- e-commerce
- lead generation
- subscriptions
- communicate
- personalize
- customer service
This may be covered in planning. But all the rest is just a method of achieving those goals. From the movie Ronin. "What's your favorite weapon? Its just a toolbox, pick the right tools for the job."
Good point. In my efforts to be general, I didn't give enough weight to the importance of setting goals. I will add something to the research / planning phases that addresses this. Or perhaps a broader arrow to illustrate how the process should flow on a stream of goal(s). What do you think?
Yea, that development bubble is going to vary A LOT based on the project. If a client is looking to use a website to automate most of their business process, then development is going to be 90% of the project (just because the project is going to grow a lot).
If you look at the cost saved in people that you don't have to hire anymore though, it usually pays for itself pretty quick.
Lovingly crafted by orangecoat with some rights reserved, and a promise not to spam you.
Back to top
Here's the updated full PDF version of the above graphic. I'd like to know if this resembles how other people think of web projects.