Loyal readers! There are too many of you to count and my apologies for being gone so long are, in turn, innumerable. You'll be happy to know that I've had my nose to the design grind stone
I recently relocated to Portland, OR, the hometown of my alma mater, PSU, and headquarters of The Dyrt, a campground locator app that I've been on contract with as a UI/UX designer.
While there is a burgeoning front-end community in PDX, the design community seems to keep to itself, but I did have the opportunity to chat with a designer last week and I found his perspective useful and refreshing. As I return to RSD after a brief hiatus, I thought, there's nothing better I can do than impart to you some of the knowledge I gleaned from my recent conversation. For starters, we met at one of Portland's most excellent watering holes - The Florida Room. A candle was spilled. A leather jacket was covered in wax. A hand was burned. The PBR's were cold and cheap.
This fine establishment is situated just blocks from where, a mere decade ago, a much younger me rode his bike around 'till the wee hours of the morning, pizza-flour billowing from a hoodie, singing words attributed to Benedictus Spinoza which could have, in all likelihood, been entirely fictitious.
Enough with the pleasantries and onto the gems. Here's the advice I gathered, some original knowledge, some perspective shifts, and some mere reminders. Like this first one:
1) The goal of wireframes is to abstract from aesthetics
Duh! But of course! No shit, Sherlock! But it's easy to forget with deadlines around every corner that the vast majority of UX work and problem solving is accomplished in the land of black and white.
My process begins with requirements gathering, and then I dutifully move into my notebook for sketching.Over the past few months working on The Dyrt's native and web app, I've found myself moving from my notebook directly into Sketch. I've heard of tools dedicated just to wireframes, and I've casually dismissed them, thinking "Well, Sketch can do that."
But temptation is real. With shadows and gradients and Unsplash plugins abundant in the Sketch interface, I find it harder to concentrate on the problems at hand. I fail to abstract from the aesthetics.
This solid reminder has led me to incorporating a tool like Balsamiq or Invision Freehand more distinctly into my workflow, to keep temptation at bay and stay focused on the task at hand: basic layout and fundamental interactions.
2) The language you use is just as important as the tool
Part and parcel of my rush into more engaging levels of fidelity has been communication. It is not uncommon for the iterative process to be foreign to some. As such, presenting a Marketing director with wireframes can feel a bit anti-climactic.The appropriate maneuver is not to skip essential steps in the design process, but instead, learn to communicate what one is trying to achieve in each iteration.Be ready to answer questions about your wireframes. Be ready to paint a picture of how the wires translate into the product. What they hypothesize as a solution. And most importantly, learn to couch your wireframes in the appropriate language.
The addition of a simple word to timestamp your process can go quite a long way. The most common phrase I use, this designer said, is, 'Here are my initial wireframes.'
Design jargon is just as unapproachable as the lexicon of rock climbers, Egyptian archeologists, or rare bird enthusiasts. It makes perfect sense to the initiated, but sounds like absolute gibberish to the rest.Because there's nothing worse - for both designer and stakeholder alike - than presenting a deliverable that doesn't feel like a deliverable at all.
3) Process is a guide and a good designer is a toolbox
We present organizations with a suite of tools to solve problems. It isn't always the case that there is time for the entire Double Diamond of design. Nor is it the case that such an approach is warranted.
This nugget of advice suggested I shift my thinking a bit, and shook up some of my design foundations.
The age-old adage 'Show your work' has haunted me since 4th grade long division. But it's what guided my portfolio, and it reinforces my decisions. Keeping steps in a process simply because you are unable to give them up isn't a strength, though. It might even betray an inability to contextualize one's problem solving skills.
4) We advocate for the user to mitigate business risks
Risk takes many shapes. It is easy for a User Experience Designer and HCD evangelist to get caught up in the risk of poor usability and a poor experience.Advocate for the user, and all else will follow - this has been Google's motto from the beginning. It's made them successful not only because they are concerned that the user might have a tough time understanding a certain icon or figuring out how to execute a task, but because by starting with the user, they extrapolate all other potential risks to the end-user experience and the end-business goals.
- Development costs: how much will it cost to pay a developer to build a certain design that hasn't been appropriately tested or examined? How much will it cost to re-design, take apart, and re-build that feature again when inadequacies are revealed?
- Business costs: how much will a sub-par experience cost your business? In a competitive market, say one where a newly released API is being capitalized on by a number of different competitors, how much less competitive will a poor user experience make you?
There is a balance to strike. Process helps mitigate risk, but the same exact context rarely crops up twice.
Sometimes the first idea thrown out in a discovery meeting just happens to be the perfect idea. But there is no a priori reason for any design concept or notion to go un-iterated, un-tested, or unexamined.
This idea mimics an notion of Jared Spool's, somewhat of a UX Twitter celebrity these days:
An untested hypothesis that turns out to be the solution to your problems isn't the result of a gut feeling, nor does it equate to mitigating risk, it's just dumb luck.
A few months in the trenches...
If you're thinking, "What a terrible read, I already knew all of this stuff," then in the least there's this fundamental lesson: seek out other designers.
I see developers across Portland flock together in the hundreds for meetups on a weekly basis.In some sense, because of its relationship to aesthetics, design might be more entwined with personal identity than development. But for someone like myself who approaches it out of utility more than art, I have the luxury of a detached perspective.I encourage designers everywhere to break out of their silos, because you never know what kind of fresh perspective, gems of wisdom, or rad new dive bars you might find.Thanks for stopping by. It's been real. ✌️