Lost your Mockups key?
Log In to myBalsamiq
Already have a monthly subscription for our cloud-based web
Log In to myBalsamiq
I have a confession to make. For the first few years of my UX Design career I was afraid to call myself a designer.
I rejected the designer moniker to gain acceptance at the technically focused, development-led enterprise software company where I started my UX career. In order to be involved in the process, I felt that I had to prove that I was an insider, and, where I worked, "designers" were outsiders.
This was in an era (~10 years ago) where the standards for software usability were much lower and product decisions were driven strictly by requirements for what functions a product should perform, not how it should behave. While my company did have a small user experience team, our influence was limited and our skills as usability experts were underutilized. My manager called what we did "guerrilla" usability, because it felt as if the real work we were trying to do wasn't officially sanctioned or supported from the top.
We were seen by many on the development team as "design-types", who had no role in creating software, except for adding some sparkle or polish at the end. Another member of my team, who had been there for a few years, alternately described what we did as either "putting lipstick on a pig" (as when we were asked to provide icons or splash screens) or "giving the pope's blessing" to products as they were sent out the door (as if we had much choice when they were already past deadline and had been committed to being released the following week).
We tried to involve ourselves early and take our position up front, as we had been taught we should. Our typical process was to take the set of product requirements and approach the design from a holistic perspective, looking for all the ways we could improve the overall experience. We would emerge after a while with what was often a great design. The stakeholders would all nod when we showed it to them and agree on its merits. And then it would get ignored.
After going through this a few times, I realized that if I wanted to make a real impact, I had to change tactics.
I suspected that the individual developers held the keys to the end user experience of our products, more so than the product managers or development managers, so I decided to infiltrate their ranks. I set out to become a guerrilla UX warrior and enhance the usability of our products from the inside out, from the bottom up, one small step at a time.
I focused on small wins and tried to get them however I could. I threw my early ideals about awesomely-designed, intuitive, flow-inducing experiences out the window and, humbled, lowered my expectations.
Rather than starting with a comprehensive design (the "big design up front" approach) and focusing on getting approval from a development manager, I decided to target the developers themselves and work within the existing process.
Since I was not usually included in the process until the very end, I couldn't wait for the developers to come to me, so my first step was to go to them. But not with designs in hand, or a list of UI guidelines to follow. I would just casually stop by their cubicles and ask what they were working on - "how is it going?," "could I take a look at what you've got so far?," "do you need any help with anything?" Sometimes this last question would return a look of bewilderment that said "wait, what do you do, again?"
When I did get a response to it, it would often be along the lines of "I need a new icon for the toolbar, could you make me one for an XSLT transformation?" But every once in a while I'd get: "Um yeah, maybe. I'm working on this settings dialog and I'm not really sure where all the fields should go. Can you help with that?"
Aha! An invitation. An opportunity.
Despite the simplistic request, I'd try to be as enthusiastic as possible. "Sure, I can do that for you. What are the fields and values? Maybe you can send me a screen shot of what you've got now?" I wouldn't question whether the user really needed all those settings, I'd just go about using best practices to lay out the fields in a logical order and group and align them appropriately. It was UX Design 101. It was also a chance to hone my design fundamentals. I got really good at figuring out when to use radio buttons vs. combo boxes.
I'd quickly return with a design and they'd be pleased. Not because it was a good design, but because I'd just done some work they didn't want to do. I'd made their job easier (as well as making the user experience better). I made sure not to scare them off by getting all "design-y" on their simple settings dialogs.
It started working. With some developers, this turned into a habit. The "cue" was me stopping by. The "routine" was asking me for help on something UI-related that they didn't really know or care about. And the "reward" was less time spent doing UI design.
Eventually, some of them even started coming to me at the beginning of the process. I called this approach "one developer at a time."
I learned what we'd been doing wrong all along. We had been trying to promote UX at the top level by positioning it as a benefit to our customers. But what really allowed it to take hold was promoting it at the ground level as a benefit to our developers.
It didn't work with every developer, of course. I was still viewed by some as the person who was there to make their jobs harder by giving them "pie-in-the-sky" designs that would take months to build. And some developers just didn't want to relinquish any control over "their" product and never really took to my approach.
But, I slowly built a cadre of developers who liked working with me and I made sure to seek them out and give them a good experience working with me whenever I could.
Another tactic I employed was sitting in on lots of development meetings, even if the topic was strictly back-end stuff. It was all part of just being available, without forcing design down their throats. I didn't talk much unless asked a direct question. In those instances, I'd try to wow them every once in a while. "What's the primary use case here? Can we just default to those settings and remove the dialog entirely?" Did you see that? I just saved work and made the end user's life easier.
Over time, these tactics bore fruit and I started to see my work in our delivered products. I began to judge my abilities less by the quality of my designs and more by my influence on shipped code. I'd delight in seeing consistent use of capitalization, and spaces between property names where there was once camelCase (e.g., First Name vs. firstName). There were bigger wins as well, like a dashboard product that I worked on iteratively with a developer that ended up matching my storyboard nearly exactly.
It may not have produced the most ideal, intuitive experiences, but, in my mind, some improvement was better than no improvement, and I think our users were better off for it. Heck, even Steve Jobs believed that "real artists ship."
Long after leaving that job, I'm still trying to unlearn some of these habits. Balsamiq has a decidedly un-guerilla-like User Experience Design environment. Valuing good design is core to everything we do. I'm starting to think more ambitiously about what's possible and have higher standards for usability than I have in the past. Intuitively designed interfaces are important, after all. Usability matters. (It can even be the difference between life and death.)
Yet, I'm grateful for my experiences early on. I believe that designers exist to solve real problems, not win awards or promote themselves. And it's OK to have to earn your place on a team by proving that you can work well with the existing members. Because of my early role, I don't take my ability to contribute as a UX Designer for granted. And I still think about designing for implementability and am cautious about "over-designing". I try to avoid design for its own sake.
In the end, you can't forget who you're designing for. It's typically someone who really doesn't want to use your product, even if they love what it does for them. UX Designers should try to help them do what they need to do quickly and easily, so they can move on to the next thing. Get your customers to not notice the work you do and they'll actually appreciate it more.
Are you a UX guerrilla? Do you have battle stories you'd like to share? Or, are you a developer who's worked with overly "design-y" designers who have made your job harder? We'd love to hear all about it in the comments!
p.s. Big thanks to Ben for the awesome sketches!
We'll send you just one email a month and share a ton of information that you'll get before everyone else. More info about the newsletter here.
We'll never share your email address or spam you.
Your email is never published nor shared.
Pingback: Soft Skills for UX Designers - Treehouse Blog
Pingback: The User Experience Gap | UX Blog | Balsamiq
Thanks for this great article! I´ve been working with nearly the same tactic the past 5 years. And it works! Unless some manager would like to count the work you`ve done. 🙁
Thank-you! Thank-you for writing an honest post about doing UX on a real team in the real world. I get so tired of reading articles and posts about the ways UX SHOULD be done – it’s nice to hear about the ways it is actually getting done in less-than-ideal settings.