Tag: Agile Ethos

When we run our quantitative analysis, and find that at least 59% of users mention a particular issue, we assume that solving it should increase customer happiness. But if you’ve ever been in such a position before, you’re likely shaking in your boots. Because you know the truth. Sometimes, you can fix a problem most users have with your product, only to find out that your users have gotten even angrier.

Let me tell you about such a user, a healthcare professional running multiple clinics, who depends on multiple software products from different vendors throughout their workflows to meet patient needs. Working in healthcare, speed of reporting is key. For someone who walks into that clinic, the time it takes for a report to make its way to their family doctor can mean the difference between life-saving surgery and dropping dead in front of their family members. That is no exaggeration: my client has worked with patients in their 20s who were in immediate danger of cardiac arrest; has seen patients almost pass out during a test because their heart couldn’t pump enough oxygen to their brains; even has infants with congenial disorders come into the clinic, held by parents who can barely stand to let go of their child for the duration of a test. Any changes to established workflows risk used by my client and her employees, risks slowing down those reports, which has a tangible impact on the lives of the kinds of people who walk into that clinic; which is to say, people like you and I, not to mention any of our loved ones.

This is why change in healthcare technologies, as with most high risk industries subject to public sector regulations, is so slow. Changes in these industries are under a great deal of scrutiny to prevent optimal catastrophic outcomes for the public. At the same time, this rigor often comes with a high cost of production, and proportionally high costs for the consumer; with means that most of the hardware/software technology used by public sector organizations can be woefully out of date and inefficient, both from a technical and usability standpoint.

So when one of the software vendors my client works with asked for feedback that would make their work easier, my client was happy to oblige them. Emails were exchanged, questions answered, and details solicited, until the vendor felt like they had a grasp on the problems my client was facing, and my client felt like their concerns were being given due attention.

Cut to the next software update, and not only was the problem fixed, they came packaged with a number of other quality of life changes, from auto-filled form data to customizable shortcuts to most used pages (I assure you, these are all very exciting, innovative, and cutting edge features for public sector software). However, when my client actually started using the update, they found that that their efficiency actually went down. Reporting was slowing, data entry more error prone, and case transfers experienced more delays.

To recap. Users cited an issue. Software developers fixed that issue perfectly. Fixing the issue created a worse user experience.Agile is a tricksy beast. The ethos of ‘Move Fast, Break Things’ is so fundamentally baked into the bones of the methodology that it can sometimes feel like the only reason your software is still running is because your team has unknowingly tapped into some ancient witch-craft and invoked into a new fundamental force of reality into existence just to hold the damn thing together. But that is more or less the point. A shoddy product on the market now is worth far more than the perfect product shipped too late to matter. That is, Agile gained popularity during a time when the tech market was new and shiny, a frontier of untapped potential ripe for colonizing. Agile was for a time when companies were rushing to set the standard for what a piece of software should do, because there was no standard yet.

Agile is a tricksy beast. The ethos of ‘Move Fast, Break Things’ is so fundamentally baked into the bones of the methodology that it can sometimes feel like the only reason your software is still running is because your team has unknowingly tapped into some ancient witch-craft and invoked into a new fundamental force of reality into existence just to hold the damn thing together. But that is more or less the point. A shoddy product on the market now is worth far more than the perfect product shipped too late to matter. That is, Agile gained popularity during a time when the tech market was new and shiny, a frontier of untapped potential ripe for colonizing. Agile was for a time when companies were rushing to set the standard for what a piece of software should do, because there was no standard yet.

Being first doesn’t necessarily require you to have a great product; so as long at you have something people with buy, it doesn’t matter how many shortcuts you had to take to get there. You can, hypothetically ignore standards and regulation, and put off planning for long-term maintenance and expansion in favor of saving time; because if you succeed, you can always fix those issues later; and if you fail, well, you won’t need to fix them. A technical debt you would be lucky to be able to pay off later. And when it works, it really works. Companies have grown fat off of the rewards of Agile, and fatter still off of the rewards of selling Agile methodologies to startups, universities, technology consultants, and project managers.

However, those heady days at the bleeding edge of a new world to exploit are far behind us now, no matter what cryptobros think. We exist in a market where users know what to expect from their software platforms, and they can tell the difference between a rushed product and a well made one, because they have to use it everyday. And developers know that later can’t be when you fix the bugs because later is when you should be working on new features to keep yourself ahead of the competition. The cracks were always there, but for some organizations, it took a lot for them to realize their time was up. Like having their lead engineer pull the CTO aside in the break room to explain that pulling a few folks off feature dev to refactor the Jenga tower of a code base just might prevent leadership from having to commit seppuku on the ping pong table to appease stakeholders a month from now.

So, to be competitive now, it is not enough to make something first, you also have to make it better than the 500 other startups already on the job. And that requires both long-term thinking, and short-term execution. Technical debt is a liability, one that must be managed with care and discretion, especially when you’re working on legacy software that started building up a tab decades ago; because it’s come time to pay up and you’re the one holding the buck.So accruing technical debt on purpose has mostly gone out of fashion. In a stunning show of self-preservation for a deeply anti-union industry, professionals in academia and industry collectively developed standards for software readability, white box testing, and reusability; and those of us who have had to parse convoluted and undocumented code thank them for their service to humanity. As the demand for more sophisticated software increased, so did the demand for more specialized skill to meet that demand. While everyone buys into the allure of being a full-stack engineer, there aren’t enough hours in the day to be competent at both. Specialization is the name of the game, and if we further discriminate between the human interaction element and the technical developmental element of a product’s user facing interface, we can evaluate what UX researchers and designers bring to the table.

So accruing technical debt on purpose has mostly gone out of fashion. In a stunning show of self-preservation for a deeply anti-union industry, professionals in academia and industry collectively developed standards for software readability, white box testing, and reusability; and those of us who have had to parse convoluted and undocumented code thank them for their service to humanity. As the demand for more sophisticated software increased, so did the demand for more specialized skill to meet that demand. While everyone buys into the allure of being a full-stack engineer, there aren’t enough hours in the day to be competent at both. Specialization is the name of the game, and if we further discriminate between the human interaction element and the technical developmental element of a product’s user facing interface, we can evaluate what UX researchers and designers bring to the table.

Bridging the gap between project management and front-end design, user experience designers bring with them an ability to identify abstract customer goals though research, and determine the optimal features and interaction journeys that would allow a user to achieve those goals, with respect to the user’s mental models and context of use, as well as the resources and incentives of their company. This ostensibly allows front-end engineers to offload the work of determining how the actually visible part of the eldritch horror the company sells serves or hinders a customer’s goals (and by extension, the company’s revenue), and instead lets them focus on figuring out why a double finger swipe inexplicably crashes the app. Simultaneously, project managers can let their UXers deal with all those emotions the customer has when it comes to the product, so that they can focus on keeping the fire extinguisher aimed at the pyromaniacs on their team.

In an ideal world, UX professionals reduce the technical debt on the project; by using a dedicated specialist to identify what customers want, what competitors offer, what their devs are able to make, and what the business needs from the project, the ideal UXer can prioritize a feature list and brand experience that keeps the product ahead of the competition at launch and into the future, while keeping the most abrasive members of their development team as far away from the customer as possible.

If you’re ever seen the picture of cats playing twister at the food bowl, you’ve gotten a fairly representative sense of how developers feel about users. What said comedy geniuses miss is that the choice to contort themselves makes perfect sense to the users in question; the problem is figuring out why. Knowing that is pivotal to determining what the best possible shape a new product or feature need to take to stand out to a user.

But while UXers specialize in the work they offload from their team, they also inherit a difficult responsibility; specifically a responsibility to justify their recommendations to a leadership that is most familiar with developers, project managers, and business analysts working in Agile. To communicate effectively under such circumstances, UXers have to leverage the language and structures used by established professional roles to gain support. Which brings us to an important problem; your numbers are right, but how you communicate them can point in the exact wrong direction.

Let’s return to our client for a second. Their software vendor solicited feedback on pain points from their users. The vendor did their job perfectly, fixing the issues as described by their users. What happened here was not related to any issues with communication or the quality of the work. The issue was a fundamental lack of understanding around how the user thinks and what the use the software for. In this case, the vendor had neglected to consider the unique pathways users create to streamline their tasks, which can sometimes be the result of interacting with the system in ways not expected, intended, or anticipated by the creators. In media studies circles, this is referred to as cocreation, i.e., the function and use of digital software is the result of an iterative process of cocreation and friction between the users and the developers. In gaming circles, this concept has been taken to its most extreme conclusion through the madness that is known as speed-running.

Here, the client had created a number of workarounds to the adapt the software to their needs. When the vendor aggregated the pain points from feedback their users, and unilaterally solved the most prevalent issues on the list without considering the context in which users interacted with the relevant systems, they invalidated the adaptations that were necessary for the large system to function.

I have no doubt that, somewhere, there is a number listed on a slideshow saying “Percentage of users cited issue x” that is the cause of all this heartbreak. Someone on the team, understanding the value of reaching for low-hanging fruit, then gave the go-ahead to solve the problem, and some poor soul on the dev-team spend a few days tracing undocumented lines of code to figure out a patch for the issue. Meanwhile, their clients would much rather they had never asked for feedback in the first place.

Quantitative metrics are all well and good. They provide valuable information about the dominant needs and pain points of a large subset of your customer base, and a well designed quantitative study can overcome a number of tripping hazards that might prevent project success. Crowds of users can point the way towards a large issue that needs solving, while providing built-in justification to persuade leadership in a way they understand. You may therefore have had your own experiences slicing your user demographics in unique ways to figure out how to get leadership to fix a problem that you know really needs to be fixed.

I myself once spent three hours crawling through interview study transcripts because my supervisor wanted a ‘percentage of users mentioned this issue’ metric on a slideshow. Reading that, you might say, ‘That’s on you – slot it in Chat’ But you would be missing the point. Let me rephrase: I went through three hours worth of qualitative research transcripts, so that I could count how many times something was mentioned for a quantitative metric we could plop on a slide. We were trying to turn an apple into an orange.

Users may have noticed an issue from their point of view, but what they saw, and what the developers saw were very different things. Each group was considering the same problem from a completely different perspective, because their understanding of, and relationship with the system being evaluated was completely different. When it comes to understanding user needs, your job is not only to identify the major needs and pain points of your customers, but also to interpret them. No amount of quantitative research metrics are going to substitute for a researcher sitting down with a customer and taking a serious interest in their experience.

Reducing those individual experiences, rich in information about cognitive processes, human adaptations, counterintuitive inherited systems, and random chance, to a counter indicating how many people said the same thing is only going to lead your team to poor product updates, unhappy customers, and a whole lot of pointless busy work.

If the vendor had taken the time, as I had, to sit down with my client one-on-one, to see where and how their employees were using the software to meet their unique needs, developed due to real world constraints, they would have seen the workflow adaptations at play and might have been in a better place to produce a solution.

So, now we know that an overdependence on quantitative metrics can impact customer satisfaction and product success. But how do we identify when such an overdependence is occurring in our team?

First we must understand ‘why’? It’s all about incentives. Just as a user may develop ways around your software’s intended flows to meet their myriad needs, so does your UX team create pathways around obstacles to meet their goals. We’ve already discussed one such obstacle; namely, the language barrier between the organization’s experience of the product, and the user’s experience of the product.

Your leadership may respond better to solid statistics pointing clearly towards simple solutions (and let’s be honest, who doesn’t respond well to clear cut solutions). However, your customers don’t experience the product in clear cut, simple ways, nor do they conceptualize their usage as quantitative metrics. If every meeting is filled percentages and statistics that are meant to represent your customers’ experiences, then it is likely that your UX team is prioritizing the feedback that can be communicated as clean solid statistics; and deprioritizing solutions that would have the highest impact at the lowest costs, but which would require more effort to communicate.

If your organization is highly risk-averse and responds poorly to low-cost pivots and iterative design (again, show me a team that embraces high risk situations or work that feels redundant), then it is likely that your UX is prioritizing low-handing fruit and easy successes that will cost the company in the long run.

If your company culture prioritizes software engineering methodologies and the Agile ethos as company-wide standard and shared language, then it is likely that your UX team is leaning into the same language and ethos to meet your expectations, at the cost of your business.

Overall, if your UX team feeds you more success stories than notes on where a particular hunch or prototype failed, then someone or something is keeping them from doing their job.

If any of the above are true for you, congratulations, your UX team has been increasing your technical debt for as long as they’ve worked for you. None of these are necessarily your team’s fault; again, the problem is about incentives. What behavior is being rewarded through your leadership’s attention, and what methods gain less traction in cross-functional meetings. Understanding process, context, and the larger systems within which your teams are working are the key to realigning your business with your customer; and there are a number of ways to get there.

The first and most important thing you can do is to gain a better understanding of what a good UX team can do for your organization.

There is a mindset shift at play here. You aren’t paying your UX professionals to design a product to put in a user’s hands. You are paying them to fail to design the product, repeatedly and frequently, so that your actual product doesn’t fail when it counts.

No matter what the situation, whether it is a 0-1 product design, a feature evaluation, a pain point investigation, or a redesign of an existing product, 10 pen-and-paper prototypes tested with a few users, are cheaper and far more valuable to your business than 1 easy to approve but poorly received software update. Quantitative research provides a direction for investigation, qualitative research provides an avenue for deeper exploration, and prototyping allows you to get every failure you might have had in a launched product, out of the way before your developers ever put fingers to keys.

In short, if your UXers aren’t spending their time in the breakroom bemoaning the number of prototypes they’ve had to toss out or how they’re running out of pen and paper for lo-fi mockups, they’re not doing their job.

Speaking directly to UX professionals, the best way for you to make an impact is to develop a robust sense of the entire project, beyond just the research and design phase. Understanding the costs and impacts of individual decisions on the overall business is the kind of advice often given to employees looking to move up in their career, but it is the bare minimum for a UXers. The changes you suggest need to bring additional value to an organization, starting with mitigating future costs caused by poor product experiences and technical debt.

Gaining some familiarity with the software architecture of the product is invaluable, especially when combined with your understanding of interaction flows; track how your suggests may cause cascading changes to the software architecture, impacting overall costs. Work with project managers to understand your timelines and budgets can only serve to help you better prioritize your solutions. Identifying feasibility is your responsibility.

Ultimately, communicating your solutions in terms of value, impact, and costs is the priority. When you look for metrics to support your recommendations, those three should be the metrics your prioritize. But those metrics are a means to an end; the ends being your recommendations, rooted in your expertise and skills labor, and the work you have done to understand your users. The cost is too high not to take your work as seriously as it deserves.