ANATOLY IVANOV / METHODS / DESIGN PROCESS

Both photography and design projects depend on the client’s subjective appreciation of aesthetics.

But while photography could be greenlit by a rather subjective “We love the pictures!” response, design introduces much more objective and complex 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.

Methods in plural, because a single design process would not suit all design projects. They 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

Iterations of:

• Anatoly IVANOV creates the graphic design
• Anatoly IVANOV and client review and brainstorm the design

repeated until agreement… or deadline / budget exhaustion. 😀

1.3 / Production

• prepress
• printing (offset or digital)
• finishing (cropping, die-cutting, scoring, folding, binding)
• distribution

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 or adapt the more robust web design process.

3 / WEB DESIGN PROCESS

3.1 / Complexity and the unknown

Today, a website represents the real-world company on-line, with all the real-world detail: websites have evolved from virtual brochures to virtual group-personalities to the product & brand experience.

Everything goes online. Values, history and vision. Ideas, services and products. Relationships with customers, investors, employees and press. Even a one-person business hardly sums up to a simple page. Even when being called an SPA (Single Page Application).

Because a website 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 website before we can actually use them. Often, ideas of features appear after the website 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 esthetical decisions for everyone else? How do we plan and quantify design, an elusive creative process?

All these parameters and questions add up to complexity and the unknown, consuming money, effort and time.

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 for the unknown, project managers develop an extremely detailed project scope and requirements statement. 100 pages long, this document defines the website’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 website: non-interactive, flattened screens of the future web pages.
• The client validates the design.
• The programmers code the website: HTML and CSS; JavaScript and its myriad libraries and frameworks (React, Vue, Svelte, HTMX); SSRs with Node.js or even the old and trusty PHP; Markdown files, JSON APIs or SQL databases, etc.
• After months of hard work, the client and the end-users finally get to play with a functioning website. It is then, while navigating the new website, 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 back in 1999, 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 website. Let’s play with it from the start. Let’s see what works, submit the website to end-users and get their feedback early in the process.
• No written document restricts our creativity. Both the client and I 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.

Results:

• 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:

1. macro-level: project stages
   (black bars on the sample project schedule Gantt chart below)
2. 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

3.3.1.1 / 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

3.3.1.2 / Interactive scenario

During the interactive scenario stage, I build a functioning website that is very close to the final version. The interactive scenario is an HTML website accessible on-line that:

• represents the information architecture of the final website
• contains all the pages of the final website
• includes all the textual content of the final website, in all language versions
• includes all hyperlinks: these links can be clicked and lead to the website’s other pages, just as they would in the final version of the website
• features all the principles and elements of the website’s navigation: buttons, selection lists, forms…
• hints at the placement of pictures in the form of gray rectangles
• omits any graphic design elements: it is a “naked” website that does not show colors, forms or images of the final version

Results:

• A tangible, specific website that focuses on features, content and navigation.
• As the interactive scenario website does not contain graphic design, it stays a very malleable, plain HTML. I can quickly and simply change its content, move pages around, add links, etc.
• The interactive scenario allows us to test the website by end-users and to react to their feedback very early in the process, using their familiar mobile or desktop browsers.
• The interactive scenario adapts perfectly to intensive collaboration and stimulates fluid, iterative creation.

3.3.1.3 / Graphic design

During the graphic design stage, I conceive the look of the website, its graphical user interface, using form, color, images and typography.

• All pages of a website 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 website extends over 30 pages but requires only 3 page templates:

  1. main home page template (main landing page)
  2. category home page template (products, about us)
  3. 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. In other words: content patterns and information architecture reveal the required page types.
  • We can concentrate on the website’s aesthetics while enhancing its ergonomics, because the interactive scenario has determined the website’s features and functionality.
  • We know precisely how the graphic design should work with the website’s content, because the interactive scenario has specified the type and length of texts, as well as the number of photographs.
  • The client often discovers a need for additional photography, videos and texts and had the time to produce them — whether in-house, or asking me to contribute through my multifaceted skills (as a filmmaker, photographer, copywriter…), or bringing additional people to the project.
• I represent the graphic design with “flat screens”: exact JPEG replicas of each page template filled with typical content or, for more technically savvy clients, Figma screens. “Flat screens” show all navigational elements, texts, photographs, forms, etc., as they would appear to the website visitor. Of course, “flat screens” omit the whole range of clickable hyperlinks or any other advanced 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 Figma or Adobe Illustrator 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 HTML / CSS pages require a lot of programming, font licensing, graphics positioning, and image optimization. Any modifications involve time-consuming changes in the code, source graphics and licensing.

Results:

• “Flat screens” of each page template represent the graphic design of the final website.
• We circumvent the unknown, focus on esthetical research, ease collaboration and reduce expenses.

3.3.1.4 / Technical implementation

During the technical implementation stage, I combine the graphic design with the interactive scenario.

• I reuse the HTML 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
  • HTML code
  • CSS code
• Depending on the website, I also add enhancements on the client-side:
  • JavaScript
  • WebAssembly / Canvas / Web Components
• For the majority of websites, I generate a sizeable proportion of images, HTML, CSS and JavaScript on the server-side using PHP, Node.js, some variant of an SQL database, as well as Nginx’ rewrite rules, caching and load balancing.
• Of course, I can adapt to whatever tech-stack your organization have been using — it might be a React SPA or a Shopify system — suggesting improvements nonetheless. My main focus remains on your clients. Yes, the DX (Developer Experience) is important, but UX (User Experience) is even more so.

Results:

• A perfectly functional, esthetical website that is very close to the final version.
• We may still improve a detail here and there.
• We submit the website 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 website 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 us to plan, assess and adjust the total duration and budget of a website design, at any point in the process.

It relies on 5 concepts:

3.3.2.1 / Man-days

The creative fee takes up the bulk of the total project cost. In turn, 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 website increases in complexity, calling for UI/UX animations and interactions, database solutions, payment systems… the more programming man-days it all requires, increasing the cost.
• The calculation of man-days also depends on the task type.

3.3.2.2 / Task types

All tasks of a project fall into 3 categories:

3.3.2.2.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.

3.3.2.2.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.

3.3.2.2.3 / Collaborative tasks

• Green-colored bars on the sample project schedule Gantt chart above.
• Examples: collaborative work on the interactive scenario.
• The client and I 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 the duration as my man-days.

3.3.2.3 / Adjustment of task duration to influence quality and cost

3.3.2.3.1 / My tasks

• The duration of my tasks stays fixed during the project (orange-colored bars).
• 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 website.
  • The client can also ask to extend the number of man-days allotted to my tasks if they prefer to invest more in the website’s quality.

3.3.2.3.2 / Collaborative tasks

• The duration of collaborative tasks stays elastic during the project (green-colored bars).
• 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. Consequently, 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 website as closely as possible. However, longer collaborative tasks will also raise the cost. Higher cost, more fine-tuning.

3.3.2.3.3 / Budget extremes

At the 2 budget extremes, the client can obtain:

1. Lowest budget:
   • A website that is designed by me without any client intervention.
   • My tasks only (orange).
   • The client either likes or dislikes my design.
2. Highest budget:
   • A website that takes a long time to build, with frequent modifications asked by the client.
   • Collaborative tasks only (green).
   • The end-result is a website that satisfies the client to 300%.

3.3.2.3.4 / Budget middle ground

The most sensible approach lies somewhere between the 2 extremes.

3.3.2.4 / 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… imprudent, if not outright 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 (website features)
• my time requirements to build the website that answers your needs (throughput and duration)
• your budget (website 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 esthetical and functional website 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.

3.3.2.5 / Beyond the days package

3.3.2.5.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 website 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 website, the client and I 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.

3.3.2.5.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 out of the window such a considerable money and time investment.

So my web design process features inbuilt emergency exits:

3.3.3.1 / Gradual payment

You pay as you go, at the end / beginning of each project stage.

3.3.3.2 / 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.

3.3.3.3 / 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 most of the websites I have built throughout 25 years — often illustrated by my own photography — in my design portfolio. Some are now museum-grade pieces, selected and preserved in publications by Taschen and others as significant contributions to design.

4 / MORE QUESTIONS?

I am always eager to answer your questions and discuss the details of my design processes: contact me.

NEXT : ANATOLY IVANOV / METHODS / GEOGRAPHICAL COVERAGE