Rehauling UI made easy
Most fast-moving startups encounter this roadblock sooner or later in their dev cycle — “We’ve built a pretty functional product, but the product ain't pretty”. It’s just one of those costs that teams pay for moving quickly — overlooking the UI.
Our team over at P2P started to have the same conversation at around mid-February, but given the task was a giant one, we were on the edge. We finally bit the bullet in March & started the rehaul & here’s what we learned along the way —
All hands on deck isn’t necessarily the best approach from the get-go
A clean architecture dictates that you have a solid foundation. What everyone seems to overlook is the fact that laying the foundation is certainly not an easy task & can get extremely hands-on with a few key decision-makers calling the shots. In these cases, having multiple people work on this foundation just means there’s more chaos to handle for the people up top, taking these architectural calls.
Besides, not everyone in the general app team (heck, not everyone in the front-end team) would be well versed as to how these basic components need to be laid out so that as the app grows we can pretty much work without altering them (Remember alterations to these have ramifications to many other places where you wouldn't expect)
In most cases, using a third party library DOES make life easy (even if you still need to alter things)
‘Every app over a certain complexity uses a framework. Either you use a third-party one, possibly with lots of developers and good support, or you develop your own and then you have to maintain it yourself, but either way it’s still a framework.’ — Lalo Martins, (Project Manager at P2P)
Our project started off with Library A, and then a few weeks into development, we decided to scrape it off, go rogue and write our own custom components for everything… eight months down the line, we realize maybe writing custom components isn’t our forte.
As with how most of the software development space is headed, companies should ideally focus on doing what they do the best & then rely on quality 3rd party libraries to do the other things for them.
Remember how I said, “most” and not all. There are certainly many applications where the size of the application matters as shipping all the unnecessary stuff that a third-party library comes with, does come at a cost.
Moving fast first & then slowing down
This, I do believe, is one of the things which we did right even if it didn’t look right from the get-go. We started designing our components to look “roughly” like how our designer's eventual goal was, but not to pixel-perfect accuracy.
This meant we could keep pumping out sections in the app that looked… well roughly how they should look like to the naked eye, allowing us to ship the app to production and then take another week to iron out the creases and have a picture-perfect implementation…
Remember, if you did your foundational work right, then this pixel-perfect implementation shouldn’t take too long, all this method allows you to do is buy yourself some time/ have a quicker release to production.
This is how things looked in the first week
This what a couple of weeks of “all hands on deck” effort looked like
And this what another week of going back and cleaning rough edges up looked like -
Treat your CSS like you treat the rest of your architecture
One thing, which I quickly learned was that how clean, CSS too can be written if the time is taken to set things up. Just like most good firms treat their codebase to be sacred ground, protecting it from rogue magic numbers being thrown around/random practices being used to “just get the job done”, CSS should be treated in the same fashion.
From declaring constants from the very beginning to leveraging selectors, if these things are well thought out (and subsequently, well laid out in terms of code) you can pretty much build the whole app from top to bottom without writing magic hex values anywhere, everything is flowing into your CSS/SCSS file for a reason and simply giving the file a look should give you an idea of what’s happening
Don’t wait for QA!
This is one of the things we somehow naturally ended up getting right. A lot of these changes require pixel peeping chances are if you don’t have some fancy automated system that does this for you, your QA folks will be having a hard time co-relating things between your design tool vs your development builds. Whom to rely on then? None other than your UI/UX developer(s)!
They are the ones who chalked these designs up, they don't even need to pixel peep to know if something’s off. Guoming Xu, our Product Manager & lead UI/UX developer naturally wore multiple hats during this big shift, sometimes working as Product Manager, but again, reviewing our builds regularly and providing the development team with regular reviews, which kept stuff going in parallel quite smoothly.
Using an amalgam of methodologies doesn’t hurt
We wanted our redesign to be as “reusable” as possible moving forward. This meant that tomorrow if we decide to botch the dark theme and move back to light, it shouldn’t take a month to do so. Similarly, on-the-fly theme changing should also be a feasible possibility moving forward.
As a result, mixing SCSS, pure CSS & leveraging the strong points for both really helped us.
Wrapping it up…
Finally, set realistic expectations for this process. We started off thinking this is a piece of cake and will be finished off in no time, but even with 3 developers working night and day it took us good 3–4 weeks to finish everything up. Having a word with upper management helps!
