UI/UX Design Before Development is Important

UI (User Interface) and UX (User Experience) are important steps that need to be thought of first, before building software/ web applications or adding new features. I’ve touched on this topic before in my Lonestar PHP 2016 conference recap about the You Can UX Too: Avoiding the Programmer’s User Interface session by Eryn O’Neil.

This post will cover some of the issues that arise when you don’t take the time to design a UI before developing your product.

Developers can have a habit of jumping into projects once they’ve received requirements, without waiting on or demanding a UI design. A Developer Interface happens when the developer is designing the interface as they build the software. Typically, the original interface will meet the original requirements, but it probably doesn’t have a lot of thought into the layout or user flow. Over time, additional features will be requested and added, again without thinking of the UI or UX, so features will just be tacked onto the existing interface. It’s definitely not pretty, and worst case it looks something like this:

Image source: http://www.infovark.com/2007/12/11/you-sank-my-battleship/

If you don’t put any thought into how the application should function and how it will be used, you’re going to build an application that doesn’t work well. You spend hours and hours developing this application, but if your users can’t navigate around easily they’re not going to use. So, what was the point of building it?

A design first allows your user to confirm it includes the correct functionality and it has the workflow they were expecting. This doesn’t mean that your users dictate how any of the backend code works, but it probably will impact how you build the functionality.

When users submit requirements, whether it is adding new functionality to a new application or building a new product/web app completely, they’re generally not great. When talking about a users requirements, there is usually at least a few things that will change. When they’re presented with the UI Design, there are usually more requirements or feature changes.

By presenting them a wireframe/design before you begin building it gives you both an option to review the functionality and easily make changes or updates to the design before it is built. These functionality changes could have meant a lot of rework/refactoring of your code in the future, however, because of the UI, you have avoided a lot of this work. It also makes sure you’re on the same page with the stakeholders and that they’re confident they’re going to get what they expect.

As with any project, the longer the project goes on the more changes will cost. With a UI Design before you start building, you give the Stakeholder an opportunity to see how the final product will look and function so they can make any changes then.

This also makes sure the way you have interpreted the requirements match the way the requirements they have.

Image source: https://4squareviews.com/2013/01/30/5th-edition-pmbok-guide-chapter-2-project-life-cycle-general-characteristics-of-phases/

—

Of course, if you’re the developer on a project you probably won’t be creating the UI design. During projects, depending on the size of the project and team, there is typically a stakeholder requesting changes, a product or project manager taking care of the various requirements and steps, and a developer doing the work. It’s easy in this telephone game to miscommunicate or interpret the requirements incorrectly. Adding in UI/UX Design before jumping into development helps to ensure everything in the project works as expected, is easy to use, and reduces the risk of changes down the road. So, next time you’re building an application or adding in additional functionality, get the UI Design first!

It’s important to remember that, while UI design first is important, you should continuously revisit and improve the UI over time too, just like you would refactor code over time and as new features are added.