Always question best practices. Seriously.

Best practices to a designer are what a peanut butter and jelly sandwich is to a chef. It is a genuinely good sandwich. Everyone likes it, but it’s not memorable. Anybody can put peanut butter and jelly in between two slices of bread. However, understanding what makes the  juxtaposition of the sweet, tart jam and a rich, savory peanut butter so universally beloved is a fundamental principle that can be applied to countless creative and unique dishes.

Yes, it is important to understand the principles, but it is far more important to understand why the principles exist and their contribution to the end product. Best practices should be applied judiciously while evaluating each as it relates to the problems being solved and the users being served. Without critically considering best practices and their purpose, mediocre work can quickly become the norm, and with an ever-evolving tech landscape, that pb&j is eventually going to fall short of satisfactory. The goal of this blog is not to provide a “what” but a few universal “why’s” that hold true for all products.

Listen for problems. Provide solutions.

It is a trite truism to say that design’s core purpose is to solve problems. As a designer, your role extends far beyond taking a list of orders and putting them on the screen in a pretty way. Most product owners understand this at least intuitively and often come to project kickoff meetings armed with a laundry list of issues with usability, visuals, hierarchy, and workflow. That’s all great information. The issue arises when the problems are accompanied by an equally long list of solutions.

I would need to take off my shoes and socks to count the number of times I have seen designers who left meetings with dissatisfied clients and creative directors in frustration after “doing exactly what they asked for”. Believe it or not, clients often view their suggestions as conversation starters rather than the final decision. They brought in experts for a reason, and they want to see what you can bring to the table. Identify the problems that their solutions are addressing rather than taking their advice at face value. If the client says “make this button red and flashing,” the designer should hear, “this call to action needs to draw more attention,” and solve the problem accordingly.

This is not to say that there are not product owners who do want to provide a roadmap of specific solutions from day one, but it is important to communicate and evaluate their directives and ensure the partnership is meeting expectations through listening and learning from the client. It is equally important to set clear expectations early on that you are a partner in discovering solutions to the UX problems facing their users. The project kick-off meeting is just the first step of the journey.

Don’t make users read.

Whether designing a native app, web app, or website, every UX decision should essentially boil down to one question: “How do I get the user to the content they’re looking for while making them read as little as possible?” For better or worse, users have come to expect bite-sized chunks of content that they can find in an instant and consume without much thought. Next time you’re on an unfamiliar website, take a moment to appreciate just how frustrating it is when finding the information you’re looking for takes more than a couple of seconds. We expect to be quickly navigated by visual cues as if we’re riding a magic carpet, and it’s the job of UX to make sure that the wind blows it in the right direction. Incidentally, information architecture is an increasingly important task for a UX designer and is inextricably linked to content strategy.

Intuitive, succinct navigation structure, clear iconography, relevant calls to action, and pointed language with strong typographical hierarchy are all crucial here. Understanding pain points in existing user flows and identifying user personas, along with the unique requirements of each, plays an essential role in effective information architecture.

For instance, imagine you identify three distinct personas, each with his own goals. An obvious (and effective)  solution might be to make each of three top level navigation items relate to a persona. This gets the user directly into content that pertains to them without wading through extraneous options. Conversely, if there is a substantial amount of overlap between user types and their destinations, it may be more effective to eliminate a click by bringing those options to the top level of the navigation or to feature them prominently in calls to action.

‘Above the Fold’ is a special place.

Speaking of limiting the user’s need to read, it’s time to push hard against the antiquated, yet thoroughly ingrained idea of placing all essential content “above the fold.” Product owners often fear that users are reluctant to scroll. Consequently, all information not visible upon page load will go unnoticed. Both statements are categorically false. In fact, the more inundated users are with commands, images, and decisions at the outset, the less likely they are to recognize the content that matters most.

Negative space is a powerful tool in design. It’s easy to lose sight of that in the flowing, endless, linear grid that is your screen, but time and time again, we learn that users are far more prepared to scroll than previously expected. The explosion of touch-enabled devices only strengthens this tendency as users expect to experience content in a more tactile way. It is design’s job to anticipate the user’s goals and understand what’s important to the product owner. From there, it must present relevant content in a way that will limit the decisions users have to make to achieve them.

Learn to Code.

People who are skilled in both the realms of design and implementation have long been referred to as “unicorns”—mythical and magical creatures who might as well exist only in fairy tales. But, as the UI/UX world becomes a seemingly ubiquitous destination for aspiring designers, possessing at least a loose command of front-end development languages is becoming increasingly common. Just as responsive web development was a novel frontier a short time ago, understanding basic HTML and CSS will soon become table stakes when hiring a designer who will be working closely with development. And, there’s good reason for it.

Even if you never write a line of code in your professional career, understanding development and its restrictions has many benefits that only compound throughout the process. You will readily understand the value of designing on a consistent grid. You will have a firmer grasp about what fancy UI elements are going to give developers a headache and how they may be modified to make life easier while maintaining a similar impact. You will understand how to properly export image assets to facilitate development.

And, most importantly, your developers will respect and appreciate your efforts to understand their challenges, enabling you to engage in productive conversations about how to achieve a certain effect or to make compromises that save the design and the budget. It helps to make the relationship between design and development feel more like a collaborative effort and less like a game of tug o’ war. In fact, you probably have a lot more interest creating compelling interactive states and visual effects than most developers do, and your areas of coding expertise could prove to be a complementary skillset that actually helps your developers learn new ways to implement seemingly daunting UI patterns.

Let design dictate breakpoints.

Responsive design is all but a given in modern websites at this point, but it’s still a relatively new concept, and there is certainly room for improvement in how we typically approach it. Generally, we allow the resolutions of the most common devices to determine responsive breakpoints. In a time when catering to a 320px iPhone and a 768px iPad would account for the vast majority of smartphone and tablet traffic, this approach was a bit more manageable. However, smart phone sizes and screen resolutions have continually expanded, and the tablet has taken on just about every form imaginable. Moreover, there is no way to know what will be coming out next.

Instead, allow your design to dictate your breakpoints—not the devices. It is a far more future-proof and flexible approach to web design because it is the one way to ensure that your design will look great on all devices that exist today and those that will exist tomorrow. If your grid begins to break down at 943px, create a breakpoint there. If your navigation gets bumped to a second line at 528px, then maybe it should be supported at all resolutions greater than 528px, rather than needlessly compromising the UI on all devices between that resolution and an iPad’s. This philosophy allows design to focus on the layout rather than devices.

Work with users & observe them

The first casualty of a project on a budget is often the very center of this whole UI/UX thing—the user. The product owner will have his ideas about about where the pain points in a workflow exist, and the designer will have hers, but observing users and asking them questions about their experience with the product is where the rubber meets the road. User observation can uncover workarounds and pain points that would be difficult to identify without day-to-day experience within an application. The good news is that the investment here does not have to be huge. Feedback from as few as five regular users will typically bring the vast majority of the roadblocks in common workflows to light.

Prototype Early and Often

Sometimes a project’s budget is simply too small to justify it, and sometimes the scope of a project is too narrow, but any time information architecture enters the equation, prototyping is key. Early prototypes should be produced rapidly. As a rule of thumb, the lower the fidelity, the better. This is a wireframe step rather than a time to evaluate UI. This approach helps the users to focus on the flow of information and hierarchy rather than superficial appearance and keeps designers and users alike from holding a concept too dear because too much time was invested too early. It should be clear that these are disposable artifacts of a larger process and not an end in their own right.

Thanks to applications like InVision, the delta of going from sitemaps and wireframes to interactive prototypes is borderline trivial, and the payoff can be substantial. Interactive prototypes give clients and users far greater context as to how getting from point A to B will feel in a real-world use case and how intuitive the workflow actually is. For a product owner, prototypes “feel” real and can help get them more excited and better equipped to provide feedback on a particular feature. For users, prototypes provide a low-investment and authentic way to observe how they interact with and react to the information presented to them within an application. Through guided sessions, your team and product owners can see which prompts lead to hesitation or confusion.

Even if a user is able to look at a wireframe and logically understand how each button or interaction should behave, there is no better way to see where he expects to find certain features than to watch his immediate reactions to various prompts. It is important not to shield yourself from the feedback or hesitate to create a follow-up session at this stage. Revisions are easy to make and far less costly than they will be a month from now when the same issues will surely crop up again.

In summary, the key to implementing UI/UX best practices is not merely to know what they are and where to apply them but to have a full understanding of the reason they were dictated best practices in the first place. Thanks to an ever-evolving digital landscape these practices will evolve quickly to appease new technology, but their core values and reasoning will remain the same, which is to make the terrain as passable and enjoyable for the user as possible.