Wednesday, January 18, 2017

Fast Food UX

As appealing as it is from a potential cost-saving perspective, everybody and their grandmother will tell you that UX can't be offshored. Most say it out of common sense, but common sense isn't always so common. For five years, in various capacities working with medium-sized software development houses with an offshore component, I witnessed some of the most bizarre examples of what people are calling "UX". Read on to understand my particularly intimate experience trying to commoditize what can't be commoditized.

As DevOps eclipses various delivery models, I've had to question how much the rise of UX has influenced this change in how we staff up for the delivery of software and technology services. I've seen it time and again; tech leadership hears the buzzword of UX and attempts to shoehorn a UX practice into an existing delivery model; in some cases the delivery model has a sizable offshore component. The attempt is made and begins to break down; fingers get pointed and processes are reinforced, but the focus on people and co-located teams is never addressed because it's too much to reinvent a delivery model "just for UX". After all, software is the core deliverable, right? UX is just a component, a value-add. Wrong.

But let's backtrack for a second and define (once again) what UX is. Because the perception that UX can be outsourced comes from a confusion in definition, understandably. The rise of sonic, haptic, and multi-sensory input technology, replacing what has traditionally been done through a screen-based UI, is also disrupting what was considered the makeup of a "UX team" even a year ago.

The myth of UX outsourcing comes from a validated belief that graphic design can be outsourced; that wireframes, prototypes, and other spot conceptual efforts can be outsourced; that front-end development can be outsourced; and that brand strategy, marketing, collateral design, industrial design and even behavioral research are afterthoughts to the more core endeavor of software development and the SDLC. This focus on piecemeal, rather than holistic UX sorely lacking in a research component, is what I've come to know as "#fastfoodUX". And as per the connotation, it's a cheap facsimile of its genuine counterpart, a false messiah to the mid-market consumer seeking to build Google for $15,000 and front row tickets to the Astros game. This misnomer of the term UX continues to permeate professional culture to the point where many of us, beaten and bruised by the ignorance and arrogance of the tech community, are throwing up our hands and claiming the battle for definition lost. The fact that UX covers a much broader range of activities that define "user centered" design is what trips up companies where the service offerings are far less holistic; as they focus in on their core strengths.

The jury's still out on forming a dedicated offshore UX team as a piecemeal component of a larger core service offering. But this judge says it's not possible, because UX is high-touch, user-oriented strategic thinking, and this sort of thinking is needed everywhere. Your dev shop is a UX company. Your marketing agency is a UX company. Your product design firm is a UX company.  Your research consultancy is a UX company. All of these and more are connected, and to say any one is outside of the sphere of a company's mission will leave a UX team poorly utilized. This is where the (more conceptual than physical) structure of a localized turnkey think tank becomes critical to utilizing UX effectively. And you can have that with coworking contractors, and you can do that with or without an office space as long as you're in or close to your client's time zone. It's the 12 hour turnaround time and the language/cultural issues surrounding offshore team members that is contradictory to the DevOps model, and to the high-touch nature of UX research, development and design. In my experience, not even the tightest onshore/offshore hybrid delivery process can ameliorate this issue. UX  thinking isn't expressed through concise, piecemeal directives by which offshore teams most effectively engage with their stateside counterparts. It's highly interactive, and highly conversational. UX done effectively is a real-time exercise between stakeholders, production teams, and end-users. 

But what do I know? I'm only someone who has effectively employed instant messaging, corporate social media, concept sharing platforms like InVision and other long-distance communication systems to help ease the gap between stateside and offshore teams. I'm just a guy who did everything he could to try and achieve the high-touch, agile feedback loop that was needed to attempt research-based user-centered design, not just presentation level skinning, with my own internal team and with clients. All the while I was attempting to be the singular stateside client liaison, often waiting for days to get the sort of results I needed and that clients expected. In these waiting periods, things were forgotten, things were misunderstood, and another 12 hours would go by to correct them, if we were lucky. The most miserable realization for me, however, was that budgeted effort estimates would always be too tight for the bar I had set for quality. That the expectation of cost-savings that an offshore model offered was "cramping our style". I inevitably had to come back at a stateside rate to get the projects back on track, and therein I would be slammed for dedicating more time, effort and energy than we had budgeted for the client.

UX as a per-capita expense is higher than that of development.  "Cross-functional" and "co-located". These are two terms that are an anti-pattern to siloed software development. And yet they are two of the most important aspects of successful UX delivery. A proper UX team exists in a collaborative culture with the tools they need to do their job. Ideally, researchers and designers are bouncing ideas off of each other in an open collaboration space, even if virtual, at least in the same time-zone. At the heart of their conversation is the product experience, from entry to exit. They whiteboard, they test with end-users, they communicate fluidly between each other and in reasonable transparency with the client. After the conceptual efforts are complete, a UX lead ideally remains present through the development process to oversee the nuances of design that are being executed on the presentation layer by front-end developers.

Tech companies trying to incorporate UX into their offerings sometimes can't get past this initial hurdle. Though it may seem like common sense, to keenly identify the value proposition of design culture as it relates to technology solutions offerings, and thereafter build a model to justify this expense, is rare. In my experience wrangling together a UX team, I've found that the visual designer's hardware needs, specifically, require higher quality screens and more hard disk space for files; this is in turn spilling over into development space as we share these files among each other. I've tried almost all the cloud-based file sharing software worth considering and we've settled on Dropbox as the most robust for cross-platform sharing. That issue resolved, there was the issue of screen quality; designers require high pixel-density monitors, preferably running dual monitor systems. And finally, third party software tools that are Mac-only make handling a PC-based offshore team that much more challenging as we must keep up to date with an evolving design toolset. A huge reliance on Adobe's cross-platform Creative Suite had us at a disadvantage to localized teams who, though more demanding in their initial hardware and software costs, are now producing scalable, vector design work in Sketch.

*SIGH*. I've seen components of UX outsourced successfully, but never this whole that I speak of. But you motherf**king cheap-asses will keep trying. There are the Fiverrs and Elance/Upworks of the world, daily encroaching on the value proposition of the design agency and its overhead; the software development house and its overhead, the industrial design firm and its overhead. In these models, "UX" design is commoditized successfully because client requirements are simple and devoid of a need for serious, holistic strategy. Clients who are seeking a logo or homepage layout from such entities don't fully understand the value of branding, of information architecture and wireframing, of product design, and even if they did, wouldn't have the budget to pursue the effort to materialize an effective strategy for any of it; i.e., the stuff that's hard; the hallmark of a professional organization's individuality and caliber. From a marketing perspective, cutting through the noise in a world that has twice as many people as when I was growing up is hard. From a software UX perspective, developing a digital solution with a presentation layer UI that is usable out of the gate, is hard. From an industrial design position, the sheer effort of meeting form with function in a hardware product is hard. All of these, additionally, are exercises covering several disciplines and skills in the fields of brand storytelling, visual design, psychology and software/hardware development consistently.

So did scruffy, hipster designers influence the DevOps revolution? It may never be admitted by the software engineering community, doomed to rot away in the annals of conspiracy theories along with the faking of the moon landing and the JFK assassination. Regardless, technology clients will inevitably come to solutions firms with needs that cross the spheres of marketing and branding, software development, and possibly even industrial design if there is a hardware component to their vision, such as a wearable device or an IoT project. At this time, very few firms are poised to call themselves a "partner" to such clients, with leadership lacking the holisticism to be truly turnkey. Those that are will embrace this "singularity"; this convergence of disciplines. They will have stateside DevOps teams working with a UX component that exists from concept to finish and beyond in the product development lifecycle.

No comments:

Post a Comment