To Code or not to Code, that is the Question.

Design, Education, ,

There’s been much debate lately on whether designers should write code. This article from Jared Spool seems to have stirred up a hornets nest. I started off my career doing both design and front end code and enjoyed both. But doing both made me feel like a bit of a hack. I just wasn’t hard-core-geek enough to invest as many of my nights and weekends basking in the cool light of the monitor’s glow as becoming a ‘coder’ required. And I was always being distracted by my interests in human factors and the evolving field of user experience.

So I focused on my UX tools and built my career of designing good experiences. I love it. I’m one of those lucky bastards that does something I enjoy for a living.  My technical knowledge certainly makes me a more effective designer.

I’m sure there are benefits to being a ‘non-technical’ person. Perhaps your brainstorms are less tainted by thoughts of what is possible to build. Perhaps you can be a little more focused on what’s good for the users. Maybe. But is not being able to speak a developers language hurting your chances of getting the design built?

I’ve had countless conversations with developers talking about what is possible, what is easy vs time intensive. Knowing enough about how things work under the covers lets me play diplomat and find the good concessions. I love the collaboration. So many times the ‘techies’ have brought UI gems to the table that really bring the design together or take you down a path you didn’t notice was there before.

Let’s not forget that coders are the users of our design work. We should take the same measures to understand them that we do our website users. We’ll all be more successful.

That said, I occasionally miss getting my hands dirty, doing the making not just the designing. And things have changed a bit in the past few years. HTML5, CSS3, and jQuery have come on the scene and I feel a bit like I missed some episodes of my favorite show.

It would be a shame to let the technical skills that I have degrade irretrievably, so I’m packing up the family and heading to Minneapolis for An Event Apart 2011. Two days of getting my UX groove on followed by A Day Apart to get a crash course in HTML5 and CSS3. I’ll let you know if being a designer who can code turns out to be a good or bad thing. Maybe I’ll see you there!

Multi-tasking or Juggling?

Design

I’ve frequently been part of long term projects, finding myself working on a single initiative for months, if not years at a time. I can testify that once you transition to maintenance and long term enhancement strategies things can get a little stale. The creative excitement dwindles and long for a new project to throw my energy into. But in the beginning, having one project can give you time to focus.

Recently I’ve started working on a few endeavors simultaneously, creative energy bouncing from one thing to the next. I wonder if switching between projects will turn out to be a huge time vampire, or be a great way to keep the creative energy flowing while other projects start to drag.  I suspect that I’ll find it inspiring as it often helps to divert your attention from a design problem for a little while and let your subconscious chew on it. The best ideas come to you while you’re doing something else.

The “So What?” of User Research

User Research,

User research is important. All of us smarty-pants UX practitioners say so. But does the rest of your project team know how understanding user motivations and mental models lead to a better final product?  Your project manager reads the personas and knows that Sharon Shopper researches products online while taking care of her 3 children.  So what? How will this influence what she does?

I had spent most of a pregnancy as the only UX resource on a multi-million dollar project. There were expectations that once design deliverable templates and a style guide were created, the UX work would be complete. Other roles would have a sort of instruction book to design the rest of the application. Needless to say my days included copious evangelizing.  The nature of the project meant also meant that most of the team consisted of database power users, the type that doesn’t have much use for an elegant GUI.  After much gnashing of teeth and circular arguing, the self proclaimed ‘data people’ came to appreciate my user-centered perspective even if they were still unsure of my methods.

When I returned to the project following my maternity leave (Welcome to the world Baby Zoey!) I was asked to review the UX deliverables created while I was out. The wireframes and site map didn’t need much help, but the user research artifacts told an interesting story.

The spreadsheet from the new methodology recording user characteristics was mostly filled with “NOT APPLICABLE”. Really? The amount of daily time the main users spend using the application is not applicable to the creation of said application? The person who recorded the information didn’t understand what could be done with it. What user characteristics affect the design? Sure it’s unfortunate that user A gets interrupted frequently while running his Reports, but so what? Since we’re designing the interface according to best practices, it will create the best experience possible. Right?

When we extol the virtues of user research, we need to let people know how it’s used in order for everyone to understand why it’s important. For someone who has watched hours of usability tests it is apparent. But for the uninitiated, the explanation often sounds like this:

Step 1: Know your users. You are not your users.

Step 3: Create an easy to use product.

We need to explain what happens in between. How do we use the personas and contextual interviews to influence the design? Use examples. Explain how users that are more frequently interrupted need extra signposts to remember where there are or that older users need higher contrast fonts.

Step 2: Prioritize features according to their impact on your users, and design the application to satisfy the specific needs of those who will use it. If a best practice conflicts with what is good for your users, do what is best for your users. Oh, and never assume that you know what is best for them. Test with them instead.

Personas are often created and pinned up on team room walls by User Researchers saying that even the programmers benefit from empathizing with the users and understanding their mindset. I’ve never witnessed anyone explain HOW that benefit is achieved. Not everyone makes the necessary leap that the design your users need may contradict what works for you and seem crazy to the majority of the populous.  Identifying the right people as users, learning about them and testing your designs with them gives you what you need to end design debates and make the right decisions.

Try including HOW knowing your users begets a better product in your next project proposal and see if those user research dollars flow a little more freely.