Software design and development have historically comprised a set of fast-paced endeavors, and they are getting faster and faster. Agile methodologies have become the norm for how teams break up and distribute work. These frameworks got their starts in product-oriented fields like engineering and manufacturing, and are often accused of squeezing out big-picture, user-centered activities such as user experience (UX) design and research. Regardless of the implications, agile is here to stay and there’s not much for UX teams to do about it but adapt. This adaptation has been happening for a while now, and many of my colleagues have weighed in on the topic already (see Valle Hansen’s 4 Ways to Kick-Start Lean User Research for Agile Product Teams). Here’s my spin on how UX teams have continued to tailor our UX design principles to the product development process.
User experience thinking is seeping into other disciplines at an accelerated pace. Topics that used to be esoteric subjects discussed in sequestered design reviews are now openly discussed at every layer, in every stage of the product lifecycle, and with nearly every stakeholder–from development architects to product managers, and from product discovery all the way to post-launch maintenance. User centricity is at the forefront of people’s minds, a refreshing change from the old days when disciplines were more compartmentalized. At the same time, UX practitioners are being pushed to think in more technical terms. As data gets bigger, reality gets augmented and form factors multiply, UX practitioners are forced to become more conversant in the technical capabilities (and limitations) of the technologies they design for.
We can partially thank agile methodologies for this cross-pollination of thinking. It was agile’s emphasis on cross-disciplinary teams that brought everyone to the same table and its insistence on constant iteration that made sure it happened frequently.
Designers are now expected to design and iterate with agility. Just-in-time has become the norm, with the tectonics of market pressures and reprioritization shifting under our feet constantly. So how do we anticipate and roll with the rapid-fire changes instead of being bowled over by them? The answer is simple: product-centric thinking. “Product thinking” is nothing new but it has seemed to be a recurring theme in UX design circles lately (see Kikkel Blasse’s post Why Product Thinking is the next big thing in UX Design). Designers should be thinking holistically in terms of the product the user hires to complete a job, rather than focusing myopically on the features that make up the product. It is a frame of mind that product managers have been tasked with for a while, but this thread has often been absent or nascent in design processes.
Here are 3 simple steps I’ve employed to achieve this balance as a UX designer:
1. Clearly state the business problem / opportunity your solution addresses. Clearly and concisely identifying the gap, deficiency or pain point seems like a commonsense first step. But this information often gets neglected or fragmented when it is time for a designer to get started. Stating, reiterating and validating the pain points is a cornerstone to any design initiative, big or small.
2. Enumerate the user goals for this problem. These goals should be measurable! Figure out the what a user considers “success” within the defined business problem. Measure the efficacy of everything you design for a particular persona against these goals. Make these measurements as quantifiable as possible. They are your number-one guidepost to user satisfaction and, ultimately, adoption.
3. Apply these 2 principles to every requirement, every user story. No matter how seemingly small the task you’re designing, there should be a direct thread connecting it back to a user goal and ultimately the business problem at the heart of the product mission. Just as product management has embraced UX thinking, designers must embrace aspects of product thinking.
There is no question about it–complex software is becoming more and more ubiquitous. The sheer amount of data that is now available is staggering compared to even a decade ago. The connectedness of systems is ever increasing and the distribution of solutions across multiple form factors, from TV screens to watches, is hard to keep up with. As designers, accounting for multiple form factors at big-data scale can be daunting. It is difficult to design for this complexity using static assets such as wireframes or high-fidelity mockups. That’s often a great starting place, but actually experiencing how a system performs under the weight of millions of records can be the single most influential factor in any modern design. Seeing, in real time, the way an interface elegantly responds from a large monitor to a watch can give you clues about how to compartmentalize information in a way that your unaided imagination cannot. Designers have trained eyes. Expecting stakeholders or prospective users to fill in the gaps of these complexities on static mockups is often too much to ask. Doing this rapidly under the relentless forward movement of an agile process makes it all the more challenging. While this is a tricky dilemma to navigate, there are ways to successfully do so within agile:
1. Experience the underlying data as early and often as you can. There is nothing that can substitute the experience of viewing and traversing large amounts of data. Even if it is through query results dumped into Excel, experiencing the data firsthand will enhance the designs and make you a better designer. This will also make you acutely aware of performance traps when it comes time to design how to disclose that data to users. Sidestepping this pitfall could be the single best way to improve the UX of your design.
2. Build semifunctional prototypes for discovery and testing. New design tools are being introduced all the time to bridge the gap between static designs and interactive prototypes. While a lot of progress has been made, these tools have their limitations. When possible, it is often best to actually prototype designs in the front-end technology your application is being built in. This requires technical skills that not all UX designers are comfortable with. But UI frameworks have come a long way in recent years, particularly on the web, to componentize UI interactivity for rapid build and reuse. These types of prototypes will give you a definitive look into how UIs will respond on different screen resolutions and form factors. Working within the technology that you’re designing to has the added advantage of a more direct translation of that design when it comes to production-quality implementation.
3. Collaborate closely with front-end and back-end developers. Developers, especially seasoned architects, will proactively see scalability and interaction red flags that others will miss. Since their perspective is rooted in implementation, they often have a keen eye for inconsistent behavior, suboptimal workflows and unnecessarily intensive procedures. Engage them early on in the design process whenever possible and include them in the iterative approach to designing.
Software design and development is fast-paced. Agile methodologies have turbocharged the already demanding delivery expectations. Heap on a healthy dose of increased scale, complexity and multiplicity of target devices, and UX design becomes a very precarious position to find yourself in. As much as agile has brought accelerated, tactical, abbreviated design cycles, it has also knocked down the barriers of working in siloed disciplines and ushered in multidisciplinary collaboration. Just as our product management and development counterparts have adopted our user-centric mandate, so too must we, as UX practitioners, adapt to some of their core tenets. After all, now more than ever, we’re all in this together.