My list of common web design mistakes

1. Markup

1.1. Use of inappropriate tags

Tags must be meaningful. Their addition for pure stylistic purposes has to be avoided. This only makes the markup hard to follow and burdens the DOM tree unnecessary. The deeper the nesting level of tags, the more time it takes for the browser to find and render the content. A smaller hierarchy means that DOM nodes are sooner available to the JavaScript engine for access.

1.2. Overuse of ids and classes? Actually of tags.

Tags enable the addition of attributes like ids and classes. It's very easy to attach the latter to the former when we need greater control over the page layout. That's why these attributes are overused on the web. Placing too many in the markup is expensive in comparison to the short tags. Reading long list of attributes can be slow and may require a declaration sequence standard for easy findability.

1.3. Use of concrete tag selectors within CSS resets

Concrete tag selectors within CSS resets are unmaintainable, which is why I prefer the universal star selector to reset margins and paddings. Concrete tag selectors are parsed slower, but executed faster. The star operator is parsed faster, but executed slower. You have to choose what's more appropriate in your case. I tend to prefer maintainability over speed, which explains why I regard this as a mistake.

1.4. Not validating the HTML

Markup validation allows us to keep browser rendering differences to a minimum. Errors in the HTML require time for interpretation by the browser, which slows down the page. HTML is the base on which CSS and JavaScript operate and when it isn't stable, the structure may need to be rebuild. HTML shouldn't be neglected.

2. Code

2.1. Unclear responsibilities

Define the code responsibilities as clear as possible. This will help with the object-oriented design and will give hints where functionality belongs. It won't be always easy to figure out, but the principles of low coupling and high cohesion give a good orientation.

2.2. Not using native methods when they are available

Built-in, native methods will always be more efficient than our own. Before writing our own method, we must check if there isn't already one that does something similar. This requires time to read the documentation if we want to write code efficiently and complete tasks with the least possible effort. Only if a method isn't there should we try to write our own.

2.3. Bloated code

This is a code that does more than it needs to. It contributes to download, readability, understandability, maintenance, security and a full bag of other problems. The discipline of software engineering proves that such code is a failure and I truly believe in this principle too. A widespread example today is the unmotivated use of frameworks, which aren't fully utilized. Sometimes even frameworks with similar characteristics are combined, when only few of their built-in functions are needed.

2.4. Writing long, uncommented, unmaintainable code

Reading and understanding code is slow. If we write less, we'll also need to read less. This reduces our workload twofold. With long code, someone else might not understand our logic, consider our code unintuitive and delete it. We must aim to make our code self-explanatory, so it can survive time and future changes. Maintenance should have higher priority than adding new functionality and is the reason why the web is in a bad shape today. There aren't any standards how to write code, so we have to create and follow our own. If we stick to them, we'll find everything faster. This is valid for selectors and declarations in CSS as well as for functions in programming languages.

2.5. Applying styles through JavaScript

JavaScript allows us to apply styles to DOM nodes, but this may introduce reflows when the geometry is changed after the initial page load. Operating with the DOM is slow as it's not part of JavaScript. Therefore it should be used sparingly, similarly to the way server-side languages shouldn't constantly send queries to a database. If we need to apply styles through JavaScript, we can isolate them in CSS classes and only specify the name of the class.

2.6. Not checking the JavaScript code in different browsers

We must ensure that the JavaScript functions we use are available to all browsers. If that's not the case, we must try to normalize the differences through our own functions or use a common framework has implemented this functionality.

2.7. Dynamic script insertion

This technique can be easily misused and lead to annoying results. Generating scripts through another script on a live site is from my standpoint hack-like and inappropriate.

2.8. Relying on external scripts that download more scripts

Other companies like to have their code on our pages. It helps them track the behavior of our users, gather comprehensive information about them, make statistical analysis and improve their decisions. This happens once we insert their code on our pages. For example, a simple Facebook "Like" button accounts for almost 50kB of scripts, making multiple HTTP requests. We don't really need what Facebook engineers need. Calls to external services are always slower than to functionality on the same domain. Some websites may slow down up to three times just because they use an external service that doesn't respond immediately.

2.9. Introducing points-of-failure

The use of external services is risky. If they fail, slow down or change, our website reacts accordingly. On the web nothing lives forever. Everything changes rapidly and our architecture needs to accomodate for that. The fewer dependencies our code has, the better.

2.10. Trying to "fallback" at all costs

When we want to embed a video on our website, we must ensure that the browser supports the proper video format. When multiple browsers support different formats, we need to insert multiple sources of we want to increase our chances that the format will be recognized. If this doesn't work again, we may fall back on Flash then. But this isn't maintainable in the long term when video formats and browser capabilities change or newer versions of Flash come out. Sometimes the effort (that in this case leads to effective code duplication) isn't justified.

2.11. Not knowing what a framework does and how it does it

Frameworks make our life easier by increasing our development speed, which is useful for large code bases. But they also mask the browser differences and make assumptions about our needs. Sometimes they are incomprehensible too. If we can't understand how something works, it's better not to use it, because we won't be able to change it quickly and adapt it to our needs. When we drive a car and it fails, we must be able to quickly determine where the issue lies. The vehicle has too many parts and the addition of more grows its complexity linearly, but it becomes exponentially more difficult to find the problem.

2.12. Not thinking in bytes

Every time we press a character or digit, we are adding one byte to our file. That may not sound much, but the average person is able to type around 30 words per minute. Only in a couple of hours can the newly created file grow large. On the web speed is everything and every byte counts. We must use the fewest amount of bytes to do the thing that works, independent of the programming language. We'll have to make tradeoffs—for example, longer variable or function names enhance our understanding, but use slightly more characters.

2.13. Inappropriate use of regular expressions

Lengthy regular expressions are easy to mistype, hard to maintain and can be slow to execute. The more specific they are at their beginning, the faster they'll find a match. If we can use a string replacement function instead of regular expressions without sacrificing flexibility, we should do so.

2.14. Copy-paste from the web

Copy-paste is a bad practice and leads to the duplication of bad code. Choosing what's appropriate for our use and discarding everything else is essential. Even better is to write our code ourselves—we can learn more this way.

2.15. Relying on sessions when cookies can be turned off

In this case persistent information might not be transferred to individual pages.

2.16. Forgetting to send the HTTP headers before sending the content

This error occurs when we have sent an HTML content and then decided that we need to send headers too. For example, before we send XML from the server to the client in response to an Ajax request, we must specify its proper content type, so the client can recognize the file received.

2.17. Not using version control

When we accidentally overwrite files, this is the moment we realize that we needed to have a version control system.

2.18. No code profiling

We can't decide on what we don't measure and code profiling helps us here. By measuring code execution speed through the profiler, we can find and eliminate bottlenecks before they reach our users. Testing how the code executes is better than assuming that everything is right.

2.19. Thinking about security last

Security has to be part of every decision we make. We need to only give our users the fewest possible privileges they need to do their job. SQL injections, cross-ste scripting, and countless others attacks exist. It's useful to check for problems with a static analysis tool and then and eliminate them. Depending on your programming language of choice, your tool will be different. For C# or Java, Coverity might be good, for PHP I have found only RIPS.

2.20. Not testing extensively or writing test cases

Testing is important as part of the validation that the site does what it is supposed to do. Test cases are useful, but they need to be maintained too, which increases the code complexity. A single person or a small team can feel overwhelmed by this effort.

2.21. Not compressing code

Compressing code minimizes the page weight and its time to load. We can serve more users then.

3. Visual design

3.1. Creating the design first, then the content

Design lives within a context, not vice versa. The context is the first thing we need to outline through content that is relevant to the user's needs and to our strategic goals. After that we must think about the kind of design that will best support our message.

3.2. Not specifying the properties of our design upfront

Deciding upfront which properties and feelings should distinguish our site can help us achieve better consistency and define better the personality of our website. It can be joyful, corporate, easy to use, modern. Our decisions here will greatly influence our design choices.

3.3. Lack of consistency

Consistency helps us minimize the time users need to understand and use our interface.

3.4. Pixel-perfectness at all costs

Conditional comments and hacks add noise to our code and make it unmaintainable. Therefore, achieving a pixel-perfect website has a higher cost, which may not be justified. Pixel-perfectness is an illusion—we just can't be sure in what context our site will be used.

3.5. Not paying attention to the gestalt principles

The gestalt principles can help us achieve the visual effects we are looking for. Their wrong use makes our site look "strange".

3.6. Making a site look like a brochure

The web is about interaction, which is why completely static pages don't contribute to a dialogue. Whatever we do, it should rely on a two-way communication, open feedback and criticism.

3.7. Making everything in Photoshop before doing it in the browser

This only slows us down. Sketches are much faster and more natural. Latest versions of Photoshop require also the latest hardware. Not to mention that without using shortcuts, Photoshop is close to unusable. The more pixels you have on your screen, the harder it will become to click on the right one. Zooming helps, but it doesn't deliver immediate value. At the end a problem is solved with another problem—zooming in and out becomes frequent. The subjective feeling why Photoshop is slow might be a result of the need to use two devices at the same time—keyboard and mouse. Every time we switch a device, it slows us down. We can even count how many times we switch them while using Photoshop.

3.8. Ignoring "harmony"

Larger content blocks receive higher relative visual importance than smaller ones, which can be normalized through the use of suitable colors and hierarchy. For example: showing larger blocks in lighter colors and smaller ones in darker colors. The first page that comes to my mind as "harmonic" one was the old version of the Datapipe site, which is no more online. It was built of many blocks, whose background colors were chosen very carefully. Despite the many colors, it looked like all blocks were "friendly" to each other. Another site that uses harmony very well is Etsy.

3.9. Ignoring "balance"

If we place all our "heavy" content like images on the left sidebar and let the site flow in our mind, it might fall to the left. If we place other weights strategically on the page, we can achieve balance. Or we may even need to remove an element to restore it. We can test for harmony and balance, when we take five steps back from our monitor and look at our site again. Chances are that something draws our attention much more than it should. We must pay attention if our big pictures relate well with our small text.

3.10. Inappropriate use of animation

Some websites have animated backgrounds that constantly change their colors and shades. In such cases the visitors often have trouble to read anything on them and it's not clear how this distraction helps them achieve their task.

3.11. Speedy animations

Speed draws attention. If we increase the speed of our animated objects, our users won't be able to see anything else. If we spread an animated ad over the text, they won't be able to read it. Both cases lead to strong emotions.

3.12. Using fonts, whose size can't be adjusted

When fonts are specified in absolute size units, the content on our website can't be resized by our users. So we have to favor relative font sizes, which are better suited for different types of monitors.

3.13. Not optimizing images

Images are the element that mostly contributes to the weight of a web page. We can use reduced-color PNG images where possible. Some portals that skip image optimization fully are bigger than two megabytes. It's hard to imagine a user trying to open one of them on a slow internet connection.

3.14. Wasting screen space

The screen has only a limited amount of pixels, so we need to use them in the most efficient way. They need to have a room to breathe too. The more screen space our content occupies, the more the user will have to scroll, which is an additional task that slows him down. When possible, we should avoid all kinds of screen space waste.

3.15. Using frames and tables for layout

Although this is rarely relevant today, it doesn't hurt to remind of this bad practice again. We may still use tables, but only for tabular data. There are more appropriate tags that can by styled for layout purposes.

3.16. Not establishing a visual hierarchy

Emphasize the most important content on your page in a hierarchical way to allow for easy understanding of relationships.

3.17. Using metaphors people can't understand

The metaphors we use should be clear and unambiguous. For example, we must be sure if the meaning of a button "X" means delete or close.

3.18. Not creating enough contrast between foreground and background colors

There are some well-maintained sites today whose content is close to unreadable. If you use a black background color with very dark foreground color, people may have to increase the brightness or contrast of their monitor to see anything, which is hard on the eyes. This is why users like me try to select the text and see if it is then readable or even change the colors through Firebug. I don't think that reading should be hard, because of choose insufficient contrast between the foreground and background colors.

3.19. Not specifying width and height attributes of media

Although most of the browsers today can read automatically image dimensions, I still recommend using these attributes. They will keep reflows and repaints in the browser to a minimum and leave no room for incorrect interpretations.

4. Content

4.1. Using irrelevant information

Such information ,might be numbers, category tags that don't make sense out of the context and many more. For example, I think that the only relevant number in Twitter is the number of people who follow you. Everything else is just noise. It is there, so people can feel like they are part of a game. StackOverflow is another site that uses numbers and tags extensively. I think that the usefulness of gamification is questionable and it takes a good portion of the interface and the user's attention.

4.2. Offering too much content

People feel overwhelmed by too much content. They are unable to grasp everything on the first look. We need to reduce the number of elements or text on a page to improve the understanding of content or the speed of choice of our users.

4.3. Bad, intrusive, unmoderated, unformatted user-generated content

Bad content is one that is inappropriate for the theme. Intrusive is one that stays on the users' way or tries to trick them. Unmoderated is one that isn't checked by a real person for its validity. Unformatted content is one that isn't styled appropriately. Avoid them and always pay attention how users interact with the site.

4.4. Not reducing the number of choices for visitors

It's important to lead the user's eye on the most important interface elements first. By reducing the choice for visitors and emphasizing different areas on the page, we make it easier for them to understand the hierarchy of importance.

4.5. Using media that fails to enhance the written message

If the used media doesn't enhance our message, we should discard it. If we keep it, it's nice to make it more personal. Videos are slow to load, so they should be kept short and provide maximum value for the traffic.

4.6. Using long, low-value sentences

The majority of the articles on the web today are just rewritten in other words. People write too much saying too little. They may have heard that Google prefers long, keyword-rich articles or they may simply be paid to write more. It's wrong to pollute the web with needless information or we'll soon lose our users.

4.7. Writing very long lines

When a line length is longer than 55-60 characters, users find the beginning of the next line harder. A suitable line height can also help. If we have too much text, there is always the possibility to cut it in half. With longer lines, rereading a specific part of the line (when we didn't get the meaning initially) becomes harder as we have to search longer for specific keywords. Shorter lines give the opportunity to increase the text size to make it more readable, but they increase the line count which means more eye transitions, which can be tiresome for the eyes.

4.8. Using smart interface titles

This is how users become unsure of what's behind a link. The undescriptive nature of a link doesn't provide context. I recently found a link on webpage called "newsletter", written in cyrrilic as it sounds. There isn't such word in the dictionary and the content creator didn't attempt to translate it. He relied instead on people, who had knowledge of English, to know what it means. But this is a barrier to some users. Another example is a TV advertisement saying "[phone model] is a phone with Android...". Back then, Android was fairly new, so the majority of people probably didn't knew what it is. When we can't describe the context to our target audience in an easy to understand way, we lose it faster.

4.9. Not caching content

Textual files and images can be cached, so that on subsequent requests they are loaded immediately instead of going to the server. This improves the overall responsiveness of the site. We can tell the browser how long we wish the content to be cached, before it makes another request.

4.10. Not being aware of how different cultures perceive sites differently

Web design is psychology too, although very subtle. When something bothers us, we may often not be able to say what it is, but we just feel it's there. As there are no two equal designer opinions, so are no two equal user opinions. Everyone perceives sites differently, but a proper design can serve as a guide to the eye. We must always be users of our own sites and seek for ways to test them with more people.

4.11. Not updating old articles

As the content gets older, its usefulness declines. To keep it as independent as possible from time and trends, we need to write about things that are less likely to change. This will ensure that they'll stand the test of time and continue to attract attention long after the initial publication date.

4.12. Not having a printable version of the content

It's a good practice to consider the people that might try to access our content on a different media (e.g. paper). This way we facilitate smooth transitions and reach more people in ways we never thought about before. If people have the choice to read something online or to print it and they choose the latter, this means that our content has passed the value test. No content is more worthy than one that someone has in her hands.

5. Database

5.1. Storing sensitive data

If we store sensitive data, it's almost sure that sooner or later our database will be exposed to attacks. We need to keep sensitive data to a minimum, if we store one at all. The most important thing to protect is the user's account, so forcing users to choose good passwords and having the means to change it is a good starting place.

5.2. Not optimizing database queries

The database is one of the slowest components of any site. Where possible, we should use simple database queries. Joining multiple tables is slow and less flexible. Selecting everything in a table through the star operator is slow. Specific columns that contain data we'll search often, are good candidates for an index. It will speed up the information retrieval.

5.3. Not introducing a cache to limit the hits against the database

A concurrent use of a website means also concurrent reads and writes. If the database doesn't cache the results, we may put unnecessary strain on it. Large sites will lag if many users request in parallel information from to the database that isn't in a cache.

5.4. Allowing SQL injections

We must be very careful of what data users submit to our site. Their input must be filtered, so it doesn't contain malicious content. We can use prepared statements or another mechanism to escape user input.

5.5. Not taking precautions before a data loss

We need to be prepared in advance for disasters and decide how and when we'll back up our data and how we'll restore it in case of data loss. Testing different scenarios in advance can better prepare us for the accident, when it occurs.

6. Project management

6.1. Starting too many projects

We can't afford to abandon our projects, so we need to start as few of them as possible at the same time. Having too many responsibilities spreads our attention, so that we allow the costly task switching to lower our productivity. Every task requires enough attention and this could quickly exhaust our resources. Our energy must be invested rationally.

6.2. Starting a new site or project the wrong way

This is a quick way to lose precious time. Thinking upfront can save it. We can use some design patterns that could help us minimize our errors in advance. One such pattern is the Model in which we clearly separate the database (model) from the user interface (view) and the business logic (controller).

6.3. Abandoning projects in favor of a new idea

Opportunity cost evaluation happens in every decision we take. If we feel more joy or sense in doing something else or we are faced with endless problems that only drain our energy, we are more likely to try something new. This eternal quest for the better leads to the falling motivation curve. The start of a new project is marked by our highest motivation point and as we approach its end, our motivation gradually declines. When it falls below a certain threshold, we abandon our project. Many companies have disappeared, because they weren't able to finish what they started.

6.4. Not reading unrelated stuff to gain different perspectives

Doing only work while missing the bigger picture is like being in the sun with no glasses—we can't see anything. We often don't understand what motivates us or how our work affects the lives of other people. Only through reading of seemingly unrelated stuff or talking with people outside our organization and profession can we gain new perspectives. Most things are unrelated only at the beginning.

6.5. Not being self-aware of your processes and actions

Our processes can greatly influence our productivity, which is why we need to be more aware of them and what we can do to optimize them. The only way to improve our workflow is to actually see that something isn't right or is missing. There's always more room for process improvement.

6.6. Using the wrong process

We shouldn't write client-side scripts before we have finished with the server-side ones. JavaScript should enhance what's already available, not define it. Otherwise, we may need to go back later and redo things that were supposed to be complete. To find more, see my "personal view of the web design process".

7. Marketing

7.1. Not telling immediately what the site is about

People should be able to find within five seconds what our site is about. If it's not clear, they'll think that they are at the wrong place and leave. Many websites don't communicate their purpose directly enough. Potential users, who might have been interested in their products or services, leave and they take with them the opportunity to differentiate and target the customer segments.

7.2. Trying to appeal to all visitors

This is the beginning of the end. It just weakens our message and makes our priorities unclear. We need to narrow our focus if we want to be more effective.

7.3. Searching for questionable, creative ways to impress the audience

Trying to impress the audience is counterproductive. It would have been already impressed if our products and services were extraordinary. Or if our customer service was authentic, careful and unexpectedly good. Using technology to impress is more questionable. For example, the use of Flash or Ajax is not always appropriate as they both have their problems. We must use technology in a way that it supports the users to achieve their tasks and not appeal to them through needless effects or eye candy.

8. Advertising

8.1. Using excess advertisements

They contribute to the feeling that a washing machine has been run on our site. Unfortunately, nothing is clean yet.

8.2. Not having standards for advertisements

Good standards for advertisements will clearly show what is allowed on our website and what not. The advertisements that we allow must have a defined file format (static or dynamic), dimensions, file size, specific price for specific number of impressions.

9. Misc

9.1. Using shared hosting

Shared hosting is cheaper than a dedicated one. The disadvantage is that it's less secure. If one person allows complete access to the server, every website on the server can be hacked.

9.2. Bad usability

Failure to account for people with disabilities, people with JavaScript, CSS or images turned-off or people relying only on a keyboard, mouse or a touch screen mobile device is a bad design. Possibilities and combinations are endless. We need to team up with other people to be able to tackle all these problems. Our users expect things to behave as they should. We need to be careful with forms—the number of fields we accept, their proper description, input data validation. Minimizing the number of needed actions or steps for users to get a result is always valuable. If something can be done with two clicks, we shouldn't introduce a third one. Or we'll slow down the process by 50%.

9.3. Not planning how the interactions take place

This can cause us to change our initial version multiple times. Generally, the user interface is very volatile and the more precise we can specify it, the better. Thinking better and longer upfront can save us time later.

9.4. Using too many external resources

Making many HTTP requests against the server is slow. HTTP headers are sent and received with every request. To speed up our site, we need to minimize the number of these requests through combining multiple files of the same type (js, css, image sprites).

9.5. Failing to consider tradeoffs of particular decisions

In web design, everything is a tradeoff. There is never a "right" solution to a problem, but a combination of small things that add up to the final experience. The best designers are capable of balancing all these things.

9.6. Targeting all available platforms

Unless we use a tool that automatically normalizes all platform differences, we'll need to change our code for every single platform we support. That's not maintainable in the long term.

9.7. Relying on trends rather than common sense

Trends are poisonous. They brings us in the wrong direction and detract us from our goals. Many wrong decisions were taken because of attempts to capitalize on the new. The "web 2.0" shiny buttons and gradients were just some of them. We can create our own unique standards, based on what great design means to us, not based on the trends someone else imposed on us. The results of common sense always beat those of trends. So, don't follow, define your own style.

9.8. Not working within constraints

Constraints can help us find solutions to our problems, because we're forced in doing so. Sometimes, even your survival might depend on it. When we feel in danger, we unlock our hidden capacity and find new ways to go forward. When we buy the latest computer hardware and create our web design on it, we may not be aware that we make the assumption that our users will also have a powerful PC. Because of not seeing problems like CPU utilization, memory consumption, disk space requirements, graphic card power and so on, we are less inclined to acknowledge them. For that reason, creating our designs on a slow machine imposes a constraint on us that forces us to be more creative in the way we reach all people, independent of the capabilities of their devices. This is a whole new way to experience web design. Suddenly we'll see how large and nice graphics slow down the rendering speed—especially by scrolling—or how Flash locks our processor. After that, we may start to consider carefully what, where and how we use technologies.

9.9. Not considering the network lag

In case of high traffic spikes, requests might take longer than usual to fulfill. The physical locations of where the site is hosted and where its users are can greatly affect the initial connection time. If our site is hosted in China, but the users load it from Brazil, it may take a long time until the data arrives. Big companies avoid this problem by using multiple servers, located in different places in the world. This greatly minimizes the network lag, which can greatly vary. For example, I once experienced almost five seconds of network lag, while trying to load a site located in China. This time depends on many variables that are mostly outside of our control.

9.10. Putting on a visible place that a site validates

Not all users are technologically proficient to know what a valid site is, so bothering them with unneeded details won't improve their perception of the website. Thousands of pages are now valid and this is no longer a differentiating factor. It's a remainder of the old days.

9.11. Creating something we don't have a long-term interest into or that doesn't support our purpose

We should know why we do something and how it supports our long-term goals. By aligning our daily actions to our purpose, we achieve more coherence and momentum. We should always strive to create things that make us feel good later.

9.12. Not recognizing that web design in an organization is a game of power and influence

When many people are involved, consensus becomes hard. Often the person with the most influence determines the direction of the team. There is a chance then that team members start to work against each other, for their own interests, which kills collaboration.

9.13. Not having the ability to sense what's going to improve the lives of many people

Through our work we serve others. We must figure out what their pains are, where problems lie and which problems can/should be tackled. We must also pay attention to the problems of the environment people live in. It often shows the first symptoms of what is needed for a change. If we strive to solve larger problems through our designs, we'll deliver more value to ourselves and others.

9.14. Not brainstorming alternatives

There is always more than one way to do things and none of them is right. We need to carefully evaluate alternatives and choose the most appropriate solution in the concrete case that will best serve our clients and their client's needs. Not going through all the alternatives might be short-sighted now and more costly later.

9.15. Setting the wrong priorities

Everything we place on a web page is a choice. Prioritizing the content helps us focus only on the most important things and discard everything else. It's all focus. If we try to be everything to everyone, we'll be nothing to noone. Our concepts are mostly multidimensional (also in invisible ways) and the most important things that support them must have high priority. Then we can work around them to see what else feels as their expansion. We can't determine our priorities without having a list of all ideas first. After determining the priorities, we should strive to keep the requirements intact.

9.16. Focusing on documentation, not action

We must concentrate on things that bring immediate value to the customer. Documentation is not one of them. It's good to have it for ourselves, but not essential for our users. They are the people, whose needs we need to address. Documentation often stays in the way of doing things, requires more time and slows down shipping. The frequency with which we receive feedback on our work drops and this can be detrimental to our project.

9.17. Trying to copy successful sites

If our client wants the same features like on another site, we need to ask why. That's often a bad and costly decision.

9.18. Thinking that we shouldn't know it all

We must then be prepared for surprises. If we don't know it all, we don't know the context we work in and we can't take the right decisions.