or: How to Manage and Control Web-Frontend Development
We want to be agile, sometimes we cannot, but we can take some lessons we learned to make waterfall better.
At my work I am are consistently confronted with huge frontends. Sometimes these are just dumb, maybe with a CMS. In some companies, the final layout is given to the frontend developer, and he will do his magic. Doing this is a cheap solution to the problem – until it is not because the project ends up like a Tetris game you are losing. Parts do not fit, and the ones you need are missing.
Let’s do it better, with a simple solution.
Layouts for websites have many dimensions. There are animations, interactive components, and expectations about the configure ability in the CMS. That is why a complete design file is just the base for your communication about what has to be developed for a functional, complete frontend. In this post, I want to show you how to transform a large layout into something manageable. With the result, you will have a proper base to developed the frontend.
If you are already working agile, this system might not be a very useful addition, but if waterfall is your burden, it will help you.
Maybe your company does not want to assist you, or can’t – then you can use this system to manage the work they give you. It will help you to ask the necessary questions.
Let’s start with what we need to avoid:
Top 3 Problems while developing frontends
You forget requirements and tasks
It is planned, maybe you put it in the wireframes but now it is missing in the final layout, or the developer overlooked it. That means your estimation is off, and when you think you finished the job it in time, you did not.
You interpret things
Some things look obvious solely because you do not know everything about it. People think different, even with the same amount of information. This leads to two problems: You develop too many features and waste time, or you do not do what’s needed, and then again you think finished the job it in time, but didn’t.
People make bad promises
Bad promises are base on interpretations and faulty estimations. It is easy to overpromise and underdeliver, but doing this is unprofessional. Only guarantee things which are founded in knowledge and confidence, nothing else. You cannot do this if you ignore the first two rules.
Bonus: You just don’t know
This situation is dangerous. You need to know how something should work and nobody knows – but you have to deliver it because it was promised to your new customer.
Let’s prevent the frontend chaos
There is a very straightforward process to avoid these pitfalls. Developers will not even have to learn something new; it is part of their nature: Build modules.
I would do this step as early as possible in the development of the product. If you create wireframes, that is a good point to start. This will help you to keep an overview, and it will make it easy to talk about everything without confusion.
A module is a collection of related elements. Think about it like you would about a website builder, would this be one element the user could put into his site? I would recommend creating many small modules, instead of some big ones. This will make the next steps easier and will prevent overly complicated CMS interfaces.
Now find global, unique names for your modules. These names are meant to be used by everyone, always. Keep the names simple and try to have a small vocabulary. If you find it hard to have a short name, your module is too big. If you cannot determine a unique name, the module is too small.
Check if everything is at its place
When you created modules out of your wireframes, read the documentation. Is everything in the wireframes part of a module? Is everything there you sold to the customer? If you do not have wireframe, do the same thing with the layout.
Check again when you created designs out of the wireframes. You would not image how often something is missing by accident.
Define modules and make them testable
After you cut your frontend into little pieces, you nearly won! The first thing you should do is to create an image of the module, screenshot the module in the wireframes, or layout depending on your progress. This will help you to connect the visual with the information we will collect about it now.
This is a team job, invite your whole team to do this:
- figure out what the module can do
- and how they are configurable
This step it essential, because this information is often just in the head of people, or written in the documentation, where this is laborious to find.
Have the right assumption
Everyone in your team should understand, that what you do not define in this step, won’t be done and shouldn’t be done. They need to know, that it is important to think now and to take this serious.
Write down all the states, how they happen (can be in the name) and what they are doing with the frontend. The designer might not be able to design every state, because of budget and time concerns. Even if that is possible, it is easy to forget a state, so be curious and find them!
Interactions are everything the user can do with the frontend in the browser. A simple example would be a hover effect on a button. A more complicated thing is something like a slider. If the user clicks a button, into which state will the slider go?
Find configuration options
Clarify what is configurable in the backend and to what extent. Background Colors, Size, hiding elements and so on.
Try to put down concrete numbers. I understand that the slider is meant to support an unlimited amount of images, but how would one test that? Just write down a large number, like 100 images. This ridiculous, but doable and testable. Everything you write as requirements should be testable – if you cannot find a way to verify it, it is not a valid specification.
How does this help?
Easy. After you collected this information you get the following things:
- The whole team has an overview over and a feeling for the project.
- Having all the modules figured out you know how big the project is in reality. (In many cases, it is more work than you thought.)
- Now it is simpler to make a more realistic estimation of the development time
- You have all the happy paths to test the module, everyone in the team can check the states, interactions and configuration options – because these are documented outside of brains.
- You can avoid unnecessary work, because you developed your interpretation, instead of only what was needed.
- You are avoiding stalling progress, because you need to go back and add missing functionality, into something that wasn’t built for it.
Write down, do not tell
It is always possible that the modules will change in the project process. Be transparent about it, communicate it and updates the module definitions. Write it down, don’t just talk about it. The documentation about the modules are your single source of truth, don’t do stuff that isn’t written down in the module definition!
Planning and avoiding deadlines
Part of the Module definition are the estimations. I would suggest doing three of them. One that is optimistic, one that is realistic and one that is pessimistic. Estimating like this helps to think about the issues and problems you might face, and it looks like a guess (which it is) because you create a range.
After you estimated all the modules, take a calculator and add them. You end up with three numbers. Compare the results with the deadline. If you have to meet all the optimistic estimations to finish the work in time, prepare to break the deadline. This is no a pleasant situation, but the only antidote to suffering is the truth.
Last, but not least, add a priority to your cards use these to figure out the order you will develop the modules in, maybe talk with you customer about this.
If you have to break the deadline proper priorities enables you to create sets meaningful modules, which provide the biggest value, while still missing the deadline.
This is it
The central strategy of this process is to keep complexity low, by dividing and deconstructing it, ask yourself if you are doing this. The goal it to keep an overview of what has to be done and what is done, by beeing transparent.