Improving UI Estimates
I recently lead a team discussion on how we can get better at estimating how long it would take to build new or edit existing components of a website. Most people's thinking was clearly focused on the tasks at hand, forgetting a lot of additional considerations.
At one point in my career I was asked by somebody to change the text colour of something to red, which they expected to be done in less than a minute. Crazy right? I mean I just need to look up the hex colour of red and add that to the CSS. The reality is, it's not always that simple.
Here I'll share the additional considerations that go into even the simplest change requests. By understanding what's involved in such a change, you'll realise that there is no such thing as a five minute task. It's worth mentioning that not all the below are relevant for every project, but it doesn't hurt to double check an estimate request against this list.
Setting up
Is this a project you've worked on before? If so, it's likely you have this already installed on your machine and you're ready to go. PMs should know who has the most experience with certain projects so resources should be picked based on knowledge. That said, if you haven't worked on something before, it can take time to set up a project and get familiar. Personally, I've setup projects which range from five minutes to half a day. The larger more complex systems to get up and running always require support from another developer (sometimes more), so it can quickly get out of control time-wise.
Legacy Projects
I look back at code I wrote the previous week, and I always say to myself 'Why did I write such terrible code!'. We have to deal with a lot of legacy decisions every time we jump into a project, so spending a while figuring out what's going on before plunging in can save time and reduce issues in the long run.
Semantics & Accessibility
I've chosen to group semantics and accessibility since these will start to become second nature to you as you progress in your career. You'll no longer need to look up the correct way to semantically mark up breadcrumbs, or how you should tab-index your complex header navigation. There are a few things you need to constantly check though. In the example of changing the text colour, has it passed colour contrast rules to meet your accessibility standards? Be sure to raise any concerns where you won't meet your accessibility goals early. Ideally colour contrast would be checked at the design stage, but I understand designers don't like to be restricted as a 100% accessible colour palette is very limiting and won't fit every brand.
Cross browser testing
Time spent on cross browser testing can range wildly depending on how many browsers or devices the project requires supporting. With good analytics data this can be narrowed down significantly. Also remember you'll need time to fix anything that you find in your tests.
Unit Testing
Does the project have unit tests or end-to-end testing? Writing a test is equally as important as writing the thing you're testing in mid to large projects. It's quite reasonable as well that for every one line of code in the actual application you have 6 or more lines of code in the test.
Animations
Something else to consider, but not necessarily for every project or task, is animations. Ensure there's enough time to add some visual flair that's on-brand and enhances the user experience. A review by the creative team wouldn't hurt here as well.
Styleguide
Any decent sized project should have a styleguide or a code asset library. If you're adding new things or changing an existing feature, remember to update this! The next person who comes along will thank you for it. Remember to include any documentation here if required, such as recommended image sizes. Updating the actual component and updating the styleguide can be doing the same work twice (Unless you have a unified component setup).
Setup/Content entry (for review)
So you've built the new feature, you'll need to add it to a staging site where it can be reviewed both internally, and once approved, reviewed by the client. Does there need to be any CMS configuration needed to get what you've built into a presentable state? Minor documentation or a short walkthrough might be required here.
Discuss mobile designs
From experience, it's quite common for designers to miss out mobile and tablet views. Maybe it's supposed to be a quick project and we just have a desktop mockup. Discuss with the design team how they think things should work if it's not clear. I usually say everything will stack on mobile, as traditionally the right column drops below the left. Unfortunately, sometimes that doesn't always work out and you'll need to get a designer involved about how they would expect things to work on mobile. Some thinking time on your side would be useful to present viable solutions to make the discussion easier.
CMS
The fun usually comes when the module you've built gets hooked up to a CMS. Again, with time you'll learn how to best deal with issues like the client adding images smaller than the recommended size, or they decided to upload a few paragraphs into a button. Where integration with the CMS is the task of backend developers, it's helpful to let them know what should be marked as required in the CMS or if any size limits for images or text should be added.
Performance
If the feature is big, there has to be some performance testing. Similar to cross browser testing, you'll need some time to analyse any performance data and action any improvements you can find.
Conclusion
As you can see, there is a lot to consider when taking on a new task that can easily turn into a few more ours than you originally thought, especially for somebody who's new to the project. Familiarity with a project or more knowledgeable in code will have a fairly significant impact, however there's nothing that will make a simple piece of work less than 5 minutes if done properly.
Is there anything else you consider when building frontend components? Let me know.
