Normally, the main considerations for good UX are pretty straightforward – is the site intuitive and easy to use? Does it look good? Is it easy to navigate? These things are important, of course. But there are many other facets to application design that if neglected, can signal project challenges or even failure. Here are a few things that designers need to keep in mind that are not normally considered to be part of the UX design process, but are best handled during the design phase of a project.

It’s difficult to design an interface if you are unclear about the underlying data structure of a system. In a way, UX design is all about creating windows into the data of a system, and if a system is being created from scratch or if new features are being added to a system, the structure of that data may not yet exist. So it is not the development team’s job to create data structure, that structure must be DESIGNED. The data structure has an enormous impact on the usability of a system. For me, one of the first things I will design is a simplified table structure – it can inform all the rest of the design process. It can also raise very important questions for stakeholders and users before any storyboarding or wireframing commences.

For example, consider a call center design. If people might call multiple times about a single issue, and if reports will be done on call count per issue, then you have to have an issues table and a separate calls child table for the calls to be associated with an issue. And the UX you build must solve the problem of making that relationship easy to manage. If you don’t have the data structure in mind then you won’t even think to solve that problem as you design the UX. It isn’t that you are talking to end users about database tables. Rather, thinking in terms of data structure causes you to probe for the right things to make the system work well.

Many times I will include a simplified ER diagram as part of the design documents. You’d be surprised how much end user and stakeholder dialog centers around this document, and how much empathy it can generate with them. You might think that people cannot think so abstractly about a system, but it is not actually so abstract. When a system concerns people and their work, these kinds of documents make a lot of sense.

There is nothing worse than fielding the possibility of selling a system to a big government client, when you get hit with an accessibility survey on your system that you can’t pass. Goodbye piles and piles of money! This has never happened to me, right?!

Yes, it is a chore to design for accessibility – unless you are blind or deaf or otherwise in need of those design concerns! It is the DESIGNER who should be most concerned with accessibility, and if you do the work with this in mind from the very beginning, you can avoid so many problems in the end. Accessibility generally cannot be easily tacked on at the end of a design project, because the problems you create for your design are often deeply baked in to your initial approach. It is enormously helpful to be very familiar with good accessibility practices before you even begin to approach your design.

Accessible design can really grease the gears to expand the use of your site or application, and let’s face it, it’s the right thing to do. It should be a prime consideration from the very beginning of a project for ethical as well as financial reasons. Read through and familiarize yourself with the w3’s accessibility guidelines here: https://www.w3.org/TR/WCAG20/%23text-equiv-all. It really is an important part of our craft as UX designers.

Responsiveness across various screen sizes and resolutions is another design consideration that can often seem to be a chore. We tend to design either completely towards a mobile screen size, or towards a desktop screen size, but we should really be thinking about responsiveness for all appropriate screen sizes all through our design process. If you have a design plan or design style sheet ahead of time, you can create responsive screens where the transition between screen sizes is very cohesive and it can reduce the work of designing towards responsiveness. This is one more thing that is more difficult to tack on after the fact instead of designing with it in mind from the very beginning.

Site performance is such an important factor in determining usability! It is a terrible mistake to relegate performance concerns to the purview of the development team alone. It is a tired trope among developers that they have pretty but unworkable photoshop or sketch files thrown at them by clueless designers – things like infinite scrolling with complex filtering on data sets likely to number in the 10’s of thousands or even millions. Such designs present severe problems for developers in terms of performance, and the problem is really one of conception and not implementation. The designer must be aware of potential performance traps, and design the experience in such a way that the user is guided to screens that will have enhanced and snappy performance. This is every bit as much the responsibility of the UX designer as it is of software engineer. Design which ignores performance concerns can severely impact the usability and delight of the user’s experience.

There is also an intersect with this in terms of knowing where to focus your attention. If a screen you’re designing is going to be used by thousands or hundreds of thousands or millions of people, you want to be very careful to deliver extremely performant design on those screens. You’ll want to work closely with the developers to make sure what you’re designing will be able to deliver that performance. But if it is some kind of back-end administration screen that a handful of high-level people will use infrequently, it may not be worth the effort to be so careful as long as it is performant enough to get the job done. You have to use some wisdom and experience to know where to focus your efforts in this regard.

It is so utterly crucial to understand the context and workflow of the person you are designing a screen for. This can definitely mean you need to have an idea of the person who will use the screen. But in addition, many UX level deficiencies in a design arise because great attention was given to the requirements of a site visitor, but no one thought about how the data generated by a site visitor would ultimately be viewed and consumed and responded to in the back office. If the needs of all system users are not attended to, ultimately the customer’s experience for the system will be a failure.

It is important to try to understand and keep in mind that a whole group of users are going to be interacting together in the use of the system you are designing. Problems along these lines aren’t necessarily UX design deficiencies, they are requirements analysis deficiencies. If you don’t account for all the users of a system and design the solution wholistically by accounting for the UX of all of the users, your design is flawed. I liken this problem to having excellent cabinetry in a house where you forgot to include a bathroom. It isn’t enough for individual screens to be intuitive and usable. The flow of information between the different kinds of system users must make intuitive sense at a structural level, or else the UX fails.

Security concerns are the unwanted pesky little brother at the UX party. No one thinks security is sexy. Often people think that security is a mysterious black box that only developers and IT sysadmins need worry about. In fact a great deal of the concern for security falls on the shoulders of the system designer. The developers may do an excellent job of guarding against code injection in forms, but if the UX designer doesn’t think about security as well in the way the system works, it will still be insecure.

I inherited work on a system once where site visitors could change their email subscription choices by simply typing in their email address, and then immediately change their settings. It didn’t occur to whatever genius created this that anyone could come from anywhere and change anyone’s settings that they wanted. No code injection needed! It wasn’t even a bug – it was DESIGNED that way. This is an extreme example, but it is clear that security needs to be baked into the requirements and design of a system from the very beginning.

It may be that the reporting needs of the system you are designing are not directly in your wheelhouse, but if anyone is going to export data into a spreadsheet and look at the data, you have reporting. If you are planning to create a dashboard in a later project with a tool such as Tableaux or one of its competitors, it is important up front to design the data structure and the UI to collect the kind of data that will be useful when you create these kinds of reports.

As an example, suppose you are creating an issue tracker. You may be tempted have a status per issue, so you can track which issues are in which status. But perhaps later someone is going to ask how long issues linger in each status. How will you produce such a report if you don’t collect a history of the status changes? So the design of the system will have to include a child table for the issues where the status changes are recorded with a timestamp. Even though this isn’t directly a part of the UX at first, the DESIGN needs to look forward and collect this data so it can be reported on later.

Putting this all together as you are designing can seem a bit daunting. I think it becomes easier with experience, but it is after all our job as designers to be aware of these things and to get them right. It will of course never be perfect and UX design needs to be just as adaptive and iterative as any part of the process of creating a system. It helps to know generally what you’re trying to achieve, and there is more to this than simple intuitiveness. The more you design holistically, with data structure, accessibility, responsiveness, performance, security, and reporting in mind, the more successful your designs are going to be.