Busting the myths about UX

Now that we have a decent understanding of what UX is, it is equally important to understand what it isn’t. UX isn’t the pixels on the page. It isn’t the code underneath or the decisions that a product team must make about how to provide the proper data to the people who need it. Yes, those decisions support the UX, but they aren’t in the realm of the UX practitioner.

The UI isn’t the UX either. While it supports the overall experience that a user has with your application, it relies on all the work done by the UX team. Wireframes are produced from research and design thinking sessions, and then tested with users to see whether the direction is correct. When there’s a greenlight to move into the development cycle, the UI designers move into action and ask questions such as the following:

• Which design system are we using for this?
• What’s the best card to use for this element?
• Is this font the right one?
• Can I place the button as specified? Can it be moved 20 pixels to the left and be approved?

Right? These people need to take what’s given from the handoff and start creating the user interface that will drive the application. They’re essentially working from a blueprint to build a house, car, or office building. They’re asking questions when a design challenge occurs and working with a UXer to ensure that the usability, usefulness, accessibility, and so on are still according to the plan – the plan, as we now know, that’s been formed from the research, design thinking, and iterations through the beginning stages of the project.

So, now let’s circle back – these things aren’t UX. UX sets the stage, but this is UI.

The bottom line and key takeaway from this section is that UI is tactics. It’s the how.