Designer-driven Design

It feels like I’ve been combining art and technology all my life. It’s an idea that has driven me in school and in working as a user interface designer. The combination of programming and design has culminated in my current position at Automattic, the company behind WordPress.com which I’m using to publish this post. As an employee here, I get to pick my own title and as such I’ve currently chosen “Designerd” as a concise way of explaining what I do and how I do it. I also spend a lot of time thinking about capital-D Design and why I seem to be so at odds with common wisdom and practice regarding how to design and build a web UI.

A Little Back Story

I was an arty kid. I have no idea whether this is because people said to me “hey, you’re an arty kid” and so I was like, “hey, I’m an arty kid”, or if my genes worked out as to make art a thing I could do, but either way my childhood included an awful lot of drawing.

I was also a computery kid. No one really told me I was a computery kid because computers weren’t readily available for me to play with until I was about 7, but once I started playing with them, I never stopped. I was very comfortable with computers and in the 3rd grade when our classroom received an Apple ][ that none of the adults knew how to hook up, it wasn’t hard for me to look at the wires and see where one fit into the other and have the confidence to just try it out. I think that was probably the first time I was called computery.

When the Macintosh came out, I saw the very obvious use it had for drawing and my cousins and I spent a lot of time using MacPaint to print out banners on a dot-matrix printer. I’m sure we used tons of my uncle’s paper but he never seemed to mind. I loved computers when I first used them: they were clearly tools for making art.

I was lucky enough to be introduced to the development side of computers in 1991 when I was 12 when in 7th grade I was tasked with creating a visual animation in BASIC by coding each individual pixel’s placement on an 80×80 grid, my first exposure to making art with code. In the 8th grade, I learned about scanners and used HyperCard to make an interactive Myst-like game, introducing me to my first onMouseOver event. I moved on freshman year to learning how to paint ocean scenes in acrylic then the next period writing programs for the Mac in Pascal.

Later I went to art college for graphic design while working digital pre-press 3 blocks away. I landed my first “real” web design job in 1999 without a resume at a company that wasn’t hiring a designer: I saw their ad for a receptionist at school and emailed them a link to a portfolio I designed and built in Flash.

My brain cannot de-couple design and development at this point. I start my work each day with a basic need that began when I was a child: to blend and balance the science in computers with the art in them.

The Early 2000s

I have to admit that I carry with me a certain “no one knows what the hell we’re doing”/Wild West attitude to web design that I picked up when I started out. The field itself was starting out at the same time and none of us knew what the hell we were doing, but it turns out I had some pretty solid mentors: Jen Mylo was the first person I met who had a methodology to designing for the web and Scott Upton introduced me to in-browser prototyping. We weren’t software designers, and we weren’t graphic designers. We weren’t web developers because they used ColdFusion and SQL and we weren’t CD-ROM designers because we had a markup language to describe our screens and a reload between each one.

So without a clear mode of operation to follow, we made things up. We tried to figure out what this new thing called a “web interface” really looked and felt like, given the limitations of the browser. We couldn’t do the UI heavy lifting you had on the desktop, and the whole idea of pages broke the application metaphor anyway. We improvised and we changed course quickly because that was and continues to be the benefit of designing for our platform.

Benefits of Being a Web Designer

Take some common situations that could have ruined your day as a designer circa 1999:

“There’s a typo on the final production graphics that millions of people are looking at right now.”

• Print designer: “Well, fuck.”
• Web designer: “Here’s a new version, I’m overwriting the old one over FTP right now.”

“Users hate the new placement of the button for the feature we shipped last week. No one can figure out where to find it and they’re throwing bricks through our windows.”

• Desktop Software Designer: “We can hide under our desks until the next release literally ships to physical stores 12 months from now. People will have to drive a car to buy it.”
• Web designer: “I just moved it back. Let’s figure out a way not to have that happen again. But if it does, we can still just move it back.”

To be clear, web design had and continues to have its own limitations (ahem: browsers, mobile screens, bandwidth, network timeouts, web standards, ugh I just remembered fonts). These limitations give us our own set of constraints to find the best solution we can given the medium we are designing for.

“Web 2.0”

Then something funny happened that we weren’t expecting, but sort of hoping for: the web became something everyone used, all the time, for a ton of reasons. New users were coming online every day, and new services popped up in droves to give them something to do there. Years after Wall Street left the “dot-coms” to die in the gutter, the former employees of these companies built new tools, with new ideas about what a web interface could accomplish. Web users adapted and started to actually love the products they used online. Flickr, Twitter, Tumblr, Del.icio.us: we all have memories of what was new about these things when they first appeared that delighted us.

Present Day

Building interfaces for the web is now a huge industry, a field full of best-practices, processes, and dogma. There are people who will tell you how to make your UI 31% more usable if you follow these 10 tips. There are tools built on top of other tools, designed to tell you what the margin of error is on the confidence range for the results of each stage of your A/B test so that you can know which UI converts that much better. If that sentence made sense to you, I apologize. We funnel users in and out of flows and watch what they do in bulk at each stage of the process so that we can optimize our products for the highest engagement to better reach our “magic numbers” so we know we’re on the right path. And it sucks the surprise and delight right out of our products, or even worse: makes them so addictive that people spend their time doing little else.

If you’re a client-based designer, data-gathering and user-testing are incredibly important because you will never know as much about your client’s business as they do. They’re not paying you to have an opinion, they’re paying you to understand and execute theirs. I don’t have much more to offer designers working with clients from here on, I’m afraid. 5 years of doing product work has got me thinking solidly from that side of the fence.

If you’re an in-house designer like me, then you’re now a part of the thing being made: you’re client and designer and user rolled into one. You should absolutely be a rabid user of what you make. Use the hell out of it and fix the things about it that bug you. This is a great place to start because you’re acting as both user and designer so by taking care of your own complaints you can end up solving a certain percentage of user complaints that would match.

“Data-driven design,” “data nerd,” “big data”: these are all vectors for talking about the same thing: “is what we’re doing working?” This is an important question! And you should ask it and gather data about it! And then you should decide whether or not you’re going to change course based on this data, if that’s what it’s telling you to do. If your data reaffirms your decisions, you’ll have more than one person saying in their heads “well yeah, that’s why we did it that way in the first place.” These people are experienced. They are your designers, even if their title doesn’t say it.

Evidence of your UI working for users should be a pillar of your design house, right alongside gut-feeling and an informed opinion based on what has worked and failed in the past. Your ego can give your product the thing about it that people love.

When designers change interfaces around, people complain at first, then slowly get used to the updates. The web user experience has become the de facto standard for using a computer that most people can figure out and are comfortable with, even though we change it all the time. The malleability of the web seems to continue to resonate with users.

The importance of the Designer

I’ve heard recently that “speed to clarity is of the utmost importance.” I totally agree with this statement but am uneasy with the general wisdom on how to get there. My goal is always to have a strong, informed opinion of where to go during the process of getting a UI launched so that we can see what users do with it, and then listen to what they say once they do.

Success on the live web is your only measure of an interface’s viability, so let your experience guide you to the point of gathering real-world usage. I get worried when I see designers spending too much time studying use cases in persona-land. The only way to know how users are going to react to your app is to get it in front of them in the real world, where they use it to accomplish a real task in their lives. Everything else is a simulacrum in a lab, a novel of characters poking at a painting of a web site.

This is a boring and staid example, but take the first-generation iPhone. Steve Jobs and Apple were working hard on it long before we ever saw it in 2007, you can bet on that. Maybe they user-tested these prototypes all day long for years, but Steve was never going to launch it until he felt that the public was going to love it. No A/B testing could have informed his opinion on when it was ready for actual humans, it was his gut that determined when we got to see it. For proof of Steve Jobs’ attention to detail and laser-like opinion, see every single thing ever written about him.

At what point did “this is how it is because this is how I want it to be” become a bad thing for a designer to admit?

Once we did see and fall in love with the iPhone, we could then start to tell Apple what we really wanted it to do, and we’ve been informing them of that ever since. It’s not like Jobs took too long to launch the perfect device, either. It just took as long as it took to get it right for the first version.

I honestly suspect that the iPhone was the device in Steve’s head in 1984 but all they could actually produce for him was the first Macintosh. Everything else since then had been him iterating on this vision until he died.

One of the largest and most successful companies in the world parleyed each successful product into a platform from which to take the next leap, and they did it all under the infamously watchful eye of what I would consider to be our era’s greatest capital-D Designer. His opinion built that company, and it nearly imploded into dust when he was gone and only found itself again when it bought the company Jobs founded while he was away. I don’t think this is a coincidence.

In my head, I can hear my many correct friends saying to me “Dude, you are not Steve Jobs, and you do not work for Apple. You are not building the iPhone.” which is clearly true but why not try as hard as we can to elicit the kind of delight that arises when using something that truly has a human’s vision and love behind it? I worry that testing every shade of blue until we find the right one that converts the most users is simply a process leading us down a road to personality-free products that no one loves.

The complications with this free-wheeling approach

requires experience, which a solid process can provide younger designers

Talking about process is dancing about architecture: the only way to experience the success of a process is to proceed with it and produce something.

html is the ubiquitous fabric of our medium and you need to be able to manipulate it. i don’t care how or why, just do it. css and javascript as well.

interactivity is key to using the part of your brain acting as the designer a direct route to talking to the part of your brain acting as the user. empathy is key

requires someone looking at the science numbers. just not sure it should be the same people with the art instincts. all hands on deck. embrace your constraints. fight about what you believe to be true but collaborate and coexist with those measuring your work.

Just launch it. Then: listen.