We all use UI. Log into Gmail – UI. Need to update Salesforce – UI again. Even using your desktop OS – one more UI. Front-ends seem so ubiquitous, so how hard can they be to make? But when you get into building and maintaining complex software – somehow the UI piece seems to take forever.
You rarely see UI projects that go completely smoothly. Some enhancements or features that seem complicated (e.g., virtual-scroll) come out fast, and others that seem straightforward or commonplace (e.g., internationalization, UI access control) take a very long time. And for sure, getting “my basic application running” always seems to take forever and a day – but it feels like a workable UI should not be such a big deal.
Whether building an internal or external facing application, people are continually asking me why the UI takes so long? Whose fault is it? Who do we hire or fire to fix this problem?
In my experience, this turns into an unproductive blame game. Some people blame the project’s management, claiming that the Engineering Manager or Product Manager isn’t on top of things and isn’t adapting quickly enough. The other main scapegoat is engineering – claiming the team uses second rate engineers/contractors (due to lack of available budget/talent). These are undoubtedly potential sources of problems (and having top-notch talent and an unlimited budget can solve many situations). More often than not, I have found that the real issue is misaligned planning and expectations due to the lack of understanding of issues involved in making a competent front-end.
Most people think of a front-end as the content that they can see and click on their screens. But those texts, images, buttons and other such content are only the User Interface (UI) – the visual elements you can see and interact with. This is the tip of the iceberg that comprises a front end. The majority of the front-end system that powers and makes the visible UI possible is all of the infrastructure, data, and components – to your user, the unseen part of the iceberg looming below the visible surface. And yes – the iceberg metaphor is often overused. But it is extremely apt in this situation. What you see above the water, is LITERALLY what you see in the UI.
This article details how much work front-ends really require… and how your engineering team spends their time in the 3 key phases of front-end development: MVP, Enhancements, and New Features. We conclude by discussing where automation can streamline this process and shave weeks, months, or even quarters off of your time to market.
Getting to MVP or 1.0
This is the process of getting from nothing to something. It is how you start. When starting a project, the common wisdom is to get to market as quickly as possible. Realize, however, that any scaffolding, features, or integrations omitted to reduce your project size MUST be built later to scale up. So any time saved really incurs technical debt – time deferred PLUS the additional time to refactor/rebuild (fix) the original implementation.
There are three main components to getting your front-end out the door:
- 55% Common Features – This is visible UI
- 25% Application Scaffolding
- 20% API Integration
As a rough guide, it takes almost the same amount of work to get the part of the UI feature you see running, as it does to get the supporting infrastructure in place to make it work.
Common UI Features (55%)
This is what you think of as a UI. These are the visual elements that you see when you log into your favorite application:
- Navigation
- Dashboards
- Visualizations
- Table views
- UI Styling
- UI Interactions
But remember, even these visual elements are more than just the pie chart or link you can see – the tip of the iceberg. The advent of UI libraries of buttons or visualizations makes only a small dent in the time needed to implement a common UI feature. Someone needs to get data in and out of the UI element. Someone needs to tell the system what happens when you “click” the button or wedge in the pie chart. Laying out these elements, making sure they have the right behavior, visibility, etc – that takes a huge amount of time. Every interaction, hover effect, or link must be hand-crafted. And all of those other aspects are likewise below that water line.
Application Scaffolding (25%)
This is what makes your front-end “work.” This work is entirely “below the water” and is never directly seen by users, but you feel the effects of it every time you use a UI:
- Defining the web application architecture
- State Management
- Separation of concerns
- Layouts
- Authentication
- Routing
This design and infrastructure is vital. For example, let’s look at State Management. Consider a “save” button – will it be enabled or disabled? This is determined when a user changes the value in an input field (and that field is valid). Connecting these two UI elements is “state management”. You can implement this slowly or quickly — but quickly will mean you will likely need to rebuild it later on, as state management can end up becoming one of the most complex problems in user interface development because the number of components, inter-component interactions, and dependencies grows massively and exponentially.
API Integration (20%)
This is not the work to build APIs, nor is this getting data into the pie chart. API integration is the “conversation” between your front-end team and your back-end team – ensuring that the data needs of the UI (and performance needs of your customers) align with your backend or services. This effort usually includes:
- Data schema validation
- Making (and testing) API calls
- Data flow integration (and debugging)
Of course, every time something changes or “evolves” the back-end or API layer, it likely causes the front-end team to be forced to update their API integration. Note that these back-end updates are rarely backwards compatible for the UI – so your UI cannot just limp along after a change, it must be fixed/updated immediately (and any test suite for the UI must be changed as well). What is worse, many UI features are often held up as the team awaits the API and back-end to catch up to the front end needs. Needless to say, this entire section also lives below the water line of visible UI.
Going into Overtime!
Oh wait – you thought your MVP/1.0 was done? Not quite yet… Of course, there is also overhead which will make projects go into overtime. Doing QA takes roughly the same amount of time as building your front-end itself (+100%). Ideally, this is done 100% in parallel with the front-end development, More likely it will be offset by 2-4 weeks, and is often started only when the project is 50-70% complete.
Another thing that can push a project over is bug fixes. As a rough estimate, this can be an extra +10% of the original project length. Here is where skilled developers, good project development processes, and solid testing methodology/tools can help, but bugs always happen.
Lastly, DevOps (CI/CD) process cuts into project development, adding in an extra +25%. Techniques like GitOps and structure around Pull Requests can help, but simply working in modern applications imparts overhead. Otherwise, you will get to the end of your build cycle – and nothing will have been tested, deployed, or integrated. This overhead is actually an investment in future success – it helps create an application that is robust, documented, and tested – but you must pay the price for this future stability.
In a best case scenario, everything that can be done early or in parallel is done early and in parallel. This will likely only cost an additional 50% above and beyond the original scoping. But if QA is started late, and bugs+CI
Maintenance + Enhancements
Everyone thinks it is party time once the MVP is out. But in reality, we are just trading one challenge for another. Whether you are using CI/CD, waterfall, or some other approach to release cycles – development simply takes time.
While the size of the update/enhancement increases the time required, the underlying process for engineering takes the same amount of time (once any mockups, designs, specifications are provided to and understood by the team):
- 30% Styling and other UI refinements (Theme, Fonts, Icons)
- 25% Workflow (UX) Improvements (interactions, layout, and component’s structural changes)
- 20% Refactor to support new functionalities from UX and UI refinements
- 25% Product support (APIs, internal documentation, fixes, libraries update)
While the most visible improvements take around 30% of the time, and the functionality improvement takes around 25% of the time, the ripple effects (refactoring and support) are often almost as large as the enhancement itself (45%). This is why so often even seemingly minor changes can take large periods of time to get right – it isn’t just that you moved a button, it is everything else that has to be adjusted to allow that move to happen.
One major thing that can also slow down enhancements are UX changes. For example, consider tabular top navigation systems [1][2][3][4].
These always are very clear and easy to read. However, because words are written horizontally, after maybe 5 or 7 pages, you simply run out of space in your top navbar. So adding “one more link” to your navigation bar might require a larger refactor to make a hamburger menu or even switch to a completely different navigation paradigm.
And don’t forget, enhancements also go into “overtime” as well – adding in QA, bugs, and CI/CD. Depending on planning, that could include an extra 50 to 105% onto your enhancement/maintenance time-table.
New Features
In general, it is impossible to estimate a brand new feature’s development time. Every feature is different but consider them largely like doing an MVP again (at hopefully a smaller scale). You will need to Create UI, Provide scaffolding and Integrate APIs (and test, test, test).
to get this new feature to work. That is the minimum for a new page. You likely also have to touch many of your existing pages to link appropriately to this new content, if not deeper integrations. And while the feature in question can greatly augment this breakdown, usually the UI itself is 55% of the work – with 25% of the time spent on scaffolding and 20% on Integrating APIs. But the story does NOT end there…
Now consider something like internationalization, restyling/face-lift, or UI access control. These are features that literally will cause your team to refactor every existing page in your product (unless you planned way ahead when you first started – which is extremely rare since every project is under the gun to trim everything that was “unnecessary” to get the MVP out). As a result, all the things you built up front have to be refactored anywhere from 10-95%. This is why major features, new content that changes a product from Version X to Version X+1 take so long: so much time must be spent updating everything that already exists. And the longer your product has been around, the more time this new feature will take (consider it interest on your technical debt).
A new feature often will therefore result in at least 30% existing product refactor, with 38% on new UI, 17% on scaffolding, and 15% on APIs. And don’t forget the QA, Bugs, and CI/CI adding in that 50-105% present.
Automation for Front Ends
Let’s be clear – we could write (and TechRadar as well as our Chief Product Officer has written) entire blog posts about how automation can make this process better. That is not the intent of this section. However, we do want to quantity some of this impact given the context of this article.
Consider the MVP.
- Imagine if a solution could automate UI/UX design and build 70-90% of your UI, all the navigation and common workflows (configuration, monitoring, investigation, etc). You are then dropping your UI feature development from 55% to 6-16%.
- Imagine if a solution could automate your scaffolding – setting all your frameworks and infrastructure (minus anything truly custom you might need). This could take that 25% of your time down to 3%.
- Imagine if, for all the parts of your application that are automated, all the APIs needs for the front-end have to have full specifications remained consistent with the automated changes. Your UI team would no longer need to do any of the API integration for these automated elements. This would reduce your API integration time from 20% down to 2%.
As a result instead of spending 100% of the estimated time, you only need to spend maybe 11-21% of that original time to get your MVP out the door: a reduction of 79-89%. This is also a valid estimate for maintenance. Adding a new widget, a new action, a new CRUD operation could likewise take hours or days, instead of weeks or months.
This is the type of world Kleeen Software is making a reality. Taking larger amounts of the front-end stack off the plate of designers, engineers, and product managers. And with all this free time – your UI engineers and designers can focus much more (and perhaps all) of their time on creating something new and exciting. They could create sizzle, something innovative, something no other company has done before (instead of one more config screen, one more investigation, one more monitoring screen). Kleeen Software’s impact is measured not in hours, but in months.
The Takeaway
As trite as it may be, the iceberg metaphor applies to the product front end development process – there is barely even a need to change the vocabulary. The visible part is, in fact, the visible part of your UI; everything else is underwater. Not only do YOU not see the underwater part – (but if done correctly) neither do your customers. They don’t care about the underwater part, but in order for the visible part (the buttons, form fields and visualizations) to float effortlessly, that underwater part better be robust. (If you are interested in other things that are often hidden but take a lot of work – I love this podcast: 99% Invisible)
Looking at your next project, and the future of front-end automation Kleeen Software is providing – a new calculus must emerge. You can be spending lots of time working on completely necessary “UI development” and still have it look to your customer like you have nothing to show for it. Or, you can let Kleeen do all that and concentrate on noticeably improving the visible part.
Cover Image by Annie Spratt on Unsplash
