In previous articles on the process of creating a website, I outlined several initial stages of preparation and design, as well as our approach to implementing the project plan. Some might think that the website is already complete – built on the basis of market and target group analyses, designed in terms of functionality and content, coded and dressed up with graphics and animations. But that’s not all. Today, I will present a few more extremely important stages.
Stage VIII – RWD
RWD, or responsiveness – adapting the portal to display in various formats, not only on computer monitors, but also on tablets and smartphones.
I deliberately did not mention this stage earlier, but we must realise that if we want to have well-prepared versions of the portal, we must anticipate this in stages IV-VII, because it will clearly affect our cost estimate. Some investors solve this by creating a portal only for desktop computers and providing a separately created mobile application for download, for example booking.com.
Stage IX – SEO
Probably at least 50% of your portal traffic will come from Google, so it is essential to create a website that is 100% Google-friendly. We follow Google’s guidelines for webmasters so that the portal is positioned higher in search results right from the start.
Stage X – Beta testing
Incorrectly linked pages, missing content that the client was supposed to provide from their solicitor (e.g. terms and conditions), non-functioning subpages – these are common situations after transferring the website from the server address to the target portal address. Before we show our portal to the world, let’s make sure it is tested by test users so that any minor errors are corrected.
This will increase the likelihood that it will meet its sales goals – users will not leave the portal because of problems with navigating it and finding what they are looking for, but will convert (purchase, sign up to a form, etc.).
Stage XI – Maintenance and Cyclic Upgrade
Few people consider that the end of a project and its launch does not mean the end of costs. In fact, we are only just beginning to work on it with users.
For the project to develop, you need people to oversee it. The standard complaint procedure is 14 days, but in IT this cannot work, because you often have to react immediately, which is why companies sign maintenance contracts so that programmers can start work right away without analysing whether it is a problem with the server, the application, a software error or some other external factor. Immediate action is required, but this involves the cost of maintaining a team in the project that can undertake such work.
A separate issue is the work and analysis of what users do. In many of our projects, we record and review all user sessions to see which actions can be optimised and made even more intuitive. This is a completely normal stage of the project. We have to approach this as if we had delivered a well-developed prototype and were checking what improvements needed to be made to it so that it would better meet the needs of users. It is never the case that we deliver a project by linking it to a domain and that is the end of the collaboration. In our project budget, we have to assume that we are simply entering the next stage of project development, and that this also requires a project team working on the product.
Case Study
Our Client from the 3D printing industry hired two graphic designers and three programmers to create a website. The project ended up costing PLN 70,000 and resulted in a completely unintuitive piece of junk. Why did this happen? Because there was no specialist to create the concept and business model, there was no competent project manager, there was not even any documentation to hold the project team accountable. There was no one on the owner’s side who would look after his interests and audit the project. The functionalities did not work, some of them were even deliberately hidden by the programmers so that they would not have to fix them.
We tried to save this project. At our request, complete project documentation was created – it was over 200 pages long. We wrote down the functions and submitted over 100 comments on the code and functions alone. The client understood that the design errors were the result of neglecting the UX process, archaic graphic design and a lack of planning for mobile versions. The business model itself, i.e. the foundation of the activities, was poorly thought out, and on our advice, the client gave up on further investing in reviving a dead project that had no chance of success anyway.
We have helped our clients rescue many failed projects and we know that it makes no sense. Often, the best solution is a fundamental change and starting the project from scratch.
We are a partner for companies that are aware that an effective, profitable project is not a quick job for little money. We are looking for serious partners who:
a) have experience and are creating another project;
b) do not have experience but are willing to be guided through the process.
We are unable to help clients who insist that documentation is not necessary or who expect a quote based on rather modest guidelines in order to compare it with other agencies. This approach means that quotations can vary dramatically – these differences are not the result of a desire to cheat or artificially inflate prices, but reflect the quality and scope of the services provided. Some want to build a Fiat Panda from ready-made parts, others a Mercedes CLS focused on reliability. We are happy to build Mercedes cars according to specific standards, or Toyotas, which are also famous for their reliability 😉 This does not mean that we will not build a Fiat for someone if that is what they need. However, it is important to remember that if you dream of a Mercedes, you must be prepared to invest in a car that matches this brand – you will not get a Mercedes for the price of a Fiat.
