A story about planning
As a frontend developer, one of the hardest things to do is to implement a modern looking, functional and ideal UI with an old, under-performing backend.
We were recently in this situation and it was a tough one. The design and the backend are not bad on their own but each has a different story. The UI wants to be a colorful, intuitive interface with a modern and user-friendly visual language but also too ideal, taking into consideration ideal cases. This small shortcoming is highlighted by the backend. Some things are done over the hand and some things are outright careless but more on that later.
I believe that these 4 tips shared from our experience will help other in this situation.
Don’t make big compromises in the frontend code
I’m sure you’ve read that before and indeed it’s important but what we think is overlooked in this context was the fact that the design has to be supported by what the backend is capable of doing. So what this means is that if for a drag and drop you need to do 3 requests to the server then probably the design should not contain drag and drop. These kinds of scenarios will make you work extra hard to keep the code clean, optimized and it will take extra resources i.e. time.
It also has a butterfly effect bad code creates more bad code and takes more time to maintain down the line. But how do we avoid this nightmare (as a UI/UX designer/developer)? I would say the first and most important thing is to involve in the creation of the design of the backend team also. One of our values is to offer clarity to those we work with. So going through a process of evaluation of what is necessary or not for the design and visualizing, along with the backend team, how the design (or at least big features) are going to work, will make the frontend construction a very pleasant experience.
So the first practical tip: get together with the designer and the backend team and one by one, explain/clarify every big feature.
Make sure the UI/UX is completed
This tip is again about the UI design. Very important — the design needs to be complete and not show only the ideal scenarios. Let’s take the simple view with an image on the left and a text on the right. It seems pretty simple and straight forward to code that right?
But what do you do when the object behind that view doesn’t have a valid image or the text is too long and goes on the next line? Sure we can improvise but the moral of the story is that it will add time: time to go back and forth with a proposed design, time to ask follow up questions and so one. This effect is magnified when you’re dealing with a more complex view.
Practical tip: split the design into small chunks and try to find all the states of that view. It’s a lot of work I know but it saves you a lot of pain down the road. It gives you the opportunity to reevaluate the estimation and effort that will go into that project. So these 2 tips are more practical and they involve some work with it will make your job as a frontend dev easier because you will have a much clearer understanding of the data flow into the app.
So if you are still here let’s continue with the last 2 tips.
Lock down the design
This is pretty self-explanatory. Once the design is ready and you are happy with it, lock it down. Nothing should change from now on till the first version. Of course, if something turns out to be flawed it should be reconsidered.
But if it’s: “let’s make this header bigger” or “let’s make this magenta” no changes should be allowed. Put it in your contract if you need to. These kinds of changes are beneficial for no one. It creates over-head with new design and impacting the current design. Also — very important — it makes scope creep very hard to happen.
A practical tip here would be: have a contract clause for changing the scope of the work. In case of scope creep the contract terms should be renegotiated alongside a penalty or the possibility to withdraw from the contract.
Always plan for the unpredictable
No matter how organized and now perfect the project will be, unpredictable stuff will show up. Take extra measures in your estimations because most of the time this is where the project is affected — time and money.
Practical tip for this one: when doing the estimation add a percentage for the unpredictable scenarios.
Hope these tips are useful as they would have been for us before starting.