HOW TO TRANSFORM YOUR UX PROCESS TO DRIVE …research > insight > hypothesis > test > repeat. The...

HOW TO TRANSFORM YOUR UX PROCESSTO DRIVE SUCCESS AT CONTINUOUS DELIVERY

Software’s most important quality is its adaptiveness and ease of change. Today, companies are stretching that quality to the limit, making changes and releasing code at breakneck speed. But are we adapting to the customer—or simply adjusting to the accelerated pace of software itself?

What does it mean to crush user experience at the speed of continuous delivery?

This E-book explores the intersection of UX disciplines and advanced software development practices like continuous delivery, agile and DevOps—methodologies that have radically reshaped the way software is designed, built and served out to customers. Based on experiences and observations we’ve made through nearly 30 years of work with some of the world’s leading brands, we share insights here on the evolution of UX practices within this changing landscape, including:

• Grounding UX decisions in the essential context of continuous delivery

• Warning signs of dysfunctional UX in the agile environment

• The costs of shortchanging UX though cycles of continuous delivery

• Ideas for building robust UX practices into your continuous delivery process

• The importance of continuous learning to effective backlog management

• How seasoned UX specialists help you avoid (or overcome) UX debt

• Practical ways to instill a culture of learning in your continuous delivery enterprise

• The importance of team structure, deliverables and communication

• Other information, perspectives and resources for your journey

OPTIMIZE YOUR UX FOR CONTINUOUS DELIVERY, DEVOPS AND AGILE DEVELOPMENT

3


4

Speed wins.

No matter how innovative your product, competitors are working hard to outflank you, developing their own breakthrough solutions to the same problems you’re trying to solve. You can build all the right features, but if you can’t get them into the hands of your users first it likely won’t matter: they will have moved on and may never come back. Speed is what matters.

The need for speed is driving companies into a digital revolution, pushing organizations to completely rethink their entire operational models and business strategies. In their search for new ways to deliver product updates faster, leading brands have staked their futures on methodologies such as continuous delivery, agile development, DevOps and related practices that enable them to deploy with greater speed, better quality and less waste than ever before. Today, continuous delivery enables Amazon to release new code nearly every ten seconds.

But speed is only half the story.

After all, no matter how fast they can do it, the job of any product team is not simply to ship code. It’s to deliver value and help their company win. Engineers may come to see the continuous delivery of clean, quality code as their ultimate objective—but for product managers, focusing on speed alone is a dangerous trap.


5

The Context of Continuous Delivery

“We must learn what customers really want, not what they say they want or what we think they want. The only way to win is to learn faster than anyone else,” declared Eric Ries in The Lean Startup. Or, as Google asserted more broadly in the very first of their Ten Things We Know to be True: “Focus on the user and all else will follow.”

Google—along with companies like Apple, Facebook, Netflix, Nike and other brands shaping our world—invests heavily in “focusing on the user” because UX is a profit center rather than a cost center. Experience design is good for business; it drives relevance and results. Experience-driven software is a key factor in value creation, driving brand integrity, market growth and profitability.

But while UX research and design help to validate solutions before writing code, shipping an actual product is where the rubber meets the road in terms of verifying that you’ve truly addressed a customer problem. This is where continuous delivery (CD) comes in: by shaping and automating software delivery to greatly accelerate the release of code, it exponentially increases the opportunities to assess the impact of your work on the end user.

Continuous delivery may not be a particularly good method for developing an original problem-solution fit (lo-fi prototypes are better). It’s not the best choice for validating that fit, either (this work s best done before entering the CD process). But continuous delivery is an exceptionally good process for observing changes in user behavior and using that learning to build a better user experience—and to repeat those steps over and over, in rapid succession.

Continuous delivery builds confidence to quickly deploy a new feature or change that in turn tests newly formed hypotheses informed by UX research. Each release is an opportunity to validate and learn—a feedback cycle of research > insight > hypothesis > test > repeat. The more feedback cycles, the more opportunities to learn, iterate and win.

The core context for CD isn’t to be faster. It’s to be better. It’s to empower teams to make great products that delight users and dominate markets. Continuous delivery should never come at the cost of continuous learning.

CONTINUOUS DELIVERY =CONTINUOUS LEARNING

When you truly put people at the center of your product, brand and business, then understanding their needs and aspirations becomes the most critical part of that business. Successful companies use continuous delivery because they want people to feel that the brand behind their products cares deeply about them and their individual experiences. Google, Facebook, Amazon and others update their software at a blistering pace to keep ahead of their competition—but their ultimate goal is better outcomes, not bigger output. Their product teams use customer input to deliver faster business outcomes, while expanding quality improvements at a greater speed.


6

When Agile is Fragile

Given this context, it’s clear that UX proficiency is a leading indicator of company performance, where better business performance is grounded in the ability to gather and process user data through accelerating cycles of development.

The maxim “fail fast,” then, does not simply instruct us to deliver code at breakneck speeds. Rather, it urges us towards a better way to learn while we do it, to fundamentally integrate the exploration of customer needs and wants with the iterative process of engineering and deployment.

It is by no means, however, a simple feat to align UX design cycles with the rapid development sprints of a continuous delivery enterprise. Anyone who has sought to execute a release quickly has invariably experienced the trade-offs and compromises necessary to meet the timeline objectives.

There are a variety of specific reasons and ways that a company’s well-disciplined process of testing, iterating and learning can go awry during and after their move to a continuous delivery model. Product managers and other leaders should carefully examine their own operations to be on the lookout for some of the following pitfalls:

• Not fully baked: Unlike the other parts of the CD process, effective UX cycles may not be fully baked into your continuous delivery methodology. Sometimes this is a matter of relying on traditional UX methods that don’t always translate well to a fast-paced, agile environment. Other times, the right tools for collaboration and communication between developers and UX designers aren’t in place to optimize iteration cycles. Often, though, the biggest challenge is much more fundamental: your culture. Remember: deployments may be empowered and accelerated by the tools, but success at continuous delivery requires an organizational culture that’s focused and aligned to the outcomes and value the product teams are trying to deliver, and the customer problems they are trying to solve.


7

• Agile without agility: The flip side of the above is being overly wedded to a single, specific process of development and release—to value agility in deployment over agility to the market. Different CD methodologies optimize for different goals, and each investment of effort trades against something else (e.g., predictability vs. productivity). As your team cycles along the product roadmap, the needs and challenges it faces will change—especially when it comes to UX design. Focus less on whether a particular aspect of process is good or bad and start asking if it is well-suited to the situation at hand. Remember: The importance of a robust CD process is to engage your team in how much value they’re delivering to customers, not how many story points.

• Overemphasis on cost: Companies that adopt CD for its cost efficiencies, or that come to focus on the predictability of budgets and schedules over the learning opportunities of continuous iteration, tend to develop some very destructive behaviors. For instance, UX artifacts signed off on by stakeholders are too often treated as concrete specifications to be followed religiously (rather than as context for collaboration, further UX engagement and user validation) out of fear that these results will push the program over budget. The prioritization of output over outcomes marks the ultimate failure of continuous delivery within an enterprise. Remember: The basis for continuous delivery is not to lower costs but to deliver a high-value user experience. Doing so focuses development on building the most critical functionality, and that focus in turn orients the team toward effective practices and behaviors.

• Overemphasis on automation: When you’re building your CD pipeline, automation is prioritized. But what automation doesn’t do is improve quality; when the overall process isn’t optimized, automation just makes the failures happen faster. Remember: without quality, right-sized requirements—fueled by strong agile UX practices—you’re not really moving the needle no matter how fast you’re going.

• Small-ball syndrome: Rapid iterative cycles demand that development is broken into smaller and smaller chunks. Over a span of many such cycles of incremental iterations and incremental feedback, it’s all too common to squeeze robust UX conversations out of the process and lose sight of their value. Teams can eventually lose the ability or appetite to deliver large-value features if they don’t fit neatly into a sprint. Remember: as soon your team is no longer actively investigating iterative changes in the broader context, you’re missing out on key decision points in the overall improvement of your user experience.


8

• Ready, shoot, aim: Similar to the above, an emphasis on sprints can lead product teams to eschew any form of long-term planning and, in some cases, lose sight of the larger product vision. Yes, agile development and continuous delivery are designed to surmount the inherent unpredictability of putting a long-term vision into action. But that doesn’t mean that these practices are mutually exclusive to longer-term planning. CD methods generate feedback to track that you’re building things, but are they the right things? Are they actually hitting the targets that the business is aiming for over the long term? Remember, as Dwight Eisenhower once reflected on the unpredictability of battle: “Plans are useless, but planning is indispensable.”

Data shows that scenarios like these are more the rule than the exception at large enterprise companies. Surveys conducted by Freeform Dynamics for a 2017 report by CA Technologies showed that only 14% of developers strongly agreed that they are able to tap into processes that provide end-user feedback on their requirements and app experience. Only that same small number agreed that CD best practices are followed all the time, and just 18% felt that those processes were even documented or well understood. As CA’s report noted, “processes lack discipline and customer insight…and feedback loops that include customers are still rare.”

• The tyranny of the present: There’s always an immediate need to research and test a variety of ideas that directly impact users, and often these needs may be driven by stakeholders outside of the product team. Because they are unanticipated, UX specialists are typically unprepared for such changes and have to scramble to assemble new designs. To move quickly, they rely more on assumptions than on knowledge—which may ultimately create more user friction than the original issue they’re trying to address. Compounding the problem, these short-term needs keep the team from investing in the kind of long-term research that really builds product value. Remember: knowing when to build or try something is vital; understand the time-based risk of any new requests, and rely on your product roadmap to guide the way through competing priorities.


9

The Costs of Going Sideways

Knowing what pitfalls to identify and avoid is half the battle. The other half is the battle—the ongoing effort that must be made to ensure UX best practices are maintained with diligence and rigor as the pace of delivery moves faster and faster. To do otherwise not only erodes the end user’s trust in the product, it ultimately adds costs at several points downstream.

In broad terms, research has shown that for every dollar spent resolving issues uncovered during a UX design cycle, companies that overlook this work can expect to spend $10 fixing that issue once it is in development, and $100 to fix it after it is launched.

Compounding the cost of each fix are other hidden costs often unconsidered in the heat of ongoing delivery sprints. When iteration cycles don’t incorporate robust UX practices to effectively illuminate the meaning and intent behind user feedback, engineers may be apt to complicate features and technology to solve problems—or focus on the wrong problems entirely. Software that did one thing simply and elegantly can quickly grow more complex when unguided—and, as a result, become more difficult to refactor, so changes to its code ultimately take longer (and cost more).

Indeed, the work of implementing a feature initially is often a tiny fraction of the work to support that feature over the lifetime of a product. Sometimes complexity is a necessary cost, but what might take two weeks right now adds a marginal cost to every engineering project added to this product in the future. And when the team is finally forced to address these issues, the effort delays focusing on the innovations that otherwise might give the product its competitive edge. The time required to define UX solutions with known shortcomings, to discuss them, and then to address them, ends up costing more time and effort across all teams. Sometimes the UX debt is so expensive that teams give up entirely on effectively addressing the issues/

Moreover, when the quality of UX is seen as the central problem, it spells user dissatisfaction and reduced sales. Recently, The Career Foundry calculated that by 2020 this cost will grow to more than a trillion dollars for e-commerce brands alone, a figure based on projected online sales and research from the Baynard Institute that indicates “conversion rates for e-commerce could be improved by 35%” through better UX design.

“Robust UX practices are the connective tissue of continuous delivery. They help ensure we never lose the thread that links learning to code to business value as we sprint through each cycle of change and iteration. ”

— MICHAEL HINNANTDIRECTOR OF EXPERIENCE DESIGNFILTER


10

There’s one more important cost to consider when UX is compromised in the CD enterprise: lower employee productivity and satisfaction. Done right, continuous delivery often has a positive impact on the happiness of the people doing the work; faster feedback cycles enable developers and other team members to stay focused on solving a single problem and iterating on it quickly, bringing their full experience and capabilities to the challenge. Developers see themselves, rightly, as being at the leading edge of these continuous delivery enterprises.

But to be truly agile, responsive and capable of continuous improvement, they need to be armed with the UX research, data and designs necessary to succeed. They also need leaders who understand the issues involved. According to the Freeform Dynamics study cited above, however, only 15% of developers strongly agree that leadership teams are putting into place the right processes and practices to deliver what the business needs. When companies ask product teams for real improvements but don’t follow through n their end, the situation becomes untenable. Yes, shipping code feels good, but good talent want to deliver code that matters and makes a difference. If that’s not happening, good talent will look elsewhere for the supportive environment they need.


11

THE WAY FORWARD

The market forces driving brands towards continuous delivery are user-centric, not engineering-centric. But in most cases it is engineering—and specifically, the collaborative model of development and operations known as DevOps—that is the focus of a company’s CD deployment.

A key way, then, to ensure robust UX practices are likewise a central focus of your continuous delivery enterprise is to take this same integrative approach—to actively and deliberately transform the “power struggle” between UX and development into the “power of collaboration” that has driven success for DevOps.

Continuous Learning in the Backlog

One key place to put this into practice is the backlog, a core component of agile development and continuous delivery. Remember, continuous delivery is about continuous learning; when addressing your backlog, the fundamental question isn’t “what do we need to build?” It’s “what do we need to learn?”

The days of far-ranging, 500-page requirements documents are over, and so are traditional UX practices built on extensive requirements capture to ensure that deliverables are as detailed as possible at the start of the project. Today, the notion that a product backlog will paint a complete and comprehensive solution well before the next sprint begins is antithetical to the practice of continuous delivery.

At the same time, development needs quality UX specs and requirements to succeed in delivering value. Among CD-related practices, the ability to capture user requirements was the number one priority identified for improvement in a survey of more than 3,500 software professionals by Outsystems for its 2018 report on The State of Application Development.


12

What this means, then, is that product managers need to deliberately work more UX discovery and design cycles into their continuous delivery backlog. And not just with lip service: at both a philosophical and operational level, the team and the organization need to make sufficient room in the process for continuous learning, making sure not penalize this work. This means getting comfortable with the fact some iterations may drop down in the schedule from time to time to accommodate more robust learning activities.

Jeff Gothelf, the author of Lean UX: Designing Great Products with Agile Teams, offers some specific recommendations on how to make this happen. He highlights the periodic use of “experiment stories” within your backlog just like any other story—it goes on your backlog and gets prioritized against your user stories. The experiment story is staffed and estimated by your team just like a user story, and holds two key directives: what you need to learn (what is the hypothesis), and how you’re going to learn it (the tactic: A/B tests, customer interviews, etc.).

The key is to plan ahead, determine how to prioritize it, and decide what stories fall below it because they may be fundamentally changed by the learning from this experiment. Again, a feature may fall out of the sprint to make room for the experiment story, which may seem anathema to teams focused on speed. But from a product-value perspective this isn’t a loss, because the point of an experiment story is that your team didn’t have enough information at the beginning of the sprint to properly inform the iteration in the first place. The key for product managers is to be honest and transparent with yourself about what you don’t know—about what your team needs to learn to deliver real value to your product and your customers.

Once the experiment story is complete, bring the learnings to the full team and other stakeholders; capture the findings in your wiki, follow up with appropriate specs and UX design artifacts, and assess the impact on your backlog—up to and including re-prioritizing or writing new experiment stories.

Leaving room for this kind of learning builds a better a better platform for shared understanding into your continuous delivery process. By being transparent, identifying your knowledge gaps, making room for learning and incorporating this into your subsequent sprints, you transform the culture over time from an emphasis on output to a focus on outcomes. The process


13

of managing and prioritizing against your backlog becomes more and more efficient and effective, which in turn drives more value and helps you deliver better products.

Highly experienced UX specialists, adept at agile methodologies, play a key role in maximizing the value from this process. Beyond the ongoing design collaborations in any given cycle and the ongoing fixes listed in the backlog, they bring a level of expertise and insight that helps product managers address some of the most critical decisions when determining priorities: What scope of advancements are needed to distinguish the product from its competitors? Where does novelty and innovation matter the most, and where is it acceptable to be on par? How do backlog prioritizations intersect with the interests of other stakeholders like analysts and market influencers? How does UX create a clear and compelling brand identity that also accommodates dynamic business imperatives? And how can a product team process all of this into an incremental roadmap that remains agile and sets a strong vision?

Q: How do you see agile product development, UX, and the relationship between the two evolving over the next several years?

A: Companies are starting to realize the importance of good UX as users are moving online to conduct a wide variety of everyday life. For customers this should mean more involvement to help form a seamless user experience when trying to accomplish tasks.

For organizations it means understanding the need for more time and budget up front to be devoted to understanding the User Experience from the user’s perspective which can help save teams from going over budget, needing more money before completion, or needing money for fixing issues. A lot of money is being spent on building out solutions before proper research is conducted and this leads to far more work, time, and money spent after the fact.

In the next few years, future-thinking companies that have UX embedded in their processes from the beginning, I believe, will easily stand out, even more so than they do now, among the rest.

WITHFILTERUX DESIGNERCORRIECOLUMBERO

A&Q

READ THE FULL INTERVIEW WITH CORRIE AND AARON BOWERSOCK AT FILTERDIGITAL.COM/BLOG/UX-IN-THE-AGE-OF-DEVOPS


14

Managing UX Debt

For companies leveraging continuous delivery as a source of competitive advantage, these are essential questions. They are also a key means for experienced UX professionals to help a product team avoid and manage its UX debt.

This debt is typically incurred when teams struggle to balance strategic and incremental planning; when items from the backlog are cherry-picked for work rather than prioritized by value; when areas of UX work, such as research and concept validation, are sacrificed for saving time and costs; or when teams forgo precision and thoroughness in the implementation. In other words, UX debt is seeded in the mentality of “output over outcomes.” Certainly, there are times when sacrifices must be made to meet other business demands; but UX debt is magnified when these compromises go unacknowledged and in the absence of full transparency—when the awareness that certain features and task-flows are unwieldy remains unspoken.

Joshua Kerievsky, who first coined the term “User Experience (UX) Debt” by extending the technical debt metaphor to user experience design, explained that all UX debt eventually comes due—usually when the gap between product performance and product vision becomes critically untenable, and your software provides an incoherent, unstable and unfriendly experience for users.

In other words, when it’s too late.

As Kerievsky noted, that debt usually comes due in the form of less customer satisfaction, lack of trust and possible customer defections. For your team and the organization, it comes due in the form of unplanned recovery work. Even simple fixes consume resources and keep the business from moving forward. Harder tasks, like refactoring user flows or redesigning navigation systems, can be paralyzing because they have system-wide implications and offer no clear path to make incremental progress. Left to compound, UX debt can ultimately divert the entire organization just to pay down the interest.

Again, this is where highly skilled and experienced UX professionals can be most valuable. They can collaborate with engineers and product managers to assess UX debt relative to the product’s current maturity level, and make targeted assessments of which design shortcuts with structural or system-wide impact will be most difficult—and costly—to unwind down the road.

The term “UX debt” comes to us from the term “Technical Debt” coined by Ward Cunningham. Technical debt (sometimes called code debt) is “a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution” according to Ward. Basically, the costs of cleaning up less-than-ideal code. It is “debt” because you need “pay it off” – go back and rewrite the less-than-ideal code. If you don’t then there can be less-than-ideal consequences that can affect your customers’ experience – sending them to your competition.

— SEAN VAN TYNEUX EXPERT AND AUTHOR


15

They can also help to calculate and quantify UX debt, and to develop data-driven measurement of the full enterprise cost of that debt. This work not only helps prevent UX debt from piling up past the point of no return, it can also serve as an effective communication and planning tool across multiple stakeholders, teams, and senior leadership.

From there, they can collaborate to establish a predictable, proactive playbook for the team to pay down UX debt—for instance, as a fixed allocation of debt tasks every sprint, a dedicated debt sprint every few sprints, or a mix of strategies best fit for the team and situation.

At a higher level, seasoned UX pros can help product managers better assess UX debt as a risk to the overall business—especially when decisions rooted in expediency and time-to-market concerns create UX debt that cannot be accurately measured (i.e., you cannot validate an idea that was abandoned along the roadmap). For instance, rather than analyze the gain from one particular implementation, they can bring insights and understanding of UX strategy that address the issue from different and more salient perspectives, such as, “What does the user lose by not implementing the better solution?” or, “What greater value is there for the user by not implementing this more complete solution?”

Best of all, seasoned UX pros can help you avoid UX debt in the first place. Experienced in agile and continuous delivery environments, they are adept at creating faster flow while keeping the dev team abreast of design rationales and strategic value intent in the most systematic and disciplined fashion. They can help make sure that everyone who has a hand in the implementation is educated on the standard of the UX quality to be met, and help product managers to quantify the quality and success of UX in the business’ performance metrics.

Just as important, experienced UX teams and specialists bring high EQs to their roles within the product team to help establish strong cultural values around avoiding shortcuts and upholding diligent UX practices. They can also help project managers hold each team member accountable for the value they are charged to create beyond the current sprint. In other words, they can play a key role in shifting your organization’s focus from continuous delivery to continuous learning, and can help your team internalize the practice into their very psyche.


16

Create a Culture of Learning

This cultural component—internalizing a diligence around UX in the face of rapid iteration cycles—is no small matter. Some consultants and implementation firms claim that all it takes for your company to succeed with continuous delivery is a team with the right tools and a bit of time to get things rolling. If you’re reading this paper, you know the truth is hardly so simple or straightforward.

Designing an evolving product, one that delivers a steadily growing degree of value and gratification to customers, depends deeply on the user-centric culture of your organization. As noted earlier (see “When Agile is Fragile,” page 6), the success of a continuous delivery enterprise is most often at risk when the principles of continuous learning are not baked into your organization—when the process of UX research and design has not been integrated with those of rapid iterative development. But when a company successfully educates and trains its departments to align investments and priorities and incentives around the user—and more specifically, around learning from and about the user—then a culture emerges that guides individual contributions toward that ultimate goal.

Within your own organization, department, or team, look for these key attributes of a successful, user-centric culture:

• Transparency: Does your organization’s leadership communicate the role UX design plays in their strategy for creating value for customers and outgaining the competition? Do all product (and product-related) teams have a common understanding of the standard of quality and user value their UX design should deliver to customers? Do all individuals who contribute to shaping the UX share a common knowledge of the business underpinnings that inform design decisions?

• Collaboration: Today, business leaders in the CD enterprise are now making a place at the table for UX to have its own seat, on the basis that customer-centric organizations outperform those that are not. In the model of DevOps, they view success to be as much about communication and collaboration as it is about software. Product managers can implement this idea within their own teams in a number of different ways, including: cultivating egoless interactions and supportive engagement; developing discussion themes early to allow ideas to mature and incubate; explicitly aligning goals and reinforcing the accountability of each individual for delivering value to the customer. In particular, include a member of the development team when conducting customer interviews, so she or he can hear directly from the end user instead of relying on notes from the UX researcher or product owner. It will also give them a stronger and more ingrained understanding of the software-experience-value equation your team is striving to solve.

EQ MATTERS

UX is an incredibly people-focused field – both in terms of the need to be in touch with users’ thoughts and emotions, and the need to effectively collaborate and exchange ideas and feedback with other members of the product development team.

Increasingly, research is showing that “dream teams” are made out of people with high EQ – those who can identify and manage their emotions and the emotions of others.

We have seen success when clients adjust their UX hiring strategy to place a greater focus on EQ. Taking a deeper look at EQ is one of the most powerful changes you can make to your UX team-building process.

For more on the importance of EQ in experience design, download Filter’s Guide to Building Your UX Dream Team.


17

• Flexibility: Continuous delivery is a proven method of building software quickly, effectively and efficiently. But you also want to build the right thing quickly. Development teams in a CD enterprise may tend to believe that up-front planning can be skipped and dealt with along the way. Instead, your team should be “agile” enough to apply different decision-making frameworks, and to appreciate that up-front planning at the beginning of a particular sprint doesn’t conflict with agile methodologies (and in fact reduces the risk of UX debt down the line). From a broader perspective, it’s important that the team and organization acknowledge that while methods such as agile, DevOps and Lean UX provide common vocabulary and practices, user needs are what drive the solution direction. True agility comes from a deliberate effort towards continuous improvement—the iterative and incremental process of optimizing the overall way you deliver software. This demands constant evaluation of your current practices against targeted results—an external-focused evaluation to balance the introspective process analysis of sprint retrospectives—and the flexibility to jettison what isn’t working and chart new ways forward.

• Empowerment: Being effectively flexible requires empowering people on your team. Does your organization permit all members of the product team to suggest and follow through on improvements to the user experience, even when the business stakeholders have signed off on the plan? This doesn’t mean team members are free to do whatever they want; everyone still has a role. But unlike traditional models where people are hired for a skill set, given a role, and then told how to execute it, they should feel empowered to innovate on how they deliver their value—including when to make changes to specs that were the basis of funding the budget. One way to empower innovation and drive problem solving as a team is to start making the development and use of customer personas a team effort: each member has unique perspectives and insights, and needs to understand how the personas influences product development.

These attributes are easy to discuss but hard to bring about unless conditions are right. In addition to some of the broader strategies already identified here for building an effective CD culture in your organization, we have seen many other practice areas that drive UX success in the continuous delivery enterprise—including teams, deliverables and communications.


18

Structure Your Team

Success at continuous delivery takes individual and team commitment to precision in all facets of software design and development. The close melding of product management, engineering, and UX design should build greater trust among team members and elevate the overall quality of product design while lowering costs and delivering greater customer value.

An easy way to build these outcomes is to make sure you have all the necessary players within your team from the start. If development or UX is omitted at the early stages of a project, you reap only half the value of each. Managers or directors are not the only ones who should be included, either; everyone is important and they should feel that way from the start. They’re investing their talents and their time into creating your product.

In addition, you should have the benefit of opinions and expertise of each member right from the start of the project. Great ideas come from anywhere and anyone on the team, and problem solving as a team requires everyone to participate. These people should be together from day one so that product decisions are agreed upon and understood throughout the team, and they all hear the same conversations throughout the duration of the project. If not, you’re likely to find yourself playing the development version of telephone, where core values trickle out inconsistently until the original vision is lost. You want those core values to be translated throughout the entire process.

When your team contributes to designing the solution together at the start, then everyone understands what is expected from each practice. For high-velocity productivity, it’s best to pair UX specialists with developers who vocally respect each other’s crafts, understand the issues each side faces, and will effectively collaborate how they can best work together to deliver the most value and innovation. Though ongoing cycles, they will naturally accelerate their pace the more they understand and support each other.

A proven UX expert should understand developer language and be embedded in the development teams. This makes the UX more accessible to the developer and gets UX issues addressed on time. It also helps promote UX skills within the development team.

DON’T DOUBLE TASKYOUR UX ROLES

Faced with tight timelines and limited resources, companies often attempt to address their growing list of UX demands by putting tasks on their existing employee’s plates that fall outside of their areas of expertise.

But assigning very specific, high-stakes UX tasks to whoever you have on hand – no matter how talented they are – works against them, their team members, their manager and ultimately the end user.

Instead, identify the precise UX skill set you need, and don’t settle for anything else.

UX roles are extremely nuanced, so hire for and leverage them accordingly. Set your product and team up for success by care-fully aligning skill-to-task and task-to-cost when it comes to these deeply specialized roles.

For more on the importance of UX specialization, download Filter’s Guide to Building Your UX Dream Team.


19

Likewise, developers should learn the basics of UX in order to better grasp the user-centric design process and learn to follow UX guidelines. There is nothing a UX designer likes better than a fast engineer who nails the details on the first pass. They’ll want to work even harder to please this person.

Ideally, your team will be fully self-sufficient, with all the roles you need to be able to handle user research, UX design, front-end development, back-end development, testing, documentation and other operations of product change. Multidisciplinary teams also save time and money by eliminating organizational dependencies, which add cost to manage and often end up taking longer because of competing priorities.

You may be able to build such teams with in-house talent, but when it’s simply not possible to bring all of these functions in-house, consider alternative ways to augment and integrate outside talent early into your product team. This not only ensures you keep moving forward though the changes at hand, but also is a great way for your core in-house members to learn and expand its operational effectiveness.


20

Optimize Deliverables for Agile

As noted, key to the continuous delivery enterprise is an emphasis on small, focused iterations that enable rapid cycles of deployment and user feedback. But many teams struggle and incur UX debt through cycles of iteration because UX deliverables aren’t optimized for this process.

For instance, even agile project managers often come to the table with UX specifications and design deliverables too large or out of scale with agile development. While a fleshed-out set of specs used to get budgets and buy-in from stakeholders can give teams a strong sense of product vision and UX flow, they don’t enable the rapid delivery of high-value features: a large polished spec screen is one large unit of conversation, which is out of proportion to the units of design, development and validation tackled in a sprint. Ultimately, this approach to UX design increases the scope of work—because there’s no ready way for developers to discern from one large spec what is high-value versus low-value, or which parts of the whole are most critical to validating a key hypothesis around market fit or customer need.

Fortunately, a seasoned UX designer can work with the product manager to straddle competing demands for larger and more polished UX deliverables (e.g., needed to secure stakeholder support) and more discrete specs and low-fi prototypes (that developers need to start on schedule and prioritize against the overall backlog). He or she brings a user-value-based approach to splitting the big picture into agile-sized deliverables aligned with a strategically iterative learning process—and also provide the design theory and context (style guide, themes, playbooks) that tie them all together.

This way, developers are better able to prioritize, test, and capture learning in a way that ensures each sprint output is an orchestrated test of business value, not a random addition of features. In doing so, expert UX designers can also help product owners better understand if the criteria used to measure value delivery actually the appropriate measures of success.

Drive Constant Communication

As Lean UX’s Gothelf observed, some UX designers may see this practice of “chopping the design up and delivering it piecemeal to the team” as compromising their vision of the product and putting out a sub-standard experience.


21

But more experienced UX pros understand that this practice actually puts them closer to where their craft, and the value it creates, gets revealed in the product.

As continuous delivery forces UX designers to think of the user experience in prioritized chunks, each of those small chunks—those functions and features—are a conversation that drives product development. UX designers are the ones to carry out and illustrate that conversion: ultimately, all those chunks have to roll up into one cohesive product vision, and UX designers have to ensure that the team keeps that vision in sight.

Aligned vision and ongoing conversation comprise the very foundation on which continuous delivery was built to thrive. Product managers need to ensure that those conversations happen efficiently, effectively and often. Having the right tools is one part of the picture, and alignment-driving practices like behavior-driven development are key as well. But if UX deliverables are provided without the opportunity for communication—if there is no established process to regularly discuss specs, review the data that is shaping them, or evaluate work against roadmaps—the likelihood of success diminishes considerably.

As a product owner, create transparency. Don’t rely on others to communicate to everyone; instead, actively share and point to roadmaps available to everyone. Constantly communicate user studies and conversations out to other stakeholders. Reward team members often for communication and collaboration. Highlight and demonstrate the impact of their work. In particular, tell anecdotes about customer pain points that were alleviated. Always start with the user problem. Don’t just assert or accept a pain point exists; ask why, understand the journey that creates that pain point, and focus team discussion on why that pain point matters. Keep what’s most important to learning and value delivery at top of mind for your team.

It won’t always be easy. As Gothelf notes, “the iterative cycle and the frequent varying opinions will inevitably create conflicts.” Again, this is where product managers should leverage the experienced UX professionals on their team—to connect low-altitude UX deliverables to the high-altitude vision of user experience and compelling customer value, so that everyone on the team is tightly focused, closely aligned, and deeply engaged in conversations about critical product outcomes.

BEHAVIOR-DRIVENDEVELOPMENT

Behavior-driven development (BDD) is an extension of other agile practices—one that puts user experience at the center of the testing process. Like user stories, test cases (“scenarios” or “specifications” in BDD) are written using common natural lan-guage easily understood by product team members and business stakeholders alike. In fact, each test case maps back to a user story, and thus offers a more user-focused process during rapid iteration cycles for organizing the conversation between UX designers, developers and testers.

Though BDD has been around since 2006, it is only now being more widely embraced by product teams—thanks to its fundamen-tal emphasis on UX and real-world user outcomes.


22

Conclusion

Because the stakes are so high, and the impact on business performance so significant, a vast number of companies are investing heavily to build a continuous delivery enterprise. All too often, however, they are surprised when they fail to reap the full returns of that investment.

In many cases, this happens because companies focus on output, not outcomes. They may be highly adept at delivering code at an ever-faster pace, but they are not nearly as effective at identifying valid user needs while doing so. They build rapidly and efficiently. They just build the wrong thing.

UX is not simply a secondary supporting function. And in the continuous delivery enterprise, traditional UX practices cannot simply be bolted on to this new development methodology.

They must be designed for and prioritized within the rapid iterative processes of CD. They must be baked into each cycle, and into the mindset of product teams and the culture of the organization. In particular, product owners—and UX practitioners who hope to thrive in this evolving environment—should pay close attention to the DevOps movement and what it teaches us lessons about how successful functional alignment looks in a continuous delivery organization.

In the best of all worlds, every company that builds software should expect each person it hires to have some fluency in UX. Not only product teams and their managers, but especially the HR department, which must be familiar with roles in UX and what it takes to attract, develop, and retain talent.

This is not an easy change, and you should look to enlist outside support along the way. Be sure to choose that partner wisely, though: agile UX practices run counter to the traditional interactive agency model, where revenues depend on weighty deliverables and documentation—and the hours needed to create them. Instead, seek a partner who brings a proven focus and proficiency in agile UX execution, who can swiftly deliver the expertise or capacity you need to keep delivering on schedule. A partner who knows how to quickly recruit, scale and manage teams—fully outsourced, or integrated with your own.

Most of all, a partner who knows the vital importance of continuous learning to the success of your continuous delivery enterprise.


23

Recommended Reading

Lean vs. Agile vs. Design ThinkingWritten by Jeff Gothelf, the co-author of Lean UX, this short, tactical book reconciles the perceived differences in Lean Startup, Design Thinking, and Agile software development by focusing on the values that underpin all three methods, providing practical tools immediately applicable to your team’s daily methods.

The Phoenix ProjectIn a fast-paced and entertaining style, three luminaries of the DevOps movement have delivered a novel that anyone who works in IT will appreciate. You will not only learn how to improve your own organization, you’ll likely never view IT the same way again.

Increase Your UX Team’s ProductivityThis e-book examines three common (and costly) mistakes Filter helps clients avoid when helping them build a UX team—and the solutions you can leverage when tackling your own UX challenges.

SEE ALSO: FILTERARTICLES & CASE STUDIES

Visit filterdigital.com to browse our online library of profiles insights, interviews, success stories and solutions that Filter has developed over nearly 30 years of innovative work for breakthrough companies and leading brands.


24

ABOUT FILTER

When we hire expert researchers, designers, developers and other specialists to work with our clients, we do so based on one essential belief: the hallmark of a great UX professional is that every decision they’ve made shows purpose and intent.

Shouldn’t your product reflect this same standard?

Filter helps leading brands shape, develop and deliver the world’s most engaging user experiences, multi-channel campaigns, visual designs and virtual realities. We bring highly skilled, deeply experienced teams and individual experts—tailor-matched and easily scalable for the tasks at hand—ready to integrate with your organization or deliver a fully outsourced solution. Our radical focus and pioneering approach help enterprise clients in Seattle and across the country execute diverse digital initiatives with greater speed, impact and efficiency.

To learn how Filter can help your team—or your entire company—optimize UX practices for continuous delivery, DevOps or agile development, please get in touch: call 800-336-0809 today, or email us at [email protected].

HOW TO TRANSFORM YOUR UX PROCESS TO DRIVE …research > insight > hypothesis > test > repeat. The...

Documents

Transcript of HOW TO TRANSFORM YOUR UX PROCESS TO DRIVE …research > insight > hypothesis > test > repeat. The...