What follows is a brief overview regarding the design process, which evolved within a publishing company, where I served as Web Art Director/Project Manager for 7 years. There the team grew from a core of 3 people wearing multiple hats, to a core of 16 specialist front-end designer/developers and back-end developers
Evolution of business needs
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. Larger projects are broken down into phases. So as each product looks for specialized functionality, it will go through more of an evolution over time, than a single major one-time redesign. The tendency, is to add functional “pieces” or “modules” to the business unit with the highest demand first, then roll-out this same functionality to the other business units over time.
During the course of this evolution, part of the challenge for UI development is to update sections of the html/css structure to bring them up to current standards, while not breaking existing structures. The result is that at any one time there are very current pieces to the site, existing side by side with relics of CSS1, inline-styles, and legacy obtrusive javascript techniques.
Other products, outgrow their former needs, site focus, or business model entirely and require a complete overhaul. In the case of CampusTechnology.com it had been 2 1/2 years since any major added functionality on the site. The education sector and focus within the company had grown, along with a larger, dedicated editorial team. The Education business 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 these new requirements.
So there are several methods of evolving larger corporate sites. It will depend on the business units needs, as to what approach is advised.
Requirements
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.
Wireframes
The next step in this process is building an interactive 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.
Designers historically created complete design mockups in photoshop. Months would be spent, moving pixels around for the client before actual html building would begin. Then the html wireframe 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 typography and extensibility of content and navigation are determined. Here is the initial sample wireframe, used for campustechnology.com redesign.
Minimal Design
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 purpose the wireframe serves, and set aside a comfortable amount of time to discuss in detail how the wireframe structure is meeting the clients various content and technical needs. The focus at this stage is on functionality, and content flow NOT design. Without a discussion of color or imagery, the client can focus on how the site will satisfy the content needs of its user.
When the functionality and structural hierarchy is in place, then, and only then can a discussion of design “look and feel” begin.
To be continued…(styleguides)
You must log in to post a comment.