Blog of Andrew Mckinney

Apache httpd.conf location on Snow Leopard

This shouldn’t be so hard to find, but the default install of Apache2’s httpd.conf file can be found here:

/private/etc/apache2/httpd.conf

A note to myself and others.

It ain’t easy being a UX designer-developer

There seems to be a pervasive myth that the idea of a designer-developer, a one-man army of product and software development cannot possibly exist. I have heard this said on both sides of the aisle, albeit more from UX designers than developers. But I digress.

Designer-developers do exist. I am one of them. It was not easy getting here, and over the years I have endured all manner of naysayer telling me I couldn’t be both, and shouldn’t even a attempt it.

At age 13 I wanted to create my own computer game, “Nazi Killer”, but had no idea how to program or even where to start. I began tinkering with an Mac application ripper, and through this process created my first game by replacing the image and sound assets of another game “Barney Killer” with my own. I could have cared less about writing the code for my own game; i just wanted it to be.

As time passed and my interest in technical creation grew, I realized I had to get my hands dirty to do something incredible. I began learning C++ with the intent of creating a DOS version of the Peter Jackson gore film Bad Taste (not a joke, I was a weird kid). I bought every book I could find, tracked down every person who knew ANYTHING about C, and got a summer job to buy a modem to grab code from local BBS’. I didn’t care about C as a language, or technology for the sake of itself. What I did care about was making my vision happen on a computer.

Fast forward through a Computer Science undergraduate that I was not well-suited for, enter the tail-end of a three-year technology management consulting career…

I was working on my fifth technical development project in when it struck me that there was something fundamentally wrong with how we were approaching our software. There projects felt like shots in the dark. Requirements gathering to functional specs to code, followed immediately by an unsuccessful software project after project. It wasn’t for a lack of talented people, but a lack of insight as to how and why the product would be used. These people were hardcore techies with Chicago-made business professionals running the show. This environment embraced all-killer no-thriller fast-talking-high-pants action. Promises of fast software are sweet to the ears of project managers and executives, but well-designed software this does not make.

Myopia

About this time I decided it was imperative I enter design school. I was inspired by Kathy Sierra, Tufte, Cooper, Norman and others. But in the 2007 Chicago business environment this decision was met with hostility. I was cornered by wave after wave of senior consultant telling me I was a fool for not applying to business school, and that design was a dead-end. “Designers are the bottom-feeders. Go get your MBA and be a rich man. You’re good with people and business.” I’m paraphrasing here, but much worse was said about designers and design school by these supposedly budding masters of industry. The hardcore techies at the firm weren’t much nicer about my decision. Smack talk about the artsy-fartsy client designers was commonplace.

I searched long and hard (penis joke!) for a design school that I felt would give me the wakeup call that I needed. I wanted to be inspired. I wanted my requirements-gathering world to be shaken. The program I ultimately decided on was Indiana University’s HCI/d program.

Indiana’s HCI/d program is fucking incredible. It’s not on the top of any IXDA list, but allow me to elaborate: The professors are top notch, come from a variety traditional design, technology and sociology backgrounds. They meet directly with masters students on a regular basis and encourage open discussion. Few others in design research schools are seriously exploring experience design, emotional design, group theory and even beyond. It’s a program and a faculty that is out there and proud of it.

But…

A program like this, that is so intensely design focused can fall into the trap that so many others: myopia. In this program, it meant an intense focus on User Experience design sketching and paper prototyping, but nothing past the initial steps. Why? Because going any further would put us in the seat of a developer/engineer, which is not the focus of the program. This is fair, but there was a feeling of outright resentment against engineers, developers and programmers. There were the side-comments from a few influential faculty, and then second-year masters students, and ultimately the first-year students. Developers, programmers, engineers, they said, “didn’t get it”. They were viewed as the mechanics, the helper monkeys; not the thought leaders. As designers, we were told, we would rule the kingdom of product development. All others would tremble and kneel at the glistening brilliance of our sketches and paper prototypes. We would be the next great leaders as the purist design oracles. These ideas were pervasive, starting with a few mouthy professors, trickling down to second-year design students (so-called ‘mentors’), only to later be spoken by first-year design students. As someone who considered himself a developer, I didn’t agree with these sentiments then, and I still don’t now.

As I did in business consulting, I endured all manner of douchey comments leveled towards me as I attempted to reconcile my engineering skills with my design education. “True designers don’t take their designs past simple prototyping. That’s an engineers job. True designers don’t code what they design. You’ll never be a good designer of you also want to engineer. Developers can’t design because they don’t get it.” The other technical designers told me they felt it to, but remained quiet for fear of a brutal designer gang-beating, which would often happen to anyone with a dissenting opinion by a vocal group of students. None of these comments were coming from experience, but what could I do?

Insecurity

For all of the trash talk leveled against designers from developers or business people, none was so dismissive and cruel as the venom coming from my fellow designers. I can name several examples of receiving a nasty brow-beating by professors and fellow students alike for the mere thought of designers engaging in development. I was once given a significantly lower grade (albeit from a 2nd-year design student) for attempting to implement my well-iterated design. He actually said that in my project review feedback. In a more recent example, I was told over Twitter by someone whose work I respected very much that I was a “fool” for encouraging a 1st year student take a particular class outside of the core curriculum. For individuals who pride themselves on being so open to new ideas and change, the thought of new ideas and change outside of design seem to be met with a great deal of resentment.

Is this jealousy? Perhaps in some cases. That’s what many of my developer friends believe. But more than jealousy I think its insecurity. And I think this insecurity falls on both sides of the design/development fence.

A developer telling a designer that their idea is unrealistic can be a major kick to the ego. A proud designer will speak in great detail about the sheer scale of user research, exemplars, design iteration after iteration that went into their prototype. And now suddenly, they’re being told that their idea is unrealistic, undoable, and that it wouldn’t be completed as designed. In a purist designer’s eyes, this is a failure, and a dismissal. It implies the designer did not have the technical chops to understand how to properly design for production. Who is this non-designer trying to tell me that my design is undoable? They don’t care about user experience at all. They don’t understand good design. If only I had the power I’d make them do it!

A designer telling a hardcore developer their creation is poorly designed is like telling them their baby is ugly. It’s not an easy task to put together a piece of software, and when it’s finally up and running it’s like the completion of a piece of art. A proud developer will immediately start talking about the design of the solutions architecture - the many iterations they went through to put it together, how lean and clean everything works. And then, some outsider who seemingly knows (and cares) little about the task of engineering says, “yeah, the design needs improving.” Who the hell are they to tell me my design needs improving? Their design will take months to build. I’ll just ignore them - they aren’t necessary to the process anyway.

I hear these same complaints at least once a week at work: developers complain about UX designers unrealistic designs, designers complain about developers unusable interfaces. The differences seem irreconcilable.

A call to action

Designers and developers don’t get a long, so what? Who cares? I care. I’m here today, right now, as a designer and a developer to say all of this dismissiveness of each other needs to stop. I say horseshit to the idea that developers can’t be designers because of some genetic flaw. Horseshit to the belief that designers are information technology phonies.

The truth is that both UX designers and developers add something to the process. I know this because I have been through both rigorous computer science and design education. I have held both technical and design positions at renowned companies. It has taken me years to get here and it was not easy. Here’s my challenge to both designers and developers:

Developers: Good design is a difficult thing to achieve, but it is not magic. User experience means putting the user first, understanding their needs and underlying desires, and then using your own designerly (yes, you are a designer!) judgement to make something which does not yet exist. Here are a few good books. Design can transform an unfinished idea, like an unfinished diamond, into something incredible. And a developer who can also design is a tour-de-force.

Designers: Learn something about implementing your design. I’m not saying “learn programming”, I’m saying “learn how to implement your design to some degree”. If this involves software development, be prepared for a lot of ambiguity and feelings of defeat. Engineering is all about patience, planning and rigor; its a great puzzle. But you will come out of it a more well-informed designer as a result. Siegel and Blevis (designers!) call this “Computer Imagination”: understanding the possibilities of the medium for which you are designing.

And the best thing is that you will be more able and therefor more marketable. I landed my associateship at Disney Animation because of my cross-functional skills. I’m crafting my own iPhone app by understanding both the design and development implications of my work. Every day I sketch. Every day I write code.

Naysayers

Designer-developers do exist. It’s just a matter of stepping outside one’s comfort zone. If you decide to do this, you will, as I did, be called “foolish”. It will come from all sides, even from people you respect and look up to. Pay them no mind. Let the naysayers believe whatever they want to believe. Be like water, or whatever Bruce Lee says. Ignore those who do not know and follow your own path.

I sometimes doubt my approach to this practice. I question my own accomplishments, their value, my success. Whenever I’m in this state, I think about all of the people in the past who have laughed at me, questioned my sanity, called me foolish. How much I was effected by what they said then, and how wrong they are now. And then I think about those who have encouraged me and helped me along. Remembering this, I try not to ever dismiss someone’s ideas, no matter how unpopular or ‘crazy’. Instead I challenge my own boundaries, and encourage them to reach out and go further.

So with all of this said, continue to be foolish, continue to try new things and go outside of your comfort zone. Get in way over your head and dig your way out. Designers can be developers, developers can be designers, and dogs and cats can live peacefully together.

Why I won’t build your iPhone/iPad App

In the past four years, every month or so, I’ll receive a request to ‘join a team’ building a piece of software for the technology-du-jour of the time. These requests often come with a wishy-washy explanation of the ‘big idea’ for a project, but with little deeper thoughtwork concluded.

Since most of these requests are from friends and former colleagues, I keep the responses polite and supportive, but with a definitive “no”. Sometimes these folks can get a little pushy. This is when I start to ask them directly about roles on the project, equity split, prior thoughtwork/high-level design. In almost all cases, they have not thought this out at all before contacting myself, a potential partner in their organization. In all cases, they are the ‘idea guy/business’ and I am the ‘designer/developer’ which means I basically do all the work while they play golf on the moon.

I write code to realize my vision. I do not really enjoy the act of it, but the fruits of my labor. All relationships should have an equal contribution from each member. I’m a shitty artist, so if you’ve got a good idea and can create quality graphics, let’s make it happen! But if you can’t contribute anything but an idea, something ephemeral and without real form, you add little value to the working relationship; this is imbalance. Come to the table with something more to offer than an idea.

“But everything starts out as an idea”

Few things finish as an idea. Your great idea exists only if you make it exist. You can create it yourself through much dilligence, or get someone else to do it. If you want someone else to do it you need to give them a very convincing reason to do so. Money acts as a strong incentive. It’s such a compelling tool, in fact, that I work 40-hours-per-week for a company to earn money. If you don’t have money, then you need to provide something more than an idea. Otherwise, get used to receiving the following email:

Hi __________, It’s good to hear from you! I hope your family is doing well. Your idea for a ________ that _________ is an interesting take on the whole __________ dynamic. Unfortunately, my cart is full with other projects at the moment. Please do stay in touch and good luck with your idea. Regards, Drew

Dealing with project fatigue

I suffer from project fatigue frequently. Project fatigue, for the uninitiated, is that awful exhausted feeling you get after an extended period of time on a project. I have an unproven belief that project fatigue is the hidden cause of long-term project failure.

When I begin to get project fatigue, I switch what I’m working on completely. I’ll put down the project for a few days, pick something else up, and come back to it later. I find it refreshes my feelings about a project. “Fondness makes the heart grow stronger” and all that jazz.

HTML sketch prototypes - best of both worlds

Sometimes you need to demo a website but don’t want to commit on the visual fidelity; HTML mockups feel right, but then people begin commenting on font choices and margins and the conversation goes pear-shaped. You want the negotiating freedom of a sketch with the sharability of HTML. This is where HTML sketch prototypes come in handy.

The example I will illustrate here was taken from a project I completed with Disney Animation Studios called “Softweb”. This HTML sketch prototype was a 25-screen internal web service which was sketched out by the team over several months. We wanted to create a final solution that would last even after the project was over - something people could come back to and pick up if the project ever lost momentum. Happily, the project was picked up and is now under development.

HTML sketch prototypes are also the one place where Dreamweaver is functionally handy. Scan in your sketch interfaces and import them into Dreamweaver. Use the Dreamweaver image map to outline clickable items on the interface in the Design View. Then, link the pages together using the properties menu.

Once you’ve tied everything together and tested, what you get are clickable HTML prototypes that can be tested on any web device. You can email links to users for feedback, use it as a clickable walkthrough during a presentation, and all the while keep the conversation on the functional elements. You’ll rarely hear comments about border color with these :)