Agile UX: How to Incorporate UX and Product Design Into Agile

DevOps is often defined as the processes, operations, methodologies, tools, and culture surrounding a company’s software and systems development.

But engineering doesn’t operate in a vacuum. Blueprints, ideas, designs, and concepts come from product design specialists who decide layouts, flows, and interactivity. These are non-engineering individuals and teams who share DevOps’ goals and desired results.

DevOps is about so much more than how developers connect with IT, how infrastructure is managed, and how frameworks can be improved. It’s about recognizing how many teams are truly involved in the software development process, how intertwined their roles and work are, and finding better ways to make sure everybody is at the table.

Developers and engineering architects want to be involved when the product and creative teams are designing the software or system. But where is that in the current definition of DevOps? Product, UX, and creative teams want to stay involved during engineering processes yet so many methodologies exclude them. These are old silos that we need to break down.

Your customers only see your user experience (UX). They don’t see how many developers you had or if you were Agile or Lean. They have no idea which DevOps tools are being used. Your company’s UX is the product, and it can make or break you. They wonder who built this piece of junk. With so much competition and people happy to uninstall an app or leave a website, will you get a second chance with the customer who abandoned you?

Agile Rarely Trains on UX or Working With UX Specialists

Many engineering teams often find UX to be siloed and difficult to collaborate with. UX doesn’t seem Lean and many flavors of Agile exclude specifics on how to work with UX. Some Agile approaches specifically suggest that a product owner describing a feature is “good enough.”

SAFe Agile makes the mistake of deciding that the best way to solve UX siloing is to exclude them completely. SAFe “empowers Agile teams” to do their own “Lean UX.” As more companies understand the value of incorporating UX specialists and a full UX process, SAFe is going in the wrong direction.

The absence of explaining UX and their processes from Agile training and books has lead teams around the world to exclude or minimize the involvement of specialist product designers.

• When you incorrectly imagine that UX just draws boxes on pages, it’s easy to assume “I can do that job.” Like so many American Idol auditionees are sure they are the best singer on the planet, most product managers and engineers self-assess as being great at UX. This normally means they believe they are great at laying out screens. But as this article explains what really goes into UX work, you will see how a UX specialist would not see a developer who makes wireframes as someone who should be given UX tasks.
• Books on Scrum suggest that if a UX specialist becomes a bottleneck, she should train non-UX roles to do her job. This type of decision is rarely suggested about other roles in software development; nobody would want an untrained or inexperienced developer to do the coding, even after a bootcamp or reading a book about programming. We would never suggest that if a developer becomes a bottleneck, she should train the project manager to do some coding.
• Hiring managers who incorrectly believe that UX is an artistic (UI) job hire artists to do UX work. There is no educational overlap between a degree in UX and in UI. Natural talents often don’t overlap; someone great at UX might be a poor artist and vice versa. Hiring for “UX/UI” often delivers you a great artist with minimal UX experience, expertise, process, or education.

Those looking only at the bottom line would love to slash the budget by giving UX tasks to individuals who might lack UX education, experience, expertise, skill, or natural talent. But this is short-sighted and can lead to poor productivity, efficiency, culture, product, and customer satisfaction.

Why You Should Include UX Design in Agile Development

In late 2018, management consulting firm McKinsey & Company published, “The Business Value of Design,” a report on research they did with over 300 companies.

They found that, “Design is the only way companies can stand out from the crowd.” When competitors have close feature sets, what makes them stand apart? Design is sometimes thought of as just the aesthetics or what makes this look like our brand. But when used with, “UX,” design means the architecture of features and the decisions made about screens, steps, flows, layouts, processes, organization, and menus.

UX is part of the continuous improvement process, always seeking to better understand users and select and design the features and product that best match their needs, solve their pain points, and bring them meaningful innovation.

McKinsey also reported that, “Companies must embrace design holistically and early in the process rather than seeing it as a small tool that fits in later.” Teams assuming that attention to user experience is something that can be minimized, excluded, or done after releasing the product are taking the wrong approach.

McKinsey collected quantitative data and found that firms that embraced UX design generated 32% more revenue and 56% more shareholder returns in a 5-year period. Declaring your company to be “user-centric” isn’t enough. You must walk the walk by integrating UX practitioners and processes from planning and portfolio down through development and QA.

Software Development Processes With and Without UX

If your company is not including UX in Agile software design and development, your process most likely looks like the image below.

A client, product manager, CEO, or someone with the vision tells engineering what they want. Engineering builds it, tests it, and gets it on a staging or production server. The person with the vision then sees it and, wouldn’t you know, they aren’t happy. They want something different or have changed their mind.

Engineering has to then cycle back to the beginning, find out what this person now wants, build, test, and cross their fingers that this is the charm.

If you have UX experts on the team, the Agile UX design process is quite different. That person with the vision comes to UX with the ideas, data, and customer pain points. UX cycles through the tasks in its user-centered design process and then tests these concepts before engineering writes a line of code. This ensures that the product or feature we’re considering building is the right execution of the right idea for our target customers.

Testing might bring some flaws to light, which allows UX to iterate and often test again. After UX’s process, you have a fully-vetted design ready to deliver to engineering.

If someone changes their mind along the way, that person talks to UX rather than putting it in as a change request to developers. UX runs interference during their process and nothing is sent to engineering without UX being involved in designs, decisions, and testing on real or archetypal customers.

Changes of mind at this point aren’t disasters since the cost for someone to change their mind at this point is minimal. Engineering hasn’t been delivered the blueprints, they haven’t started, and have nothing to rebuild. UX iterates on their designs and can do user testing to ensure that the ideas are a good, strong match to the customer base. Changes of mind burn time, but the overall impact on the budget is small.

UX Has a Formalized Process

User-centered design (UCD) is a formalized process that includes tasks that direct UX specialists to research, design, prototype, test on real or archetypal users, and then iterate based on learnings from testing.

Focusing on a few of these areas, we start with requirements and early discussions about features and projects. When UX first gets requirements and other project information, it’s important to start collaborating right away. UX should NOT find out later that they have designed something that can’t be built.

Start by bringing in UX workers or managers when product or project managers are deciding features and prioritization. A project with no value to the user can be removed, saving untold time and money. This is where maximizing the amount of work not done comes into play. Product and Engineering should support UX when they create less work for Engineering by reducing or removing features or entire projects. However, too often, projects have ego attached and teammates often exclude UX from these early conversations so that the project gets funded.

Research is an important piece of what UX does. It’s not user-centered without involving users. Statistics and quantitative data are great but there is no substitute for interviewing users, deeply understanding them, and getting qualitative data. UX wants to know the why and not just the what.

UX research also gets teammates on the same page by unifying everybody around personas, archetypes of target customers. Based on interviews with users, we aggregate what we learn and boil everybody down to 6 or fewer personas. What motivates them? What to do they need? Where are opportunities for our company, product, or service?

The best use of personas would be to include them everywhere. Product imagines features based on personas (and good data). UX designs based on personas. QA tests while imagining they are these personas. Marketing can add their demographic and other details, but they too should consider how brand voice, social media, and advertising speak to the personas.

Personas help non-UX workers get away from, “Well, I like it this way,” or, “The CEO likes it this way.” We are designing for these target customers and if you or the CEO do not fit into the personas, then UX is not swayed by ego or personal preferences. UX must stay customer-focused.

Information architecture has to do with hierarchies, structure, and taxonomies. This could be site navigation, or it could be how products are categorized in an eCommerce database. We want to make sure customers will easily find products by categories, meta data, and filters.

Interaction design, sometimes also called experience design, is what most people think of when they imagine UX. These are the wireframes and prototypes, the blueprints of designs and concepts. These would show process flows, layouts, menus, interactions, paths, choices, and so much more.

UX prototypes are like wireframes brought to life. They are clickable, interactive digital mockups. We don’t have to write code; we have software that helps us create these quickly. Companies looking for more realistic prototypes use Axure since it has conditional logic, variables, mobile swiping gestures, dragging and dropping, and all kinds of event triggers. You can prototype for just about any type of device.

UX prototyping is done to:

• Brainstorm
• Collaborate
• Iterate
• Explore solutions
• Pitch to investors (for startups)
• Test the prototype to see if the solution connects well with the target audience(s).
• Deliver an interactive model to developers or other teammates, which is often preferred over pages of documentation (and no clickable model).

Now it goes to user testing, also called usability testing, which happens during the UX process and before engineering writes a line of code. You must test concepts and designs to make sure that the idea and the execution are fantastic for target customers.

User testing will bring to light any flaws, giving UX the chance to iterate on ideas, which is inexpensive at this point since there is nothing for engineering to build or rebuild.

There are 5 key reasons UX runs tests before delivering to engineering:

1. Best use of engineering’s time and resources. If you want testing participants to see a finished product created by engineers, you have to build and test it for bugs. If UX testing brings needed changes to light, developers would have to rebuild and QA would have to re-test. If UX testing showed a larger failure of the concept, this might mean that engineering’s time was completely wasted as this is not code that will end up anywhere. The concept would have to be rethought, redesigned, and freshly tested.
2. Iterate behind the scenes. When companies just build it, just ship it, iterate on it, and build and ship again, this means that customers are seeing a variety of versions. They are seeing the work in progress and watching the sausage being made. This is often a frustrating and confusing experience requiring customers to keep relearning a system that’s evolving. It’s better to iterate behind the scenes in the UX process and to be clear with testers that it’s a prototype or demonstration version.
3. Monitoring and measuring. If a new concept is released live, UX researchers don’t have a good way to watch people use it, ask them questions, and get the type of feedback UX needs to determine if something is ready or needs another iteration. UX always wants to know the why, the qualitative, and not just the what or how many. How are users spending, converting, engaging, etc? Avoiding proper UX testing makes it harder to diagnose and fix issues or customer pain points.
4. UX testing pays for itself. UX testing is not a huge expense. Some third-party testing tools want under $100 per testing participant, some require a minimum annual commitment of thousands of dollars. These are not huge expenses given the company’s overall budget for the software development process and the importance of early testing feedback. Rounds of user testing nearly always cost less and move faster than making programmers build something we might have to undo or build again.
5. User testing solves arguments. If your company doesn’t allow UX specialists to make the final decision on how the product is designed, then you might find UX in conflict with product, engineering, or a stakeholder when there are varying ideas of what should be built and released to the customer. Or what if UX has two strong ideas and they are wondering which connects better with customers? The solution here is user testing.

UX can prototype the concepts. It’s best to boil the competition down to the best two designs, especially if you can already find compromises across ideas and team members. This means we’re not testing what UX wants vs what product likes vs what the engineering head likes vs what the scrum master thinks sounds like a good idea vs what the CEO’s life partner likes.

User testing lets the customers speak up and helps you find the right direction for the features or product. It resolves arguments by providing teams with hard quantitative and qualitative data that tells everybody which idea is likely to bring the most customer satisfaction.

It’s not user-centered design without involving the user. This means that we research and test with real or archetypal customers rather than guess, assume, or “just ship it.” We must ensure that what we “just ship” has been vetted through user testing and is an excellent execution of a great idea.

What Happens When UX Is Circumvented or Reduced?

Skype recently announced that its 2017 redesign, which aimed to make it more like Snapchat, was a failure. Users didn’t want, need, or like the new features. The backlash was large enough that Skype made a 2018 announcement that they would redesign Skype again. (https://devops.icu/skypes-coming-redesign-of-their-last-redesign/)

UX experts would have known at many steps of their process that these features were likely to be unwanted or fail. Research with target users could have quickly revealed that they didn’t want Skype to become Snapchat. Killing the project or pivoting at this early point could have saved Skype millions of dollars plus bad press and customer alienation.

Even if UX research had been bypassed, testing a UX prototype on users would have made it clear that customers didn’t want Skype going in this direction. With UX still moving through its process, engineering hasn’t written a line of code yet. This could have saved tremendous time, money, and human resources, celebrating simplicity and the work engineering didn’t have to do.

Agile UX Design Process

Remember the Agile manifesto principles. Your highest priority is customer satisfaction by building valuable software. Give (UX) workers the environment and support they need, trusting them to get the job done. Maximize the amount of work not done. Continuous attention to good design enhances agility.

Projects that are moving forward need to give UX a huge runway so that appropriate research, design, and testing can start. Do not invite UX to your kickoff meeting and surprise them with the demand that final wireframes must be delivered in a few days. That’s not UX.

Don’t look at this as Big Design Up Front (BDUF), which is a term designed to make people cringe and declare that this is something we must get away from. When a project or feature is large or new, it’s necessary for UX to cycle through most, if not all, of the user-centered design process. For UX, the smallest possible piece for a larger feature is the user’s workflow or process. If we design and test something smaller, we run the risk that we’re not getting the big picture of the true user experience.

For example, if we are designing a flow where users register and purchase, we can’t just design password selection fields and submit those to engineering. If UX worked in small pieces, when would the entire process be tested? We cannot know the user’s reaction to the entire flow without testing the entire flow… which means the entire flow must be designed before it goes to usability testing.

Where features, stories, or fixes are small, UX practitioners can do a subset of the user-centered design process and work more quickly. UX will always go as fast as they can, but a great UX specialist will do everything she can to avoid sacrificing the quality of the work being done. In the fast vs good battle, UX will always pick good over fast… and you should too.

Budgets and timelines are what blocks UX from getting fast feedback and iterating. UX practitioners always want feedback and the chance to improve the product, aiming to design what really works for customers. Bringing UX practitioners in as early as portfolio management and planning allows UX to estimate the time and budget they will need; these shouldn’t later be surprises or causes of conflict.

A UX Practitioner Is Part of the Agile Team

Embed your UX Designer in the Agile team. Invite them to release planning, stand-up, retro, and every meeting where UX might be discussed. Allow UX to estimate their time during release planning so that there are no surprises about the timing UX tasks will require. Don’t make decisions without them. If your UX teammate missed the meeting, wait until you can find them in person, over chat, email, or any method your company uses.

Assign questions, ambiguities, or bugs to your UX teammate in JIRA or whatever bug tracking system you use. Make sure the UX issues are in the same system as other issues; don’t drop UX issues in a Trello board if you are using VersionOne for everything else.

After UX has had their long runway, if it was required for this feature or product, a best practice is to have UX be 2 or more Sprints ahead of engineering. UX can sprint along with you. Get plenty of tech stories or fixing of tech debt into the backlog. That way, if UX’s creative and cyclical process runs late or requires more sprints, devs can truly be agile. Instead of waiting for UX, they can switch to some low hanging fruit that product or engineering has prioritized.

Also consider resourcing, allocation, and staffing. Depending upon the size of the project, assign no more than 3 projects to one UX designer. If you have separate, expert UX researchers, who also do testing and analysis, assign one researcher to no more than 3 UX designers. If your UX practitioner is what’s known as T-shaped, meaning she is also qualified and excellent at research, testing, and other UX sub-specialties, then make sure she is not accidentally a bottleneck by being assigned to too many projects.

Measuring Results

Without customer satisfaction, you might not have customers. You can use customer satisfaction metrics to determine how improving your processes by integrating UX has made positive changes.

• Fewer complaints
• Better app reviews
• Higher app ratings
• Fewer support tickets
• Fewer call center calls
• More positive semantics of social posts
• More app installs, fewer uninstalls
• AOV (average order value) increase
• Higher conversion rate

You can also measure desired DevOps goals such as time to market and time between fixes. How long do stories, projects, and epics take to get to market before and after your UX revolution? Developer time estimates are likely to be more accurate when they have finalized UX designs on which to base their estimates vs working from stories or whatever you’re doing now.

If UX is providing blueprints and those are being followed, we’re hoping engineering has less work by reducing surprise changes and rebuilds. Better UX design earlier, fewer fixes later.

Agile UX Design More Than Pays for Itself

Many project managers see UX as a budget line that can be removed or reduced, and hiring managers get excited at the idea of combining UX tasks with another role. However, more and more companies are learning that there is no substitute for investing in a proper UX process undertaken by trained and experienced UX specialists.

Eric Ries, author of The Lean Startup, asks, “What if we found ourselves building something that nobody wanted? In that case, what did it matter if we did it on time and on budget?” Even if your organization isn’t using the Lean methodology, the warning still holds true. DevOps’ desired results echo this when we aim to build the right thing for the customer, improve customer satisfaction, and develop features with high customer value.

Knowing your customer, involving your customer in the process, and building for their true needs and preferences is ultimately more important than timelines, budgets, frameworks, and tools. Trust that if you build the right executions of the right ideas, the revenue will be there.