By Chris LaCava, VP of User Experience
In software, there are natural tensions between engineering, business and user experience. If equilibrium is not maintained between these opposing forces, the unbalanced results are often baked into the software itself.
Engineers are usually tasked with developing a scalable, maintain-able solution within a given timeframe. Business stakeholders are responsible for bringing things to market that will sell successfully. A user experience team’s purpose is to design the most efficient, easy-to-use and pleasant experience possible for the user. Working in concert, with the right mix and attunement, the motives of these three camps create great products. When they are out of alignment, they often produce some of the worst.
The first step in gaining equilibrium is elevating the three constituencies to equals so natural tensions can serve as a mechanism for checks and balances. UX design has historically been tucked underneath engineering, or some other part of the organization. It is important to realize that while everyone has a role in product design, the more unencumbered by competing motivations a user advocate is, the easier it is to maintain equilibrium,.
This is why I passionately argue for user experience as a separate and equal constituency when assembling a software development team. Keeping UX balanced with other constituents will definitely increase your chances of creating a successful product. Inversely, imbalance will have a negative effect, so achieving and maintaining balance is important to the success of the product. Here are three common indicators of imbalance throughout the product creation cycle, as well as strategies to rebalance:
1. Losing sight of the end-user. As negotiations and debates run their course through normal software production cycles, the original intent of functionality can get distorted. Compromise is a necessary part of the process, but staying true to the end-user’s motivations is ultimately going to be a differentiator by making a more easily-adoptable application. Attention to the unique nuances in workflow of your target user-community is one of the key factors in user adoption. Those nuances are also most apt to being overlooked because they are often subtle, esoteric or foreign to anyone outside that particular community.
Restoring balance: The first step is understanding the end-user to begin with. Identifying your target audience in as much detail as possible is the first step to developing successful software. This is usually going to be a conglomeration of users with different goals and motivations. Understanding the relationship between user types, as well as their individual goals, is extremely important.
Next, understand the nature of their work in as much detail as you can. This includes tasks that could fall outside of the solution that you are developing for them. There are many ways to do this but the most effective is to simply watch your users work. Arranging to shadow a few target users doing their work (often referred to as contextual inquiry) is an excellent way to learn their colloquialisms, patterns and frustrations. If it is not possible to shadow people, reaching out to communities of users throughout the lifecycle of the product will still give you valuable context. If you can capture this information and distill it into a software tool, you are much more apt to stay focused on the end user when it’s time to make difficult decisions about your application.
Once you’ve amassed a rich understanding of your target user base, review it often. Collecting user feedback and reviewing the data are often reserved for UX professionals, but everyone on your team can benefit from ongoing end-user feedback. This can be as simple as framing your and your colleagues’ mindset by repeating the simple mantra of UX – “I am not the user.”
2. Putting form over function. There is a lot of very slick looking software out there. Good aesthetic sensibility and expert graphic design make for a pleasant user experience. But when aesthetics become the primary focus, they distract from the real goal of software – performing a task. If you find your team is endlessly debating the aesthetics of a design, it is probably over weighted in the balance. Other constituents will often vie for top billing on the features and controls that are most important to them. But always keep in mind, a design that attracts an inordinate amount of attention is diverting focus from the goals of the application. You will pass this distraction and inefficiency onto the end user by baking it into the product.
Restoring balance: Remind your team that the best designs are transparent; the user should be almost unaware of distinct controls and overt actions. You want to strive for muscle memory, not contemplative artistic appreciation. Strip down the user interface as much as possible. Remove any superfluous controls. Prioritize actions and progressively disclose less important tasks. If there is still too much clutter, it is probably a sign that requirements are not refined enough or that there is not a clear enough understanding of the end-user workflow. Table the design and make a flowchart of usecases. If a flowchart is complicated, the user experience in the software will be as well. Flowcharts should reveal primary vs. secondary task flows. Optimize to make the primary tasks efficient, but not at the expense of encumbering the secondary task.
3. Loosing focus at the expense of agility: Agility is quickly becoming the standard operating mode for software development. Developing quickly, releasing often, and frequently correcting the course has become the expectation from business stakeholders and consumers. As shrink-wrapped software distribution becomes less and less common, developers are abandoning waterfall product cycles. As a result of this shift, having the luxury of exhaustive requirements discovery and comprehensive design specifications prior to development is becoming extinct. This often makes UX team members nervous, especially those who learned best practices during the days when waterfall was the only option. Becoming too reactionary to the tight release and update intervals leads to myopic design, which can lead to bolt-on features. This eventually creates a dreaded Frankenstein application, with an inconsistent and discontinuous user experience.
Restoring balance: Keep one eye on the big picture. This takes some mental gymnastics, since you’ll simultaneously be in the clouds and trenches at the same time. If the strategic goal of the application is in focus, it will permeate to the tactical work demanded by quick iterations. If it is a new product, you’ll need to have some idea of the strategic vision to inform the process, but not so much that you can (and should) design the application end to end. This is, as much as anything, an exercise of taking a leap of faith early and trusting in the process.
For this to work, however, three things must happen: 1) technical teams must be amenable to and encourage iterative rework of the user experience. The quid pro quo for relinquishing an exhaustive design is flexibility to change your mind iteratively. 2) Business stakeholders must inform UX team members of business goals and strategies in a more detailed manner than historically needed. This insures that you don’t paint yourself in a corner and can react accordingly when business objectives change. 3) The UX team must establish and adhere to consistent visual language and set of design principles. What those are is less important than that they remain consistent. This will anchor the user experience in familiarity as features grow. This is the insurance policy against a Frankenstein app.
There are countless other things to keep in mind to maintain equilibrium. However, most of which, I’d argue would fall under one of the three broad categories stated above. The main thing to keep in mind is that the process is constant. The tensions above are a natural side effect of creating and maintaining software. The process is often contentious, but acknowledgement and constant rebalancing of these tensions will ultimately result in better software for all constituents.