In a hurry? Avoid these common pitfalls when starting a new project.

We all know this one: a development project is about to start and there’s a rush to get it done fast. The bigger the hurry, the less time the team tends to have to concentrate on quality and the greater the pressure to take shortcuts.

During times like these, it can seem very hard to justify a slower start, but spending the time to do things properly the first time around will save time and effort in the long run. Even if it’s at the expense of slowing the project down for a short while.

Projects can face many kinds of problems because of shortcuts taken in the beginning. Even though I’m writing from a designer’s point of view, these issues concern the whole development team.

Here are six of the most common and dangerous pitfalls that will cause problems toward the end of a project if not properly taken into account from the very beginning.

Not defining measurable goals from the start

Everyone knows that data and analytics are important, but there are vast differences in how different organizations handle this data. Our data maturity model is a good place to start when trying to figure out how your organization handles data at the moment.

In immature organizations, analytics might be treated as a feature to be implemented without really setting any goals. Even more mature organizations often decide on the metrics late into the development of the project because of an initial hurry to start development.

Either way, there are major benefits to deciding on your metrics as early as possible. Knowing what metrics matter will help make more informed decisions regarding the product. It’s also very important to convey these metrics to the entire team. The development team is full of talented people, and keeping everyone in the loop is extremely beneficial for the project. Development teams tend to feel and work better when they know what is expected of them and the end product.

Metrics should also be applied to individual features. This might not be possible or relevant for every feature, but for most of them, the team needs to be able to measure how that feature performs.

There are many ways of categorizing metrics. One of the most useful is by Alen Faljic. He divides metrics into two groups: design metrics and business metrics. In this model, design metrics relate to the value gained by the actual users and business metrics tend to relate to things like revenue, costs and user base.

No matter how you define your metrics and KPIs, if you don’t keep measurability in mind, a project can easily become a feature factory that is more obsessed about creating new features than making features create impact. Using metrics also gives us valuable feedback that can be used to plan future development.

Not validating or testing your design

Metrics help guide the design work in the right direction, but without feedback from actual end-users, we won’t know if the design has an actual chance to succeed. Feedback should be collected at every phase of the project.

Constant prototyping goes a long way here. Prototypes can be used to demo the features to stakeholders as well as for testing. During the design process, prototyping also helps with figuring out potential problems in the current flow.

When it comes to testing, you really don’t need a fancy usability lab. Just identify where you can get a hold of potential end-users and try to get feedback with your prototype. There is naturally a time and place for more formal usability tests too, but when your product is ready for proper testing, making larger changes will be more time consuming and expensive than if these problems had been caught at an earlier phase.

Validating designs is not limited to just testing with end-users. They also need to be validated with the entire team. This means demoing and discussing the designs with developers, testers and stakeholders. This is necessary to make everyone understand the goals and reasoning behind the designs, as well as plan how the development and testing should be implemented. And most importantly, if the designs are lacking or otherwise not possible to implement, changes can be made to them before development begins.

One example where this worked especially well for me personally is when I worked with Tallink Silja. Terminals tend to be full of passengers that have time to spare before their ship departs. I did many quick tests with prototypes for features this way and usually got really relevant feedback. Many features were either left out or redesigned as a result of these hallway tests. After the initial designs were done and discussed with the business side, a demo was held for the development team. This demo often resulted in changes and additions to the initial designs before the actual development started.

If you don’t validate your designs, there is a much greater risk that the project will end up creating something that does not fit the needs of the end-users or that some problems will be noticed in the design later during the development process. As always, fixing problems will be the more difficult the later they are identified.

Not having a design system mindset

A very simplified way of thinking about design systems is as component libraries with guidelines on how to use them. This definition is of course massively simplified, and the amount of work required to create and maintain a proper design system should not be underestimated. In order for a design system to make sense, the organization or product usually needs to be large enough and, in many cases, the effort of building a fully functional design system could be put to better use.

Even if you are not building a design system, it’s very important to have a design system mindset when starting a project. This means that you should design and develop components once and then use them in a consistent way throughout the product. Instead of starting to implement features right away, first take a step back and take the time to properly define the most common components and design tokens and create general design guidelines for the product.

Spending the time to properly create these components and collect them into a separate library will dramatically mitigate the risk of redundant work. Having design guidelines defined and properly communicated to the developers from the start will also increase the uniformity of the product and, once again, save time by avoiding the need to constantly tweak layouts throughout the development process. As an added bonus, if this work is done properly and the need to create a design system comes up later, you are already on the right track.

Accessibility as an afterthought

Accessibility is not just about people with disabilities. It’s about making sure everyone can use your product. Often good accessibility is also just good design. Neglecting accessibility at the start of a project is still unfortunately common. ”We’ll fix it closer to launch” is something you hear when shortcuts have to be taken.

This way of thinking brings about two different issues that could easily be avoided. Firstly, designing and coding things to be accessible from the start is always less work than fixing these issues retroactively. Secondly, if accessibility is not taken into account from the very beginning, previous design and development decisions might make genuine accessibility impossible for certain parts of the product.

Accessibility is not rocket science. As a matter of fact, to a good designer or developer, a lot of the things that make good accessibility should be self-evident. A good reference to keep in mind is the WCAG 2.0, which is basically the core of the EU accessibility directive. And if you are working on a mobile product, you might want to look into the updated 2.1 version, which adds more mobile specific guidelines.

Accessibility is especially important to keep in mind when designing the most frequently used components and functionalities of the product. Design and develop them well the first time around so you don’t have to come back to them later.

Not writing enough documentation

Writing the right amount of documentation can be tricky. Creating and maintaining proper documentation comes at a price, but it will save time and money when there are, for example, production issues or multiple teams involved. Your personal email archive is not documentation and neither is your project’s Jira ticket history.

Of course, it’s also possible write too much documentation. If you do this, you will most likely waste people’s time on writing something that no one will ever read and that will expire soon anyway.

The design guideline is one type of documentation we already talked about. If written, communicated and maintained properly, design guidelines will save a lot of time during the development process and help ensure that the product is consistent in appearance and function.

Business decisions also need to be documented. This can usually be done by simply writing notes on meetings and storing them somewhere where anyone can access them. If these decisions have not been documented anywhere, trying to figure out non-technical reasons for certain solutions can become a huge hassle, especially if people change in the project.

The initial application/feature documentation, or “the spec”, is usually written by designers and is a part of the hand-off from designers to developers. While writing this is beneficial, the written document is not as important as the actual communication between designers and developers. A good spec defines the main cases and exceptions but is written so that changes can be easily made to it where needed. As with prototyping, writing documentation can also help with figuring out new edge cases that nobody thought of before.

The level and style of other, more technical types of documentation, such as architecture and API documentation, can differ greatly from product to product and there really is no silver bullet here. What is important is to define what to document, how and where.

And last but not least: cramming too many features into the MVP

This issue is by no means unique to projects that are in a hurry and is something I still see and hear about way too often. A project sets out with a way too large scope, often accompanied by an overly optimistic schedule.

Everyone has heard of the MVP scope, but many organizations don’t understand what it actually means. For example, the first release of a product might be called an MVP even if it is way too large to begin with. Scope creep can infect an otherwise sane scope and make it bloated by the end of the first release. Also, as the size of the first release grows, fear of release can kick in and create even more delays.

There is a rather simple solution to this problem though. Define the MVP scope as strictly as possible, but make it clear that the MVP doesn’t have to be the initial public release. What is important is to get out a working version that has the minimum required functionality for release to a group of people that are not part of the project.

The biggest reason you want to do this is to start getting feedback as fast as possible. The larger the scope, the larger the probability that you’ve developed something that will not be needed.

Budgets and organizational culture can also come into play here. Fear of having your funding cut or an organizational reluctance for public releases often can lead to cramming the first release as full of features as possible. In this case, it’s perfectly fine to make an initial backlog with a lot of features, but it should always be possible to make changes to the backlog during the project.