XXV.4 July - August 2018
Page: 21
Digital Citation

The dynamic of artifacts and outcomes

Uday Gajendar

back to top 

How many of you have heard or lived this: The product manager of the app for which you’re serving as the UX lead types out a 10-page requirements doc. You read through it and realize there are some critical dependencies that correlate to the assumed user’s “day in the life” usage patterns. You wonder, Is there a way to expose them and get clarity among the team? So you excitedly suggest creating a diagram of the user’s activities and running a team work session to get folks to discuss it in real time. The PM balks, saying (a bit huffily) that it’s time-wasting, repetitive work. After all, they already wrote it all down—it’s in the Word doc! And besides, there are assets to ship this week to meet the delivery schedule. Sigh.


Amid the hazy rush of agile and lean, there’s a strong movement away from documentation and artifacts (or, in some cases, a manageable process at all—but that’s a whole other issue). Move fast, iterate faster, and strive for rapid experimentation for quick validation. This seems to all be done in the zealous pursuit of velocity—gotta get that “say-do” ratio up, so we have a strong sprint, right? Well, stepping back a bit from the madness, it’s good to ask: Is there a place for artifacts borne of our HCI-guided practice amid hightech product development in 2018? And if so, how do we tie them back to the business drivers, or projected outcomes? Not to get too heavy, but these crucial questions lie at the heart of our role and indeed even the existential value we project for any team setting.

To clarify, in this article by artifact I mean any human-made construction as part of the standard design process, from a napkin sketch to a journey map to a persona to a task-analysis diagram—and, of course, detailed UI specs provided to engineers. So, I am not referring to artifacts found per ethnographic-style discovery processes, although those are quite important in helping teams understand contexts and purposes. I presume we (coming from HCI-guided education) know that making is a vital form of research. That activity, whether quickly sketching on the whiteboard or laying out a schematic of the content architecture, helps us investigate the fundamental paradox of any design situation: Understanding a problem necessitates making suggestive solutions (which are lightly held hypotheses), which then lead us deeper into the problem space, uncovering new considerations or constraints, and so forth. It’s a bit of a vicious cycle but necessary and simply inherent to designing. That’s a big part of the fun, right?

Amid the hazy rush of agile and lean, there’s a strong movement away from documentation and artifacts.

Such design-based artifacts should lead us to valuable outcomes or impacts, as this shapes our overall value, our operating imperative within a cross-functional model of collaboration with engineering, sales/marketing, and product management. What are those impacts? Currently in our quantified data lifestyle, it’s mostly numbers that have the most tangible utility—and our non-HCI-oriented peers mostly love numbers! More to the point, certain key business metrics are meaningful signals of business progress, such as increasing total payment volume (TPV), hitting market-growth targets (e.g., doubling from 10 percent to 20 percent market share against competitors), elevating trendlines (moving them up and to the right!) around adoptions, activations, and sales, or reaching specific user-engagement numbers for retention. Or it can be Net Promoter Score (NPS), customer-satisfaction ratings, improved brand perception, or simply app-store ratings. Regardless of measurement, it’s something specific, concrete, and mathematically calculable for the sake of causal correlations and perceived predictability.

As UX leaders and designers, we serve with pragmatic intent and idealistic aims, toward improving the human condition. Moreover, we must also demonstrate it sufficiently via ample tangible evidence along the way, on that journey toward releasing a product or feature with confidence to the market with real measurable outcomes, to justify further UX investment.

I remember on my first day at a local startup, the chief product officer (CPO) led me to a whiteboard in a bare conference room, where he jotted out a simple ratio: “DAU/MAU” or “daily active users over monthly active users”—their core metric of user retention that they report to the board, featuring rather prominent investors, every quarter. He pointed at it and said tersely, “We just need this to go up—I don’t care how you do it with your design expertise, but they should connect.” Got it. Challenge humbly accepted. For me to improve that metric, I must create things along the way to peel back the layers of assumptions, dependencies, and constraints to really help me dig into the essence of manifesting that critical ratio for the board.

Perhaps the reaction against design artifacts is based upon flawed perceptions of taking too much time, redundant steps, repetitive documents or formats, and maybe general feelings of simply going through a prescribed checklist—especially for client-agency arrangements where keeping labor and materials costs down and time-to-market efficiency up are the top priorities. This is certainly true for startups, furiously working against running out of money!

But we know, as practitioners in our field, that making such artifacts is no mindless checklist, mechanically followed in tedium (unless your job environment is boring, but that’s another topic!). Such artifacts provide tremendous value along the journey of achieving stated business goals. They in effect become tools for analysis and synthesis across stakeholders, aiding the team’s quest to master the problem space with relevant, novel solutions.


Here are other ways in which artifacts are essential in helping the cross-functional team strive toward resolving problems with potential solutions:

  • They help center and focus attention on what’s really important, presented in a way that prioritizes concerns and questions (via the power of visual design and content strategy). They are not simply a long-winded slide deck or inscrutable spreadsheet!
  • They ground and anchor high-stakes dialogues on something that makes real the various abstractions floating in everyone’s heads—artifacts give everyone something to point to, react to, defend, and argue with.
  • They help (re)frame or challenge assumptions by presenting information in a way that shifts and even elevates a conventional point of view (e.g., from a 25-page document into a timeline journey of the steps and pitfalls a user encounters) to enable those breakthrough aha! moments. The power of pictures showing how actual dots are connected—that is a revolutionary, eye-opening moment for many people!
  • They embody disposability—they are not precious at all, and indeed should be presented as such, with a wanton willingness to mark up, fold, and tear. Indeed, I often take the first step of doing such defacement to my own diagrams in front of shocked engineers and PMs—it gets quite a reaction! But the point here is to role model productive behavior so as to give them permission, to say via your actions that it’s OK to react and iterate upon them. That’s the whole point, to move us together toward mutual understanding and perhaps spark some innovative ideas.

Plus, when you have a series of artifacts over the life of a project, you have in effect created a living record of the manifestations or communal interpretations of the problem, from multiple, disparate yet connected angles, so as to yield effective decisions that will purposefully lead the team toward desired outcomes—like that infamous DAU/MAU ratio.

Artifacts become tools for analysis and synthesis across stakeholders, aiding the team’s quest to master the problem space.

The power of the artifact is therefore the “thing itself”—guiding crucial conversations and thus shaping relationships among folks who otherwise maybe never thought about a particular use case in such a way thanks to the power of the visualization, as posters or prototypes, revealing latent layers of potential. Whether it’s bridging perspectives or enhancing divides, artifacts serve a potent role. Gotta get all that stuff out in the open, driven by the thing, this artifact, not fickle personalities or silo-driven attitudes. Also, such artifacts serve to invigorate or boost a moment in the development process, inspiring energetic engagement with problems, opportunities, and goals. Because, let’s face it, often the overall project tenor can go stale as folks churn on the same content, treading water but not making forward progress. Picking apart a prototype reenergizes dialogues that may have faded through routine office doldrums. We can transform the meh to aha!

This points us to the vital dynamic of continuous conversation, understanding, and disagreement, and even further understanding, leading us all toward commitments with confidence. Then everyone feels they are part of a truly participatory process, not blindly, separately speeding toward arbitrary deadlines for velocity’s sake. Discussions, interrogations, revelations—these are at the heart of strong collaborations, bringing to the fore good thinking and decisions by virtue of interacting with artifacts such as journey maps or paper prototypes. And, of course, sparking the fames for inspired connections and new ideas. What good is breaking the speed barrier if you’re going to crash and burst into flames, with charred ruins sprinkled everywhere? Pyrrhic victories have no place in collaborative iterative team engagements!

Now, about those outcomes… Key business metrics are highly important, and smart, effective teams keep their business drivers constantly in view. Even literally so, as giant posters or banners on the walls! Or simply written on the whiteboard in persistent view of everyone involved. Those business outcomes often span multiple levels of impact, beyond raw numerics toward procedural or cultural progress:

  • Market- or industry-level change: launching a new technology or product category to redefine the baseline, to inspire whole new paradigms of behavior
  • Company-level impact: improved cross-functional partnerships that break down silos and reduce dependencies across departments, with improved routines
  • Product-level impact: reducing complexity and smoothing out workflows with refreshed interfaces
  • User-level impact: creating delightful moments of gratitude and satisfaction in their daily lives.

Can a single artifact really lead to a specific impact? I honestly don’t know if it’s possible to draw a clear line at such a microscopic level. There’s great interdependency among various decisions and considerations in any high-tech product-development situation. Instead, I see such artifacts as essential signposts along the road to achieving those outcomes—as checkpoints, as moments of debate and reflection. They keep us honest by forcing us to ask, “Is this moving us toward or away from our intended outcomes? In what ways is this artifact working or not working? What can be improved and how so?” The intent is to maintain momentum with both rigor and disposability. More than any specific outcomes or measures, it’s about ensuring that our narrative, our story of the brand, the feature, or the product itself, is strong, credible, and viable. Every story is rooted in a desire for some kind of positive change that is surfaced via the artifacts we make. The constant fluid dynamics of dialogues is key—is this moving us closer to achieving X, however we may choose to define X (and there may be multiple X’s)? It’s our charge to keep making our way forward and engaging teams to join us on the journey to real impacts. Therein lies our role and value as UX design leaders.

back to top  Author

Uday Gajendar ( has been a prolific UX designer and leader for more than 15 years, shipping designs for PayPal, Facebook, Citrix, Adobe, and others. He also enjoys coaching startups on UX fundamentals.

back to top 

Copyright held by author

The Digital Library is published by the Association for Computing Machinery. Copyright © 2018 ACM, Inc.

Post Comment

No Comments Found