What follows is an overview regarding the design process, which evolved within a publishing company, where I served as Web Art Director/Project Manager for 7 years. Where the team grew from a core of 3 people wearing multiple hats, to a core of 16 specialist front-end and back end developers and designers
As part of an in-house design and development team, the life cycle with the product and client (who is also part of the company) is continuous. This tends to blur the (dead) lines, and makes it increasingly important to keep a handle on project scope and breakdown. This also leads to larger projects being broken down into phases. So sites (like TDWI.com) that are looking for specialized functionality, will go through more of an evolution over time than a single major at-one-time redesign. The tendency, is to add functional “pieces” to each site over time. During the course of such projects, I will update sections of the css structure and design to bring them up to standards. The result is that at any one time there are very current pieces to the site and at the same time some relics of CSS1, and obtrusive javascript techniques.
On the other hand, some products (Campus Technology would serve as example), simply outgrow their former needs and site focus. In the case of CampusTechnolgy.com it had been 2 1/2 years since the last facelift, while the education sector and focus within the company had grown. The Education group, had acquired high-caliber writers and actual web editors with an interest in the web site, and editorial ideas. This resulted in a complete overhaul of the previous site, to meet the new requirements. So there are several methods of evolving larger corporate sites.
Once the consensus is reached with client and corporation that a redesign will benefit the business model, the client will work with a project manager and designer in a series of meetings to bring together functional requirements and redesign considerations. Depending on the client, this documentation could be anything from a two page word document, a 20 page pdf, or 100 pages filling a 1″ binder.
The next step in this process is building a wireframe. Armed with the clients needs, technical requirements, and research into their market, I will sketch some basic layout ideas in pencil before starting the html wireframe.
I used to create a complete design mockup in photoshop. Months would be spent, moving pixels around for the client before actual html building would begin. Then the html layout would need as much time tweeking as the photoshop layout. After listening to Kelly Goto session at Web Directions 05, I cut the photoshop mockup phase out of the timeline and go straight to a working html wireframe. This gives the client the most accurate idea of the final product. And a functioning navigation is much easier to explain.
Think of the wireframe as the structural frame of the house. This is a very important step. At this point, the type and extensibility of content and navigation are determined. Here is a sample wireframe, used for campustechnology.com redesign.
The first reaction from the client may be to wonder where the color is, or mention that the “design” looks very plain. It is a good idea to prepare the client for what the wireframe is, and set aside a comfortable amount of time to discuss in detail how the wireframe structure is meeting the clients various content needs.
Design Process – Beginnings
What follows is an overview regarding the design process, which evolved within a publishing company, where I served as Web Art Director/Project Manager for 7 years. Where the team grew from a core of 3 people wearing multiple hats, to a core of 16 specialist front-end and back end developers and designers
As part of an in-house design and development team, the life cycle with the product and client (who is also part of the company) is continuous. This tends to blur the (dead) lines, and makes it increasingly important to keep a handle on project scope and breakdown. This also leads to larger projects being broken down into phases. So sites (like TDWI.com) that are looking for specialized functionality, will go through more of an evolution over time than a single major at-one-time redesign. The tendency, is to add functional “pieces” to each site over time. During the course of such projects, I will update sections of the css structure and design to bring them up to standards. The result is that at any one time there are very current pieces to the site and at the same time some relics of CSS1, and obtrusive javascript techniques.
On the other hand, some products (Campus Technology would serve as example), simply outgrow their former needs and site focus. In the case of CampusTechnolgy.com it had been 2 1/2 years since the last facelift, while the education sector and focus within the company had grown. The Education group, had acquired high-caliber writers and actual web editors with an interest in the web site, and editorial ideas. This resulted in a complete overhaul of the previous site, to meet the new requirements. So there are several methods of evolving larger corporate sites.
Once the consensus is reached with client and corporation that a redesign will benefit the business model, the client will work with a project manager and designer in a series of meetings to bring together functional requirements and redesign considerations. Depending on the client, this documentation could be anything from a two page word document, a 20 page pdf, or 100 pages filling a 1″ binder.
The next step in this process is building a wireframe. Armed with the clients needs, technical requirements, and research into their market, I will sketch some basic layout ideas in pencil before starting the html wireframe.
I used to create a complete design mockup in photoshop. Months would be spent, moving pixels around for the client before actual html building would begin. Then the html layout would need as much time tweeking as the photoshop layout. After listening to Kelly Goto session at Web Directions 05, I cut the photoshop mockup phase out of the timeline and go straight to a working html wireframe. This gives the client the most accurate idea of the final product. And a functioning navigation is much easier to explain.
Think of the wireframe as the structural frame of the house. This is a very important step. At this point, the type and extensibility of content and navigation are determined. Here is a sample wireframe, used for campustechnology.com redesign.
The first reaction from the client may be to wonder where the color is, or mention that the “design” looks very plain. It is a good idea to prepare the client for what the wireframe is, and set aside a comfortable amount of time to discuss in detail how the wireframe structure is meeting the clients various content needs.