Both photography and design projects depend on the client’s subjective appreciation of aesthetics.
But while photography, in essence, elicits a “like it / don’t like it” response, design complicates matters with considerations for marketing strategy, product positioning, corporate culture, information architecture, end-user interaction, usability, ergonomics and other, often very pragmatic and utilitarian, parameters.
That’s why efficient and effective working methods are even more crucial to successful design projects than to photography projects.
But a single design process would not suit all design projects. Design projects differ by media, scope and client involvement.
In my experience, print design projects, such as advertising and brochure design, require the simplest and shortest processes. Brand identity projects, such as logo and typographic systems design, position themselves somewhere in the middle of the complexity / duration scale. Web design projects demand substantial energy and time inputs, both from the designer and from the client.
1 / PRINT DESIGN PROCESS
The print design process is relatively straightforward:
1.1 / Prologue
- Anatoly IVANOV and client analyze:
- client’s business
- client’s needs
- client’s industry
- Anatoly IVANOV and client outline the project’s goals.
- Anatoly IVANOV and client define the budget (creation and production).
1.2 / Graphic design
- Anatoly IVANOV creates the graphic design
- Anatoly IVANOV and client review and brainstorm the design
1.3 / Production
2 / BRAND IDENTITY DESIGN PROCESS
Brand identity systems combine logos, corporate colors, design grids and typography to express the essence of a company. The complexity of such fundamental projects depends on the scope of the company, so I tend to either use the simpler print design process, adapt the more robust web design process, or mix the two.
3 / WEB DESIGN PROCESS
3.1 / Complexity and the unknown
Today, a web site essentially mirrors the real-world company on-line, with all the real-world detail: web sites have evolved from virtual brochures to virtual group-personalities.
Everything goes online. Values, history and vision. Ideas, services and products. Relationships with customers, investors, employees and press. Even a one-person business hardly ever sums up to a simple page.
Because a web site represents the company in such detail, choices about what and how goes on-line involve a lot of strategic decision-making. I have witnessed several web design projects redefine the client’s core marketing strategies, and sometimes, even the product itself. That’s the reason web design projects last for months and require a very collaborative approach.
The intangible nature of the internet complicates matters even further. It is difficult to evaluate the features of a web site before we can actually use them. Often, ideas of features appear after the web site goes live.
And of course, we still have to deal with the typical challenges of design. What do users really need? How does design solve real-world business challenges? Who, in a company of 500+, makes aesthetical decisions for everyone else? How do we plan and quantify design, an elusive creative process?
All these parameters and questions create time and money consuming complexity and the unknown.
3.2 / Two ways to deal with complexity and the unknown: predictive vs adaptive
3.2.1 / The common approach: deny the unknown with detailed predictions
The natural human reaction to uncertainty is to make predictions, develop a plan and then follow through, step by step:
- To compensate the unknown, project managers develop an extremely detailed project scope and requirements statement. 100 pages long, this document defines the web site’s features, specifies the schedule and allocates a fixed budget.
- The client validates the scope and requirements statement.
- Graphic designers use the scope and requirements statement to create the look of the web site: non-interactive, flattened screens of the future web pages.
- The client validates the design.
- After months of hard work, the client and the end-users finally get to play with a functioning web site. It is then, while navigating the new web site, that the client realizes that some features should be changed and some other added or removed.
- The project managers rewrite the specs. The designers adjust the design. The programmers change the code.
- Still, the client asks for additional feature revisions. User feedback reveals problems no one suspected. Requirements keep changing.
- With each new modification, the final result strays farther and farther away from the initial scope and requirements statement. The project gets delayed and the budget explodes.
- Blame and pain settle in. Not a pretty sight. But, unfortunately, all too common in the web design and software development industry.
3.2.2 / My approach: accept the unknown with adaptability
My web design process accepts the unknown as something that we cannot change or control. Inspired by the ideas of agile programming, my web design process adapts to uncertainty, on the go. I redirect the energy needed for predictions and control into creation and experiment:
- I skip the detailed scope and requirements statement.
- I shift the graphic design to a later stage.
- I begin with a functional prototype of the web site. Let’s play with it from the start. Let’s see what works, submit the web site to end-users and get their feedback early in the process.
- No written document restricts our creativity. Both the client and me feel free to imagine features and functionalities as we go. We test them on end-users right away.
- A flexible cost system empowers the client to decide which features to implement.
- constant awareness of what works and what doesn’t
- frequent end-user feedback
- full understanding of per-feature cost
- freedom of choice for the client
3.3 / How does it work?
My web design process flows through 2 systems:
- macro-level: project stages
(black bars on the sample project schedule Gantt chart below)
- micro-level: project tasks
(blue, orange and green bars on the sample project schedule Gantt chart below)
Note: detailed explanation of the Gantt chart follows after the graphic.
3.3.1 / Project stages
126.96.36.199 / Prologue
During the prologue stage, we:
- discuss and analyze the client’s business, needs and industry
- negotiate and settle on a solutions proposal that outlines our collaboration
- sign a project contract that defines our collaboration in legal terms
188.8.131.52 / Interactive scenario
During the interactive scenario stage, I build a functioning web site that is very close to the final version. The interactive scenario is an XHTML web site accessible on-line that:
- represents the information architecture of the final web site
- contains all the pages of the final web site
- includes all the textual content of the final web site, in all language versions
- includes all hyperlinks: these links can be clicked and lead to the web site’s other pages just as they would in the final version of the web site
- features all the principles and elements of the web site’s navigation: buttons, selection lists, forms…
- hints at the placement of pictures in the form of grey rectangles
- omits any graphic design elements: it is a “naked” web site that does not show colors, forms or images of the final version
- A tangible, specific web site that focuses on features, content and navigation.
- As the interactive scenario web site does not contain graphic design, it stays a very malleable, plain XHTML. I can quickly and simply change its content, move pages around, add links, etc.
- The interactive scenario allows us to test the web site by end-users and to react to their feedback very early in the process.
- The interactive scenario adapts perfectly to intensive collaboration and stimulates fluid, iterative creation.
184.108.40.206 / Graphic design
During the graphic design stage, I conceive the look of the web site, its graphical user interface, using form, color, images and typography.
- All pages of a web site fall into several page types that share the same graphical elements and content placement. Therefore, a page template can be used for each one of these page types to create any number of pages.
Example: a web site extends over 30 pages but requires only 3 page templates:
- main home page template (main landing page)
- category home page template (products, about us)
- content page template (detailed description of a product)
The content of each one of the 30 pages changes, but the 3 designs remain the same. Result: visual consistency, brand identification and easy navigation.
- The graphic design stage focuses on the creation of page templates.
- The previous stage, interactive scenario, resolves a lot of unknowns and helps the design process:
- We can decide how many page templates we need, because we have by now created all the content and information architecture: content patterns and information architecture reveal page types.
- We can concentrate on the web site’s aesthetics while enhancing its ergonomics, because the interactive scenario has determined the web site’s features and functionality.
- We know precisely how the graphic design should work with the web site’s content, because the interactive scenario has specified the type and length of texts, as well as the number of photographs.
- I represent the graphic design with “flat screens”: exact JPEG replicas of each page template filled with typical content. “Flat screens” show all navigational elements, texts, photographs, forms, etc., as they would appear to the web site visitor. Of course, “flat screens” omit clickable hyperlinks or any other interactive features, but because we have already defined that functionality during the interactive scenario stage, we can use them as a more efficient way to work on the graphic design:
- It is much easier to shape the page templates in Adobe Fireworks and save them as JPEGs. I can quickly react to client and end-user feedback and modify the graphic design as needed.
- In contrast, fully interactive XHTML / CSS pages require a lot of programming, graphics slicing and image optimization. Any modifications involve time-consuming changes in the code and source graphics.
- “Flat screens” of each page template represent the graphic design of the final web site.
- We circumvent the unknown, focus on aesthetical research, ease collaboration and reduce expenses.
220.127.116.11 / Technical implementation
During the technical implementation stage, I combine the graphic design with the interactive scenario.
- I reuse the XHTML code of the interactive scenario stage and add the “flat screens” of the graphic design stage to create a mixture of:
- images optimized for the web
- XHTML code
- CSS code
- Depending on the web site, I also add enhancements on the client-side:
- A perfectly functional, aesthetical web site that is very close to the final version.
- We may still improve a detail here and there.
- We submit the web site to end-users once again to get their feedback and correct any eventual shortcomings that would slip through the interactive scenario and graphic design stages, as well as to iron out any bugs.
- At the end of the technical implementation stage, we open the final web site to the public.
3.3.2 / Project tasks
Project tasks subdivide project stages into manageable blocks of work and duration.
My flexible win / win system of project tasks allows to plan, assess and adjust the total duration and budget of a web site design, at any point in the process.
The project tasks system relies on 5 concepts:
18.104.22.168 / Man-days
The creative fee makes up the bulk of the total project cost. The total amount of the creative fee depends on the number of man-days:
- The more days I work on a project, the higher the total cost of the project.
- If the web site requires complex database solutions, I join forces with a programmer specialized in back-end technologies. The more complex the web site, the more programming man-days it requires, increasing the cost.
- The calculation of man-days depends on the task type.
22.214.171.124 / Task types
All tasks of a project fall into 3 categories:
126.96.36.199.1 / Administrative tasks
- Blue-colored bars on the sample project schedule Gantt chart above.
- Examples: sign-offs, payments.
- I do not count the duration of administrative tasks as my man-days.
188.8.131.52.2 / My tasks
- Orange-colored bars on the sample project schedule Gantt chart above.
- Examples: creation of the graphic design.
- I work alone on these tasks.
- I count 100% of these tasks’ duration as my man-days.
184.108.40.206.3 / Collaborative tasks
- Green-colored bars on the sample project schedule Gantt chart above.
- Examples: collaborative work on the interactive scenario.
- The client and me work together on these tasks, either simultaneously (meetings, brainstormings), or asynchronously (additions, revisions and changes from the client and then from me).
- On average, I count 40% of these tasks’ duration as client’s man-days and 60% of duration as my man-days.
220.127.116.11 / Adjustment of task duration to influence quality and cost
18.104.22.168.1 / My tasks
- The duration of my tasks stays fixed during the project.
- My tasks form the core of the project. They create the foundation for the collaborative work that follows.
- I calculate the absolute minimum number of man-days needed for their completion.
- Before the project starts:
- The client can ask to decrease the number of man-days allotted to my tasks, but risks to severely lower the quality of the web site.
- The client can also ask to extend the number of man-days allotted to my tasks if he / she prefers to invest more in the web site’s quality.
22.214.171.124.2 / Collaborative tasks
- The duration of collaborative tasks stays elastic during the project.
- The duration of these tasks depends on the number and scope of changes, revisions and modifications requested by the client.
- At any time:
- The client can decide to decrease the duration of the collaborative tasks, and, therefore, reduce the costs. However, the client will also have to reduce the number of changes, revisions and modifications. Lower cost, less fine-tuning.
- The client can decide to increase the duration of the collaborative tasks to increase the number of changes, revisions and modifications, in order to approach the ideal web site as closely as possible. However, longer collaborative tasks will also raise the cost. Higher cost, more fine-tuning.
126.96.36.199.3 / Budget extremes
At the 2 budget extremes, the client can obtain:
- Lowest budget:
- A web site that is designed by me without any client intervention.
- My tasks only (orange).
- The client either likes or dislikes my design.
- Highest budget:
- A web site that takes a long time to build with frequent modifications asked by the client.
- Collaborative tasks only (green).
- The end-result is a web site that satisfies the client to 300%.
188.8.131.52.4 / Budget middle ground
The most sensible approach lies somewhere between the 2 extremes.
184.108.40.206 / Days package – a fixed price contract commitment
I think that starting such a long-term project without at least a rough idea of a total budget is a bit scary. So during the prologue stage, we decide with the client the duration of my tasks and the duration of collaborative tasks. Which gives us the overall number of man-days and the total cost.
I apply progressive discounts for long-lasting projects. So the longer the project, the lower the price per man-day.
As we negotiate using a win / win approach, no one is forced to accept the first proposal. We stay open and find a balance between:
- your needs (web site features)
- my time requirements to build the web site that answers your needs (throughput and duration)
- your budget (web site cost)
In practice: we sit together and try different combinations in a project management program that instantly outputs the project duration and cost.
Once we have agreed on a total number of man-days, I commit to a days package – a fixed price / fixed man-days contract:
- At the end of the days package I guarantee to deliver an aesthetical and functional web site that can be used on-line.
- I communicate about the use of my man-days weekly, using both a Gantt chart and a resources sheet.
220.127.116.11 / Beyond the days package
18.104.22.168.1 / What happens if the client requires more days than we have scheduled in the days package?
I understand and anticipate the client’s wish to build the best web site possible. Even though we have agreed on the optimal duration of collaborative tasks, I leave to the client total freedom to extend them and to request any number of revisions and modifications.
Beyond the days package (fixed price / fixed man-days contract), I apply my day rate used for the days package:
- A project with a longer days package and therefore a larger discount will have a lower day rate.
- A project with a shorter days package and therefore a smaller discount will have a higher day rate.
- It may actually cost less to agree on a long days package (fixed price / fixed man-days contract) than to agree on a short one and then pay all the extra days at a higher price.
- I communicate about the use of the extra man-days weekly, using both a Gantt chart and a resources sheet.
- I invoice the extra man-days at the end of each of the 3 project stages.
My 25 years of experience in web design confirm that clients tend to underestimate the time needed for collaborative tasks. I therefore usually advise to anticipate and extend the collaborative tasks when agreeing on a days package (fixed price / fixed man-days contract).
As we work together on the web site, the client and me develop a feel for how long it takes to implement this or that feature or modification. We can therefore frequently estimate the needs in extra man-days before proceeding further.
22.214.171.124.2 / What happens if the actual project takes less time than we have scheduled in the days package?
I admit that I have never seen this happen in 25 years of working on web design projects. But if it does happen, I would prefer to reimburse the client all unused man-days.
3.3.3 / Emergency exits
Web design is a complex, lengthy and costly process involving a lot of human interaction. We may disagree to a point when we prefer to end our collaboration.
However, I would feel really upset if you had to throw this considerable money and time investment out of the window.
So my web design process features inbuilt emergency exits:
126.96.36.199 / Gradual payment
You pay as you go, at the end / beginning of each project stage.
188.8.131.52 / Rejection and termination
I leave to the client total freedom to reject the interactive scenario or the graphic design or the technical implementation and terminate our collaboration.
In such case, all previous payments will remain permanently acquired by Anatoly IVANOV, but no other payments, such as for non-initiated stages, will be asked.
184.108.40.206 / Reuse possibility
If you wish to reuse the work done up to that point, I would gladly license the usage rights if:
- The portion of the days package plus any extra days of all finished and initiated project stages are paid (I do not ask for payment of the non-initiated stages).
- The integrity of the graphic design is maintained, in case you wish to use it.
- The copyright mention of my contribution is maintained.
3.4 / A complex answer to a complex problem?
Yes, my web design process may seem more complex than the traditional approach, because I embrace the inherent complexity of web design.
But the detailed description of my web design process actually takes more time to read than to implement and use.
What’s amazing is how the process feels nimble, natural and trust-infused to both the client and myself.
Moreover, we always know where the project is and how much it costs.
Does it work? Yes, it does. Even the page you are reading now is the result of my web design process. You can also take a look at other web sites I have built in my design portfolio.
4 / MORE QUESTIONS?
I am always eager to answer your questions and discuss the details of my design processes: contact me.