UX Enhancements to Existing Products
Recently, I rolled off a client project where we implemented an e-commerce platform with lots of customization to meet client needs. This brought to light the delicate balance between using the platform’s existing features and customizing the user experience to more effectively accommodate your users. You want to think that every out-of-the-box solution is going to provide an optimal user experience, but we all know that’s just not the case. Every project needs tweaking.
Updating the Existing Front-End
There are some solutions and platforms that you can tell were built by developers with good coding skills but the UX is not ideal; that’s not their baileywick. The clues are in the existing CSS files. Maybe they are using points to define
font-size for an online experience and setting your
background-color property as “
lightyellow" in your default CSS file; yup, you need some degree of damage control when you see this.
It would be nice to rewrite the entire stylesheet, but time and/or resource constraints will probably make that impossible. After all, the reason for using third-party technology is so you don’t need to spend time and resources building something from scratch, isn’t it?
I would recommend that you make as many quick changes as possible across the board, right off the bat. A simple “Find and Replace All” changing
mediumspringgreen to their appropriate hex values is a good start. From there, make similar changes to a handful of equally glaring issues that seem to be common throughout the file. These changes don’t take a lot of time, and allow you to become familiar with the base styles for future use. Do a quick “find” function to step through each instance and make sure the keywords don’t appear in any existing selector or attribute names, lest you find yourself wondering how your
.featured class suddenly broke the page and became
Another challenge is changing layouts of page templates that are used throughout the site, such as “Category” or “Product Detail” pages. This is where that initial review of the CSS file comes in handy. You should have some kind of idea as to how certain classes or elements are styled, or at least know where in the CSS file they can be found. From there, you can create new classes that suit your needs, if they can’t be met by existing styles. If you find yourself editing site-wide styles, don’t forget to test those styles across the whole site, and not just the page you’re working on. The same advice for updating images tied to a style.
Start Big, Finish Small
My strategy on this last project was to try and pinpoint site-wide issues from the start, and fix as many of those as time and resources allowed. Those I couldn’t fix I would note for future reference, or notify the client that there were potential issues that could come up down the road; don’t waste a lot of time arguing internally about the “best” solution: let the client make the decision about whether they want to have you spend time revamping it.
These issues don’t necessarily have to be related to how markup or styling are presented, but to the general flow and spatial relationships of elements within the design of the site. After this initial assessment, the general rule of thumb I came to live by was, if I saw a problem that could be quickly fixed, I’d fix it. For example, once I came across larger problems that I didn’t see in the first go-around, I had to pick my battles, but the strategy remained the same: make the client aware of the issue and its potential negative effects, and let them decide if they want to spend the time and resources fixing it. While some clients will heed your advice and warnings, others may not see the value in making any changes; that’s their prerogative. At the the end of the day all we can do as UX practitioners is to keep them informed, and document those decisions in email or other artifacts.
Adding New Custom Features
Once you start going down the avenue of adding features and extending the platform with customizations, a development team needs to make UX considerations such as:
- How is this new feature going to be implemented?
- Where on the page, or in the system will it live?
- How does it affect the information architecture, if at all?
- Is that really going to fit in there?
- Does it need to be a full page, or should it be a sidebar module or a lightbox?
These are only a few of the questions that need to be answered before you can take off your “UX Practitioner” hat and move forward with development.
Front-End Development Considerations
Once development begins, there are front-end considerations:
- What styles will it inherit?
- Do we need to develop something custom to do that? Or does something already exist as a plug-in or extension?
- How can we leverage existing code we wrote to implement this feature so we don’t have to start from scratch?
There may be some great solutions that developers will offer up, but which don’t fit in well with the site. This is where you need to be careful. They may work functionally, but they could also produce sloppy markup and a visual design that does not dovetail smoothly with the existing UX or workflow, thus impacting the user experience in a negative way. That’s why having UX involved from the beginning of the process of adding these features is so important.
Not Reinventing The Wheel
When it comes to adding these features, each one is a unique adventure. The trick lies in what’s come to be a theme here, for both new and existing features: The goal is always to balance client needs and existing platform structures with good UX and front-end development best practices. There are going to be a lot of compromises, and some of them are going to hurt, but that doesn’t mean you didn’t do your job. In fact, it means that you did it well.