Frontenders, Estimates, and Improving Interfaces
So I’ve recently joined a new company as a frontender in a UI/UX team, and I was providing my first estimate. After being given an initial deadline, I quickly worked on breaking down the project into small tasks, like so:
- Task A: 3 hours
- Task B: 2 hours
- Task C: 4 hours
- Task D: 2 hours
- Buffers and contingencies: 5 hours
That’s a total of 16 hours which, assuming I was able to put in 5 hours of actual coding per day, translates to 3 working days. That’s what I told my peers, and before long I realized I’ve made two mistakes.
1. Overestimating Coding Hours Per Day.
I’ve already noted in an older post that on any average day, without doing overtime, my actual coding hours are typically around the range of 3 to 4 hours, depending on how much non-coding tasks there are.
I have no idea why I was expecting myself to put in any more hours than that; was it forgetfulness or was it unrealistic optimism spurred by the start of a new job?
In any case, that was the first mistake I (and many others, I’m sure) made in my estimate. We must never forget that our job is not just about coding, but also communication with our peers and clients. With our jobs come the regular and necessary commitment to emails, progress updates, meetings, impromptu discussions, and other administrative tasks that keep us up to speed with not just the team or clients, but the company as a whole.
According to my experience and personal time tracking data, I spend about 50% of my working time on coding and 50% on communication, on average. You might think the communication part is excessive, and I used to think so too, but now I’m starting to realize that communication is as important as coding. I’ve had bad experiences whereby I’ve spent good time putting in the hours to code up a feature, only to be told at the end of it that what I’ve coded was not ideal, and that I had to rebuild those parts. That’s the result of bad communication. As coders, we tend to like going into the zone and feeling spectacularly productive, but without periodically communicating to people around us, our focused efforts can end up being futile.
2. Not Estimating the Hours for Improvement.
More often than not, when coming up with estimates for a project, I tend to focus only on the time that is needed to finish our tasks. As a frontender, this means considering only the effort that is required to translate a set of designs into their corresponding working pages.
The problem with this approach is that I wasn’t factoring in the time for improvement. Given any design, there’s always the room for improvement, for thinking of ways to enhance the user interface. But if I’m only estimating the time needed to do exactly what the designs have stipulated, then I’m not giving myself any leeway for brainstorming and improving on things. Worse, my estimate and the resulting (usually tight) schedule is going to narrow my role down to that of an implementer of designs.
But that’s not what frontenders should be.
Frontenders are the first people actually interacting with the design that designers had envisioned, so we should be the first ones to recognize if an interface can be improved. But if, from the start, we narrow our roles down to pure implementation, then we’re going to ignore this aspect and concentrate on the implementation per se.
In my opinion, if we could just include the estimate for improving the interface from the start, then we’re telling ourselves to periodically—with each subtask, perhaps—step out of the shoes of a pure implementer and consider the interface critically, from the perspective of a user. There’s no guarantee this exercise will render results, but enforcing this habit will help build our muscles for picking out areas to improve on designs/interfaces, and internalize the fact that improving the interface is part of our job.
An added advantage to this is the fact that managers or clients or designers will now see improvement estimates in the workflow and recognize that frontenders should not just be pure implementers, but play a part in improving the interface as well. In my case, especially, since I’m now in a UI/UX team, it is all the more important that I help deliver improvements to the interface and user experience, and not end up being a pure technical implementer.
UX = Good Design + Good Development.
There’s only so much a good designer can do with his prototyping tools. As long as our final products are rendered and served on the browser, we need developers to help make sure the designs are providing good user experience, by actually scrolling and clicking and testing out the design concepts on a browser.
And the first step to that, surely, is at the planning phase. As good plans help lay the groundwork for good work, plans that actively include the room for improvement will help lay the foundation for improved interfaces. On my part, I’m going to start adding estimates for improving UX in my next project and see if it is going to work as I’ve described. I might even write another post for that. Till then, stay tuned.