Select a category

Brandon Ward 6/4/21 Brandon Ward 6/4/21

Delivering Quality Experiences

Effective UX has to walk the line between fresh and novel, and usable. Novel is interesting initially, but usable has to be useful when the shimmer has worn off. We strive to achieve both of those valuable experiences.

1. The Basic Design Process

The Brief

We've all seen the cliché memes even if we haven't experienced them ourselves:

Make the logo bigger! Make it pop! Add more sizzle! Make it fresh! Wow me!

And, honestly, we've also seen some sites that do just that, some even do it well. Everything from auto-playing music and sound effects, to parallax, animated gradients, interactive video, even websites that are almost full-blown video games in their own right.

It can feel as if every call with the client begins in a similar vein.

"We're building <APP> for <VERTICAL>. It's like <OTHER APP>, but ours will be different because <POP/SIZZLE/GAMIFICATION>."

We nod our heads. "It'll have dynamic, user-content-driven dashboards!" Yep. "And we want it to work on mobile and tablets." Absolutely. "It'd be cool if we could have some ML and AR involved there too, but we're not sure how yet. We're hoping you can help us figure that part out." Nothing new here. You want it to be accessible too right? “Oh yeah, accessibility! If we have time left, do that!” <sigh>

Research

You do your research. You talk to the stakeholders. You ask hundreds of questions of your client's customers. You unravel the knot of unknowns, and patterns of user behavior emerge. You begin to understand what the business actually needs, and what the users actually need. You rough out an IA and test it. You see the pitfalls in the current journey. You identify inefficiencies and problems, er, opportunities across the service layers. You present your findings. "Yes! You get it!" the client says. We're all on the same page. You understand the problem, and you begin solving it.

UX Design

You wireframe. You prototype. You assure the client that, no, these aren't the actual colors. No, that's not English it's called Greeked text. “Why does it look like Latin if it's called Greeked text? Why don't the numbers in those columns add up?” So you replace all the lorem ipsum with real-ish copy and adjust the numbers to make a little sense. Okay, now they get it. No, that's likely not the font you'll use, we're just trying to get a sense of how things work first. Visual design will come later. Okay, they get it. Sort of. So, you begin testing.

Testing

Testing goes great. You uncover some problems with the IA. No biggie, super-easy change. You see some small issues with some labels, so you wordsmith those. There are a couple of show-stoppers that make you feel stupid. How did you not see that before!? But you see it now, and you've already got 2 or 3 ideas for how to solve that. Things are smokin! You report your results. It tested through the roof, and you're very confident users will experience very little friction. They'll be able to easily grasp the tasks with no supervision. You've organized things with clear paths. Sequential work is laid out so it's obvious what came before, what they're doing now, and what comes next. The client begins to see how amazing this new vision is. So you move on to visuals.

Visual UI Design

The visual designers kill it. Maybe it's another team. Maybe it's you. Maybe it's Maybelline. They've transformed your usable, utilitarian, efficiency-driven low-fi wires into gorgeous, pixel-perfect renderings of the final vision.

And here's where things can get dicey.

2. The Road To Destruction

Make it Pop!

"I like it..." says the HiPPO. "...but I don't love it." This is nothing new. We're designers, and this is the path we've chosen. Okay, that's fair. What don't you love about it?

"Oh, I don't know. It just doesn't pop/wow/sizzle/whatever. Have you been to <THAT HOT VIDEO GAMESITE>? They've got lasers, and real-time AR video that places you right in the middle of the screen and when you move your mouse around your little guy runs after it! And when you scroll, it scrolls horizontally, not vertically, which gives it a panoramic feeling! It's really cool!"

Everyone is forcing smiles and nodding...

"I know our accounting platform isn't a video game, but why can't we do something cool like make the avatars move around, or use their webcams to show a real-time view of their face so they don't have to upload a photo? What if when they scrolled, the data grid used that cool parallax motion so the columns moved underneath one another like those cool Miyazaki films? Anyway, all our competitors scroll vertically...what if we laid all our stuff out horizontally? It'd really set us apart!"

Okay - so I may be exaggerating some client requests and expectations, but honestly, not by very much.

Note: I don’t hate Lingscars.com for a number of reasons. Perhaps that’s another article.

Also, I’m not talking about getting the right feedback at the right time. That’s a different issue, nicely addressed in this article by James Cook.

3. The Path To Quality

The Truth

It’s times like these my boss Tim is wont to say

“Effective UX has to walk the line between fresh and novel, and usable. Novel is interesting initially, but usable has to be useful when the shimmer has worn off. We strive to achieve both of those valuable experiences.”

— Tim Doll

The first thing about introducing anything "fresh and novel" is that you've created your own usability debt. By its very nature, the user is being introduced to something they may not be familiar with and will have to discover and learn. If this is a game, or a marketing site, maybe that's a great thing. If it's accounting software, it's not. In fact, in most (if not all) cases I'd argue introducing your own obstacles to clarity and efficiency, not managing to your user base's existing mental models is bad. It’s like tying your own shoelaces together then trying to sprint.

Remember Stephen Anderson's hierarchy of UX?

Concept and design by Stephen P. Anderson

We assume the app will be built to function reliably. Our job is to make it first usable and convenient. Only when we've established that base platform can we even begin to explore pleasure and meaning. If you try to design for uniqueness and stand-out visuals prematurely, you'll compromise your own foundation that your research and design teams spent so much time and effort establishing.

Does this mean we don't try to cross the chasm of convenience and push our apps into the pleasure zone? No. In fact, apps like Word and Excel could really use a healthy dose of pleasure and meaning, and dare I say convenience as well. But managing design and experience at this level gets exponentially harder. Your baseline reliable functionality that's relatively usable is table-steaks. It absolutely has to do that or nobody will use it at all. But if you don't even try to shoot for some novelty, some fresh expression, they may use it a bit, but have no desire to come back. This is one of the biggest problems with MVPs (minimum VIABLE products). When was the last time you really enjoyed an experience or app or site and said to yourself, "Wow, that was a really viable experience!"?

The Product Roadmap

This is why we choose to design and build Minimum VALUABLE Products (I'd also have accepted Minimum Lovable Products). Because MVP is so common though, we don't even use that acronym. We use Cupcake, Birthday Cake, and Wedding Cake.

Cupcake (your minimum valuable product) is what absolutely must ship, otherwise, there's no point. It's important to note here that Cupcake isn't a horizontal cut of the hierarchy though, sacrificing convenience, pleasure, and meaning for a baseline product that merely satisfies at an intellectual level. No, Cupcake products cut vertically up the pyramid, capturing a bit from every layer.

The cake analogy is so powerful, because at their core, all three types of cake are the same. You've got flour, eggs, sugar, cocoa, icing, maybe even a creamy filling and a topper. A bite of a cupcake and a wedding cake are essentially the same experience, just in a less substantial form.

Cupcake offers a compelling experience
Birthday Cake enhances that experience
Wedding Cake is the full realization of the product vision

Cupcake encompasses the things you KNOW you must deliver to provide real value.

Once that core value is delivered, you can begin on some Birthday Cake revisions, adding additional features, functions, dare I say, even sizzle, insomuch as they enhance the core experience of your app. You scale. You are able to handle more clients. But when you're building Cupcake, as much as you want that slick new feature or novel AR avatar experience, you have to justify that it's part of the core foundational experience and nobody would bother with your app without it, or, if it's an enhancement that can build onto the base in a fast-follow release (Birthday Cake). Wedding cakes are the "big show" of cakes.

Wedding Cake is what you envision your product to be two to five years from now, with all the bells and whistles that make Wedding Cakes so much more substantial than your humble cupcake. But all the while, you're really providing the core value in your initial cupcake offering, and getting hung up on fresh trends and unique, fun, and sizzling design can detract, and more often, even degrade, even break your core experience.

Have Your Cake & Eat It Too

To wit:

The Basic Design Process
- The Brief—Effective planning and setting expectations
- Research—Discover insights into the problems you’re solving
- UX Design—Design like you know you’re right
- Testing—Test like you know you’re wrong
- Visual UI Design—Enhance the experience with brand guides and style
The Road To Destruction
- Make it Pop!—Here be monsters
The Path To Quality
- The Truth—Keep it real, make sure you stay focused on what matters
- The Product Roadmap—Cupcakes! Delicious, moist cupcakes!

Let's seek to build Cupcakes that span the layer-cake hierarchy from functional, to reliable, to usable, past the chasm of convenience, even to pleasure and meaning.

Once we've designed the thing the users actually need that supports the business' goals, don't let sparkle get in the way of delivering a great, valuable product.

Brandon Ward 4/20/21 Brandon Ward 4/20/21

Define Success to Achieve It

The contract said the product required an "Audit log." That was it. The web app for a major hospital chain with 35,000 users wanted an audit log, and we were under contractual obligation to deliver one. Whatever "audit log" meant.

When I say audit log, what jumps to mind? Is it:

A log of CRUD (create, read, update, destroy) activities for key parts of the system?
Is it a log of every change event system-wide?
What does this log data capture? Who? What? When? Okay, what about deltas? What about related or effectual changes?
How often is this data written?
Who has access to it?
How is it accessed?
Is it just a database, or is there a UI?
If there's a UI, what kind of visuals are there?
Is it searchable? Filterable?
What is the point of the audit log? Is it for security? Audits? Paranoia? Legal compliance?
When someone is viewing the audit log, what are their goals? Why are they there? What are they looking for?
Is there any reporting? Are there rule sets that trigger flags or alarms? Where are those managed? Who manages them, and how?

I'm sure if I asked all of you, I could triple the length of these questions. These are just the core, fundamental questions one would ask regarding a feature like this. Well, these are the questions one SHOULD have asked regarding a feature like this before promising to deliver it.

The budget was gone, time was up, and everyone was frustrated

When the day finally came to tackle these and so many more questions about the audit log, the budget was gone, time was up, and everyone was frustrated with the project. You see, this was only one of the hundreds of features that had been called out in bulleted lists in the contract without any real definitions, requirements, or criteria. Because nothing was clearly defined, every single task was a meeting requiring several hours of conversation between clients, project managers, scrum masters, designers, and developers. Everyone had their own interpretation of what each feature meant, and nothing was written down. Even when there were mockups to demonstrate how a particular feature might function, due to a lack of requirements regarding integration with other parts of the system, even fully-built "done" features were constantly tossed, re-written, broken, updated, and on and on.

The audit log would be one of the worst offenders. This project (that we inherited from another company and team) would take more than double the original budget, and 9 months longer to ship than originally "planned" (obviously, planning wasn't part of the setup process for this project). Even when it shipped, it lacked significant functionality the client had hoped for. Everyone was sad, tired, and spent.

This is a story about setting yourself up for success (or failure)

This is a story about setting yourself up for success (or failure). The good news is it's not really that hard to do when you do it at the right time. The bad news is it's really hard to do if you don't and can cause innumerable problems, heartaches, cost and time overruns, angry clients, and more. The recipe for success is actually pretty straightforward:

Define success
Set clear, articulated goals
Don't underestimate level/time of effort
Under-promise, over-deliver

Do you want your projects to be great? Make every client happy? Deliver everything on time, and under budget? Fantastic. Those four points are the key, the rest is execution. I don't mean to devalue execution, because frankly, it's everything. But as the saying goes, failing to plan is planning to fail, and all the great execution in the world can't save you from poor planning. Great outcomes are achieved when goals are clearly articulated.

What is the definition of success? This is the first (and often middle, and last) question I ask when we are proposing/planning/kicking off a new project. When we, as a team, are able to clearly define what success means to each of us, we can set up a project that will drive us towards that definition. No matter what state you're in, beginning, middle, or end, you can always look back at the definition of success and see if you're on or off track. When you're done, you can categorically point to the definition and say with confidence that you expertly delivered on your promise. Everyone wins. If you don't have a “success” definition, then it's constantly up for debate and redefinition. Clearly pivoting at crucial times is important. You may find that your original definition lacked wisdom or detail, or maybe you learned something new since then. It's okay to, as a group, redefine success when significant changes occur. What you do not want to happen is that everyone has a slightly different opinion as to what success looks like. When that happens, no amount of expert execution will make everyone happy, and the project will ultimately fail.

Clear, articulated goals pave the path to success

Clear, articulated goals pave the path to success. Now that you've defined your destination (success) you need a map to get there. That map is a list of clear, concise, detailed goals to break down "success" into measurable pieces. These are most often found in the form of BRDs (business requirements documents) and acceptance criteria in stories. For designers, our job is usually to uncover and place these landmarks and signposts to guide the teams that follow behind on the trails we blaze. Virtually every design tool (contextual inquiry, interviews, journey mapping, user study, usability study, heuristic analysis et al) are meant to mine the minds of stakeholders, users and more so we can collectively create specific goals that, all together, combine to form the product or service we're building. You skip any of these steps, and it's like taking shortcuts in the untamed wilderness. It's like telling someone to bring you a rock. They bring you a rock. You say no, that's not the rock I'm looking for, bring me another rock. Ad infinitum. Have you ever been on a project that was lead that way? I have. It's torture. Don't do it to yourself or others.

Slow is smooth, and smooth is fast

“But Brandon!” You exclaim. “All this takes time, effort, and money. We have to kick this off NOW! Aintnobodygottimeforthat!” Bless you, my sweet, summer child. The military has a nice little axiom for just this argument: Slow is smooth, and smooth is fast. This is truer in software than just about anything. Moving fast and breaking things may be fun at first, but it's costly, and we've already discussed what happens to projects that try to function that way. An old boss of mine used to say, “we need to slow down to speed up.” Sounds like The Sphinx from Mystery Men, but it's true. Stop. Think. Articulate. Define. Refine. Plan. Do these things, and your execution will be faster. But it won't just be faster, it'll be better, with fewer iterations necessary, fewer bugs wrote, fewer changes necessary. Spend as much time as you can sharpening your axe so you have to swing it less and with less effort.

Sometimes along the way, you discover the target has moved, or a million other things may have changed, and all that perfect planning is completely invalidated. Did you waste your time? No. First off, one of the reasons you're likely able to recognize that the plan/target/efforts are no longer valid is because it was so clear to begin with. You are able to recognize when something isn't right because you were following a map and you now see it was upside down. Fantastic! What a great time to slow down to speed up! Pause, reassess, adjust plans/definitions/budgets/timelines/requirements et al until things are back in alignment, then execute again with abandon! Slow is smooth, and smooth is fast! Don't cling to a mistake just because you spent a lot of time and money making it.

Measure before, during, and after

How can you know if you're off course, or if you're holding the map upside down? You know because you are constantly measuring what matters. You measure before, during, and after. You monitor. You keep your finger on the pulse of each element of the project, looking for signs of atrophy, necrosis, and rot. You're also looking for bloat, smell, and itchiness. These are all metaphors we use to understand the negative aspects of projects. I can't tell you how many times someone has said "this smells funny." And usually, they're right. If you're paying attention, monitoring, thinking, measuring, reflecting back on the plan, against the criteria, rechecking the definition of success, you'll spot things that are leading you astray, or are causing your project (and people) pain and suffering.

If it’s so easy…

So if it's so easy, why do seemingly good projects go bad? How did the audit log issue (and that project in general) get so far gone? Well, in my team's defense, we came in mid-project when everything was already on fire, and we just tried to land the project as quickly as possible before we ran out of fuel and/or burst into flames. We saw first-hand what it was like to try to execute on a project that skipped literally every single one of these critical planning steps (and some we didn't even address here). We did our best to move forward.

Looking back though, even then, we thought since it was already on fire, we just needed to finish everything as quickly as possible, rather than, you know, putting out the fire with good planning and definition. We felt that moving fast and fixing things was a better approach. We were unequivocally wrong. I can state with no hesitation that, if we were to go back in time and take on that project again, here's how we should have done it:

Pause all development
Define the actual scope (success) of the engagement and append it to the contract
Write out every epic, feature, story, and task with relative acceptance criteria
Require interactive prototypes, not annotated PDFs
Updated required budgets and timelines against new scope (success)

Once we'd adequately addressed these items, we could then allow development to proceed. I guarantee we would have delivered faster, more reliably, and for less money.

Now, as you go back to your projects, or begin the next one, don’t plan to fail by failing to plan!

Define success
Set clear, articulated goals
Don't underestimate level/time of effort
Under-promise, over-deliver