Today, I recommend an excellent two-part article by Taylor Hunt.
All frontend-related professionals should consume content like this daily. However, as it goes with all materials, it is important to read it critically. So, I can’t help to think if and how I would’ve behaved if I was a Frontend Architect in his organization. Would I’ve done anything differently?
Obviously, we can assume that he couldn’t possibly mention all of the things that he thought and considered while working on that optimization project. Therefore, my observations cannot be taken as real criticism, since I only have a partial understanding of his journey.
There is much value in academic and/or curious investigations. But in terms of the market, given that time is money, I wonder if his time (and his team’s time) could’ve been allocated better. Nonetheless, without detracting any value from this research, I wanted to raise some Frontend Architecture considerations.
1) Did they consider the detrimental effects of UIs that are too fast?
I have the feeling that they did think about this. However, maybe I would’ve stayed on that point a little longer. After all, “premature optimization is the root of all evils”. And, as some researchers point out, there is such a thing as “too-fast UI”.
A quick search can show us many articles about it, but I chose two: this one and this one. In other words, were they spending money to harm themselves? Was there anything more profitable to be done? I really encourage people to rely on quality data to make decisions like this. Products like QuantumMetric can help with that.
Also, in regards to e-commerce, I remember reading an article years ago in which an improved UI, which felt almost instant, caused a drop in sales. Apparently, most customers were computer-savvy and were used to expecting for a couple of seconds for their orders to be processed. When that did not happen, they assumed that an error occurred. The new customers thought that they had been targeted by a scam that just captured their data. And some elderly and people with disabilities, who often rely on that page re-rendering as a visual cue that things were completed, kept staring at the screen for a while until noticing that all was already done. In fact, that has happened to me.
2) Was that the top priority?
I am all pro “divide and conquer” approach to project development. However, especially in a time where the Voice of the Customer (VOC) is the main source of directives for new work, I would assume that they (the customers) could’ve had a list of more desirable features and improvements. Or maybe not.
If speed was a top request, great. Otherwise, I would’ve put it back in the backlog. The only way to know for sure is by analyzing data. It made me extremely happy to see that they did in-person interviews and investigations. That is amazing. But usually, we need to contrast that with data from a much bigger pool of users and a longer timeframe, usually captured by a system like Hotjar and QuantumMetric. Tylor and his team are obviously super smart, so I assume they thought of all this. But since it wasn’t thoroughly discussed there, I thought of writing it down here.
3) Pressure the backend teams
Part of what I consider my responsibilities as a Frontend Architect is to provide the frontend developers with all they need to succeed in their work. That often involves stepping in and engaging in discussions (fights) that they don’t have the time or interest to be in.
Throughout my career, I noticed that a lot of pressure falls on the frontend teams, expecting miracles from them, while the DevOps (infrastructure), Backend, and Database teams are treated as delicate china plates. Managers don’t like to shake them too much. But given that the Frontend is always been updated anyways, they feel more comfortable keeping the hot potato with the Frontend teams.
However, if I want to be successful in the eyes of my supervisors and really help the company to prosper, I must find ways to get all teams to work as they should. Therefore, I do fight back. Not that Frontend teams shouldn’t care about speed, because we should. But it is like a Formula 1 car: we cannot oppress the design team to engineer an ever-more aero-dynamic body, while letting the other teams take it slow on the engine, electronic components, etc. Computer systems are composed of multiple parts, and teams should share the responsibilities.
When we accept the old story “the others teams cannot do anything, let’s fix this on the frontend”, my teams’ focus shifts from innovation to an oppressive and complex work of optimization. That is not good for employee retention and reduces my ability to fulfill other goals in Digital Transformation. Also, at that point, the whole company would start to wait on us to fix the speed issue, not remembering how unreasonable that can be. The ball will be in our court.
I feel Taylor’s pain, especially when we do not have much authority to push back. Sometimes we need to budge for the sake of the company and of our employment (I’ve been there). But once hired as a Frontend Architect, I saw no option but to fight and to hold every team accountable for their part in the project.
If I must ensure high performance of products and coordinate an efficient/effective Frontend Shop, you can be sure that I will fight a lot to get all parts of the machine to operate well. And even if I lose the battle, I will continue to find creative and strategic ways to go back there and win it later on. As a Frontend Architect, I have the time, knowledge, and reach to do that. The Engineers don’t, as they are consumed with actual work.
Employee retention in the frontend scope starts here. And if I lose teammates as well as time to work on innovation, then the project loses competitive power, my reputation gets harmed, and the company struggles. There is always something on the backlog aiming to improve the apps. So, if I am going to invest in speed, I need to be sure that that’s a priority. Otherwise, I will push back and transfer the work to the piece of the system that is most behind in its optimization capacity.
Conclusion
I hope you take the time to read Taylor’s article, and that he writes more things like that. It is not every day we meet such a thoughtful professional. And while I did have some thoughts about his journey, I wasn’t there, so I don’t really know the full story. Either way, it was a very profitable reading.