In the ever-evolving world of development, it’s easy for things to get lost along the way to launch. What was once a fairly straightforward process undertaken by one or two developers has grown into a massive undertaking usually encompassing multiple teams and layers of input, each with their own agendas and concerns. This is not all bad nor unexpected, as company websites are asked to do more and more each year, but it does complicate matters quite a bit.
Complications do not have to be negative, however. Robust, well-designed, highly functional websites should be complex amalgamations that offer real, tangible value to their end users while appearing simple and easy to use. Thus is the developer’s dilemma: hide the effort, at all costs.
This is why intentionality matters at the outset of any new development project. Talented project leaders can help ensure the many moving pieces of the puzzle find a way to fit together in the end, but even highly motivated and competent leads can lose the forest for the trees.
Overwhelmingly, the beginning of any new development project or revamping of an existing project is typically boiled down to two questions:
- “What will it look like?”
- “What will it do?”
Valuable questions indeed, but it is precisely this narrow scope from the outset that leads to trouble down the line. Let’s examine the three elements I see most often get left by the roadside in service to answering those two questions.
1. User Experience
At this point, most everyone is beginning to realize how truly important user experience (UX) is. The term itself has sparked a paradigm shift in modern web development and the web is better for it. Despite an overall consensus on importance, however, many project leads and developers struggle to adequately define UX, an entirely understandable problem when you consider the scope and breadth “user experience” entails.
That creates many opportunities for things to go wrong. An overly granular approach to UX can be as damaging as indifference to it. Each piece of a website or web app has an intrinsic experience unto itself, but each of those must be viewed as part of a whole ensemble of other experiences that ultimately create the experience for the end user. No one will remember the perfectly crafted micro-interaction of a button click on a form that loses everything I’ve typed into it if my connection goes down or if I accidentally refresh the page. All I’ll remember is having to fill out that form again, if I can be bothered to stick around at all.
That’s why it’s important to undergo periodic audits of a project’s experience, particularly at times when individual pieces or modules are completed. Taking some time to evaluate how subsystems work together, and how those systems come together to create a user flow and experience throughout the entire product can give a team the 30,000-foot view needed to correct issues with UX before they turn into the kinds of problems that permanently turn users away.
By maintainability, I mean how easy it is to continue to maintain a product or website’s codebase after it’s been launched, once real user data comes in and bugs that were missed in testing begin to reveal themselves. In the rush to “just ship it,” we coders always end up having to make some sacrifices. Perhaps it’s forgetting to delete 120 lines of old commented-out code or forgetting console.log()’s spit out data. Hoping the average user will never see, we promise ourselves we’ll fix it later, once we’re launched and everything’s stable and we have more time.
Technical debt can be an absolute monster if left unchecked, and it rears its ugly head every time we find ourselves having to maintain or make changes to the codebase. Seemingly simple tasks can become maddening when having to navigate the cracks and fissures of overly rushed code. All too often technically functional code that makes it into production is so fragile, attempts to change it create cascading problems across the project.
Project leaders and developers need to create their products with ongoing maintenance in mind. No matter how thoroughly tested, real users will interact with your sites and apps in ways you never expected or intended, creating issues you never imagined. Being able to easily maintain and update your code allows you to respond to those unforeseen problems quickly. It’s easy to get consumed by adding functionality or sprinting toward that always looming deadline, but neglecting maintainability at the outset will cripple a codebase down the line.
Extensibility is often lumped in with maintainability, but really deserves its own place on the priority list. While it’s true that well-maintained code is easier to extend, extensibility should be seen as far more than just being able to add new features. The ways your site or app will (or can) grow over time are defined far more by infrastructure and tech stack choices made early, than by any particular block of code.
Therefore, one of the most important choices a team can make regarding extensibility is around the tech stack and libraries it chooses to use. Those of us who’ve been in the industry for a while remember the Ruby on Rails craze, and the subsequent inability for many of the sites and apps that used it to scale effectively, simply because Ruby was never designed for that in the first place. At the time it was a strong language with tons of built-in library support intended to create a minimal viable product quickly. This isn’t a knock on Ruby; it was a nascent technology at the time and has since matured, but there’s a lesson to be learned there about keeping extensibility in the conversation at each step of the development process.
Teams should take time to weigh the benefits of new tech against their potential role in extending the product down the line. Take chances where you can safely, but make sure mission-critical pieces of the tech stack are mature enough to grow with you.
Look at the Big Picture
The growth and maturation of development teams have resulted in amazing innovations in both the tech and design side of web development. Bringing together more minds and skill sets ultimately results in better and more complete products for your users. But it also makes it easier for pieces to fall through the cracks.
If there’s one thing to remember, it’s that major problems can be avoided by simply building in time to step back and view the big picture. Overlooking UX, maintainability and extensibility might seem minor when you’re racing to launch, but giving them the proper attention will make the difference in the long run, helping you avoid the headaches and costs of frustrated and lost users.