In the world of web project management as it relates to building complex web applications, do you think that the development should follow design, or can both be done concurrently?
I’m involved with an exciting project with a fast approaching deadline. Because of this deadline the development team (database, JSP, and Flash) had to get involved early in the design phase making it difficult to update design templates down the road.
I was wondering what your thoughts are on this matter? I’ve been involved with such a large number of projects and had this same situation crop up, that I’m convinced that in most cases, design should be 100% complete before developers are called in.
By taking this approach, the developers can focus on development and not have to worry about new features or design changes.
5 responses to “Web development should follow design, with emphasis on the word follow”
This is always hard…
Design and layout/developement often go hand-in-hand, or at least should. I often pick up clients that have sites already designed and now want me to help them get optimized for search engines. Typically, the design that is already in place is not highly optimized, so then I go back and redesign the site for them.
It would have been more cost effective, and cheaper for them if they would have hired me from the start to design and develop all at the same time.
Ok, so what I am trying to say is, ‘that design can’t simply come first’. It’s like if someone drew up plans for a house and said I like this design only to then give it to the architect and be told that this house is not structurally sound and will collapse on itself.
You have to know have to develop ‘structurally’ well before a design can happen…IMO.
I agree with you Mark, however the development I was thinking about was the backend kind (not html type stuff). Maybe you were thinking the same.
I agree that the developers and designers should be involved from day one, in most cases. It helps to get an idea of everyones perspective.
Iterative development like that ends up stepping on everyone’s toes, not just the designer sadly. It’s a shell game to try to keep everything in line and organized as developers phase out features, introduce new ones and designers change the functionality and layout of the front end.
I’m a big advocate of all the teams working on a functionality diagram prior to development, laying down exactly what each page does, and then everyone getting out of the designer’s way while they figure out how to lay it out in the most highly usable way.
It’s something my company has struggled with because our clients are always pressuring us to compress our timelines to meet their unrealistic expectations, so those nice neat phases always bleed over into each other and more frequently than not it ends up taking longer if we’d done everything according to our initial plan.
I have learned that you should always have a detailed requirements document before code is even mentioned or Photoshop is opened. After you have a requirements doc, you then need a solid application design and architecture. If you have a good architect, they will design the application so that the presentation layer (design) is loosely tied to the underlying functionality so changes are simple. Both design and development can take place in tandem if you have a solid set of requirements and a solid architecture FIRST. My two cents.
Well what brings about a Industry Standard and just another project is the team work. Me and my team have been creating projects and completing assignments on time (only if the client wants it modified for some reasons).
The development team really bear the brunt of huge data incorporation and structural enhancements. The design team only has to cope up with them. You may not alter the foundation due to sudden structural modifications, but you can alter the structure or look because of the limited space of your foundation.
In short, the development team should work hand in hand with the design team so as to keep them well informed on sudden design changes in the information base.