4 Roadblocks UX Designers Will Encounter
How to survive as a designer in a non-design-driven company
User experience design already has countless definitions, but for the sake of this article, why not add mine to the pile: It’s a multidisciplinary process by which an experience is crafted for a specific user or group. The component of that process that is (understandably) most recognized is visual design. It’s the shiny layer on top of everything else that tends to leave the biggest impression on people.
For many organizations, this misunderstanding is not much of an issue. Design-driven organizations have this multidisciplinary process sewn into their fabric. However, for many organizations, particularly those founded on engineering principles, misalignment between design and development can run rampant. For young designers with little exposure to how design should look within a software development context, these can be confusing waters to navigate.
Let’s take a look at some of the ways this can manifest itself, and some ideas to help overcome it.
1. Design as a matter of personal preference
When there is a design to be evaluated, everyone will have an opinion, strongly rooted in their own preferences. A designer’s preferences ought to be well-aligned with research findings and industry best practices. A developer’s preferences may simply be whatever is easiest for them to develop. A project manager’s preference will likely be similar to the developer’s. A CEO may wander into the meeting and tell you the interface should look like their favorite banking app. These competing interests can lead to every designer’s worst nightmare: design by committee. Assuming the metric for success is usability, whose preferences should matter the most here?
The answer, of course is the user’s.
And in second place? The designer’s.
Assuming that the designer is the most well-versed in industry best practices and user needs, their opinion should always carry the most weight. Especially since they are there to advocate for the human beings who will be actually be using the product.
However, most organizations will not allow their designers this kind of unquestioned autonomy, nor should they. Designers need to be able to back up their reasoning. This is where the false notion of design as a purely visual or artistic discipline can become dangerous in organizations that are not design-driven. While the developer and project manager have hard numbers to back up development velocity and budget, the unprepared designer may find themselves unable to properly defend ideas or prove the value of their proposals. If design is seen simply as a matter of taste, defending your work is going to be an uphill battle.
Remember this: Design can be scientific: You can back up nearly every element of your design with facts and figures. In theory, for any given UX problem, only one design solution exists that is objectively and measurably better than all of the others. The goal is to find it. Realistically, we’ll never have enough time or money to personally design and validate every possible option, but there are a lot of resources at our disposal to help us get most of the way there.
Take color schemes, for example. There is a wealth of research on the meaning and perception of specific colors, which can be relied upon to settle arguments about, for example, which shade of yellow your warning icon should be.
Be sure to follow the work of industry thought-leaders as well. Websites such as Nielsen-Norman Group are invaluable sources of information for reinforcing your design decisions with hard evidence, and deepening your understanding of design principles.
As far as best practices are concerned, companies such as Google and Apple have invested heavily in usability research, and their UI standards are excellent resources for creating your own guidelines. The majority of users are familiar with these design paradigms, which is a sound reason to adhere to them. Referencing the work of these design-driven companies can be a very effective way of getting buy-in from project stakeholders.
Finally, user testing and usability studies should be conducted early and often. Frequently in engineering-driven organizations, this step is skipped entirely and not budgeted for, but there are other ways to gather insights from users, which I will discuss later.
2. No design standards
In many engineering-driven organizations, a designer may find themselves to be the first or only designer. In these situations, a software product may already exist, having been developed without a coherent design strategy or vision. Going forward, it will be crucial to put in place an agreed-upon yet always-evolving set of standards that serve to prevent rogue developers from doing it their own way, and higher-ups from insisting on bad design practices.
Once implemented, design standards are the quickest way to settle arguments about interaction design, patterns, and layouts. They provide teams with a common language and a framework to work within. While a designer will lead the development and evolution of design standards, it is important to have commitment from both product management and development in order to use them effectively. People can only be held accountable to things they have agreed to.
Fortunately for designers, reinventing the wheel is unnecessary. As previously mentioned, there is a wealth of publicly available design guidelines from which to borrow, and most of the principles found in Apple or Google’s style guidelines have universal applicability. However, adapting them for one’s own software product will involve specific considerations for color, branding, platform, and of course, specific user needs.
Getting buy-in on a style guide for future development is the easier part of this process. The difficult part will be convincing product ownership to apply new standards to old pages and functions. I’ve experienced working on software with four different generations of pages, all with their own unique style. These pages would take dramatic rework from a web developer, just to retrofit them with new components. Unfortunately, organizations will often be reluctant to prioritize that work over the development of new features.
In a pinch, this does not have to be an all-or-nothing approach. For example, if a developer is going to be making changes to one page, they may also be able to squeeze in some restyling of buttons. That said, this is not the ideal approach, and enacting change may be difficult at certain levels of command. In my experience, the impetus for radical change and alignment to a style guide has come from the executive level. Paying down UX debt is never the sexiest use of resources, but it’s important for the long-term success of your software product.
3. Poorly articulated requirements
There have been times when I was given a specification that read less like a set of functional requirements and more like the UX notes I would attach to my finished screen designs. The issue here is requirements articulated as solutions. As a newbie designer, I sometimes followed the “requirements” to the letter, until I realized that my colleagues were often requesting designs that violated best practices, and essentially trying to do half of my job for me. This commonly occurs when proper analysis is skipped over, and the person in charge of writing a functional specification jumps immediately from a 50,000-foot-view to a solution.
There simply is no good shortcut around a user story. Here’s how an overly prescriptive requirement could have been better articulated:
My colleague writes: There will be a button that turns the auto-refresh feature on and off.
What they really mean: As a [type of user], I want the ability to disable the auto-refresh feature when necessary to maintain the current state.
The real intent of this solution is to allow the users to disable the auto-refresh feature, not to allow them to press a button. As a designer, I know that a toggle is probably the proper component for this feature, not a button. The user story provides me with the context, background, and requirements necessary to design the appropriate experience.
Writing and verifying stories with project stakeholders is a key step that often gets missed in organizations that are not design-driven. Consequently, jumping straight from requirements to solutions without the proper analysis can often lead to user experiences that do not properly meet users’ needs.
As a designer in such an organization, it may fall on your shoulders to ensure that the proper analysis takes place. If you are unclear about requirements, contexts, and intents, do not hesitate to call a meeting with key stakeholders to turn these requirements into user stories. The time spent up-front could save headaches later on.
4. Little to no access to users
Perhaps most frustrating of all is when designers lack access to users and, consequently, firsthand insight into how a software solution will be used. Often, this process is not built into the product life cycle, and user experience designers only receive secondhand insights. It is likely that product managers are speaking to the customers, but not the actual end-users.
When user-testing and usability studies are not budgeted or afforded for, UX designers will have to be especially proactive about finding ways to fill this gap. Here are some ideas:
Tag along on a site visit
This may mean reaching out to someone outside of the product team, such as a support specialist, a salesperson, or even a customer. While user-testing may not be factored into the site visit, you may have opportunities to observe and interact with actual users. Be sure to take notes, and preferably video recordings, for later review.
Consult your technical support team
These colleagues will have insights into day-to-day issues that users are experiencing. They may even be able to provide you with data, such as performance metrics or clickstreams. Lead software architects or account managers may also have access to customer systems.
Do some QA testing
It should go without saying that strong domain knowledge is crucial to success in your role. Testing software for bugs and errors will (partially) put you in the shoes of users and improve your understanding of the product, including its pain points.
Guerrilla testing
Guerrilla testing can always be performed as long as you have people around who have not participated in the design process. Depending on the complexity of your domain, it may be wisest to test on those who have some understanding of the software already.
It is my sincere hope that you will not encounter these difficulties as you make your way into the world of UX design. Sadly, the tech world has a long way to go in its embrace of design, and many companies are lagging far behind. Fortunately, many of these issues are well-documented and there is a path forward to organizational design maturity.
With experience, design evangelism, and a whole lot of patience, you can be an agent of change within your organization. No one wants to deliver bad products, but sometimes change is hard. Little by little, designers can help to lead an organization out of the darkness and toward delivering products their users will love.
