UX / UI For Existing Business Software

With businesses having to spend less time on finding and building out necessary complex backend systems, there has been a recent shift in focus to making those systems more ‘design’ centric. ERPs, CRMs, Customer Portals, Learning Management Systems and a myriad of other business-related software are in need of a facelift. These once ‘scrapped’ together and ugly user interfaces that lack visual logic are now technically capable of being dressed up and made to be ‘beautiful’.

The reason it’s becoming so popular? Because businesses are finding financial benefit in better being able to drive their vendors, partners, customers, and even internal staff to a more ‘intuitive’ and intentional system.

This is what is most commonly termed as UX / UI. Short for User Experience and User Interface; it defines the process of basing your digital designs (user interface) off of strategic user flow plans to help guide them through your site or system to get them to where they most need to go (user experience). Technically it means taking designs, coding them into HTML, CSS and Javascript components and integrating them into the existing backend technology you have running your site, system, software or platform.

However, we find a lot of businesses new to the world of external markup and styling integration and not quite sure where exactly to start. Like anything that is becoming trendy or buzzword-worthy, there are a lot of misconceptions about how to approach such projects.

Having worked with a couple dozen different backend systems and technologies to integrate in new custom digital designs, we have come across some key areas to focus on while departing on an integration project as such. In most cases integrating a successful UI design is less about technically being able to code it out and almost exclusively about the team collaboration and execution plan put together for the project. Below we help to highlight a couple of the most critical components of preparing for a UX / UI project.

1) Existing Code Structure

Questions to Ask Yourself:
Is your code repo ready to be shared with another technical team? How will you handle new commits to the codebase? What rules or controls will be in place for team members pushing? Do you have a technical write-up or visual architecture of what your codebase looks like?

What it Translates To:
Having an existing codebase and aiming to integrate a new UX / UI requires that you and your technical team carefully consider how you are going to go about accepting updates into your system. The HTML, CSS and Javascript will have to overwrite or fit into your existing system, and that means being aware of potential pitfalls. Too many times we have worked with clients that fail to consider all the nuances of their codebase and unintentionally ‘break’ it with a hasty commit. Have a rollback plan in place to account for such unwelcome tragedies.

2) Team Dynamic

Questions to Ask Yourself:
Has your team ever worked with an external development team before? What is the hierarchy and skill level of each of the developers on your technical team? What are your biggest pain points when it comes to wanting to be communicated to? How will each member of your internal team interact with an external team?

What it Translates To:
The most critical aspect of any UX / UI integration is communication and getting technical teams introduced and communicating early and often. It’s an area of focus that is ‘glazed’ over a lot as people tend to just like to focus on the technical capabilities of teams. But let’s be honest; knowing how to code out basic HTML, CSS and Javascript is relatively easy with an experienced developer. It’s understanding how that developer relates to your technical expertise that must be measured up and addressed. We often times run into working with client teams that are not as senior in development experience as our agency teams…and that is perfectly OK. Understanding the true technical capabilities of your internal team members is crucial to us pairing solutions and meetings that elevate all of the work being performed. You want to make sure to find a blameless external team that doesn’t point fingers if your ‘developers aren’t up to speed’ or complain about deficiencies. The true expertise comes in making a project successful no matter the number of people or technical capabilities. Developers unite!

3) Technical Limitations

Questions to Ask Yourself:
Does your codebase rely on certain versions of technologies or existing libraries? Do you utilize any frontend or other frameworks that must be considered before building out the markup? Is accessibility a critical factor for launching pages?

What it Translates To:
One of the most abstract areas of focus when initially trying to scope out a UX / UI project, it’s being able to easily communicate any technical libraries or guidelines that other developers must follow when implementing new frontend designs. How do you find out? Well, it relies heavily on your internal technical team. They should be aware of Javascript libraries, frameworks or other components that are being used within the system to streamline tasks already being done. If your internal team is not familiar, make sure you have an external team audit and account for these prior to starting. DO NOT start implementing frontend designs without knowing these things first. It will just lead to broken UI experiences for customers.

Sometimes there are some gray areas and it is OK to mark them as so, just as long as when code starts being deployed you are quality assuring those areas before moving to production. Long story short on ‘Technical Limitations’ is that with an existing system you can rarely just ‘start coding’ and you have some rules to follow when it comes to coding for what is already there.

4) Release Plan

Questions to Ask Yourself:
Do you want to release all the new designs at once? Or do you want to release pages as they become developed?

What it Translates To:
Understanding the options for releasing your new UX / UI development and contemplating the pros and cons internally. There are typically two ways of ‘releasing’: Batch or All at Once. Batch typically breaks down deployment of live pages to segments or even single pages or sections on pages. This follows a more agile-type process and requires a dedication to a strong process whereby developers and project managers are closely linked at all times. Depending on project type batching almost always takes longer across all deployments but it helps get single elements out faster and / or creates a gradual shift in UI so as not to shock the customer with radically new looks. All at once of course focuses on all pages / views to be deployed and launches them simultaneously. Which one is right? Based on project goals, existing teams and budget will drive the optimal choice.

5) QA / Bug Tracking Process

Questions to Ask Yourself:
How are you going to handle commits from external developers on the project? How about internal developer alterations? How do you handle code / merge conflicts? Who is part of the quality assurance team and what steps need to be followed? Is there a contingency plan in the case of major bugs or rogue pushes?

What it Translates To:
Quality assurance is the process of assembling a team and set process to follow so that while new implementations are being initially developed, they can be thoroughly reviewed and be pushed live with little concern that there will be any issues to the overall system. This requires dedicating individuals on both sides of the relationship and establishing a set process in terms of steps for how new frontend elements are submitted. QA is one of the biggest buzzwords when it comes to UX / UI (and development within existing systems) because this is the area that focuses on making sure new and exciting features or designs don’t completely break the existing system. It is the last line of defense between a successful, seamless launch and a stress-filled, chaotic launch. Remember though, quality assurance only works if everyone understands the process and uses it.

Conclusion

Overall the ability to apply improved user designs on existing platforms, softwares and systems will continue to increase in volume. Understanding that it’s not just ‘code’ that needs to be accounted for is critical in making sure that the project risk is minimized. Have specific questions on how to implement new frontend elements into your project? As always, we love to help provide insight. Give us a ring.