I once sat next to a newly-diagnosed MS patient while walking him through an online description of the progression of that disease. It was devastating.

Another time I interviewed a long-suffering Psoriasis  patient about her frustration with the lack of progress on treatment. It was infuriating. 

I once sat next to a job seeker who had been unemployed for 2 weeks. He was invincible. And so was I. 

Yet another time I sat next to a jobseeker who was unemployed for 6 months. He was desperate for communication – of any kind. So we talked. 

Empathy is the true comprehension of what our customers, visitors and users feel when they reach out for our service. Without it, we’re designing blind. 

Get out of your cube, office or co-working space. Go meet your customers. Ask them how they’re feeling. Understand them and they’ll know it. You’ll find them in your products and services. 

[Jeff]

UX Design portfolios and deliverables are overrated and rarely useful.

“Can they draw straight lines?”

That’s what my boss asks me each time I meet a new UX Design candidate.

I’ve interviewed a lot of UX Designers over the past two years. Inevitably (and at my request in most cases) we end up going through some of their past deliverables. Whether it’s in a book or an online portfolio, a series of wireframes is typically shown along with some kind of flow diagram, perhaps an old spec or a use case template as well. What I’ve found from these hours of interviews is that, for UX Designers, an online portfolio is overrated and rarely useful.

“Sure they can draw straight lines.” That’s my response because everyone can draw straight lines in Omnigraffle.

But those lines ultimately convey an experience– an experience that you’ve thought out, iterated on and designed through some kind of internal process. That’s what I’m interested in. I want to know why you made the decisions you did and how you got to those decision. Your online portfolio won’t tell me that.

Drawing straight lines on wireframes is the price of entry for any UX Designer. Save yourself the time of building out a robust online portfolio. Consider, instead, publishing a case study of some work you did and describe your thinking. Better yet,  blog. Get your thoughts, ideas, philosophies and processes out there. That will tell a potential employer much more than a deck of de-contextualized Visio wireframes.

[Jeff]

CEO’s can be a tough group to design for – after all, it’s their vision with which you are now entrusted. I’ve been fortunate enough throughout my career to work closely with several CEO’s. From fledgling ideas to high-growth companies like TheLadders (where I’m the Director of User Experience), I’ve whiteboarded, wireframed and prototyped my way through a wide array of exciting ideas side by side with the minds who created them. Along the way I’ve picked up a few tips and tricks that can make your next startup design gig that much more successful.

Without further ado:

1. Call their baby ugly – Yes, it’s their idea. Yes, it’s their hope for their future. Yes, it’s their dream. But if it’s a bad idea or the product strategy seems wrong, tell them. If their minimum viable product is, well, not so viable, tell them. If the first designer they teamed up with sold them a sack of hammers, tell them. You’ll be doing them a favor and earning credibility. Telling it like it is makes it clear that you are not placating them simply because they have an idea and a term sheet.
2. Get to know the industry – Whether it’s online dating or concert tickets, the CEO knows the space. They live and breathe it and if you want to understand your audience, build targeted experiences and convince your CEO these solutions will work you must understand the domain. Check out the competition. Read the stats. Understand who the big players are and who just got funded. If you can contextualize your design not just within good interaction design criteria but within your industry, you’ll succeed far more often at promoting your best thoughts.
3. Drop some knowledge (do the kids still say that?) – CEO’s tend to know a lot about a lot of things, including design. However, they’re rarely design experts. This is where you experience can shine. Facing a challenging workflow? Call upon a similar challenge from a previous engagement. Analyze how a successful experience got it right and what you can “borrow” from them. You’re the expert. Show it.
4. Speak their language – It’s critical to understand how your CEO consumes information. Several of the ones I’ve worked with feast on data. If that’s the case for you, embrace it. Gather the data and show how it proves your case. If that’s not available use that to drive home the need for qualitative and quantitative testing. Making grandiose artistic arguments for your design will most likely not resonate with a CEO. Get to the point in a language they understand.
5. Work quickly – This is a startup after all. Spending time pitching and then executing months and months of user research, persona creation, deep user analysis and competitive analyses only delays getting software in front of customers. I’m not suggesting there’s no value in these activities. What I am suggesting is that you execute repeated abbreviated versions of these tasks. Work quickly and get software in front of customers. Get feedback. Fold it into your existing research and iterate again.

These tactics are not unique to designing with CEO’s in a startup environment. They’ll work in many environments but if you’re lucky enough to be working closely with the CEO employ these tactics to maximize your success and the success of the product.

[Jeff]

I realized this week that in a traditional web app design scenario there end up being three review cycles:

1. Wireframe review – ensuring all the elements are on the page, hierarchically correct and flowing logically from screen to screen. Confirming that the right data is being captured and then presented back to the user in meaningful ways that encourage the correct actions.
2. Visual design review – once the wireframes are approved, the visual design transforms that skeletal frame into a living, breathing, beautiful work of art business solution. Colors, branding, typography, white space et al are all examined to ensure alignment and aesthetic quality.
3. Interaction review – this is when the actual code is put through its paces and stakeholders, for the first time get to play with their creation. All of the assumptions “approved” in the first two reviews are now put to the test to see if, in reality, they behave the way they were represented in the wireframes and visual mockups.

This last (and third!) review cycle, the interaction review, is the first time the experience being designed is actually, well, experienced. Any changes, tweaks, complete re-works and realizations are only now surfaced. The code has to be updated and, in most shops, the documentation leading up to that code will also have to be updated. This is wasted effort.

Prototyping gets the experience out in front of stakeholders, users and the execution teams early and often. The proposed end-state can be evaluated and estimated. Workflow challenges and nuances are far more readily exposed and solved – all without having to update ANY documentation (because none exists). Prototyping shows your executives where you’re heading. It shows your dev team what they should be building and how it should behave. And it shows your customers how you’re solving their problems  — before any major code is written.

As the experience is validated each time the prototype is presented, a finer layer of polish can be applied to the design – this includes interaction design tweaks, visual design and, if your code is good enough, code tweaks. Even if the prototype produces throw-away code (or no code at all) it is still far more effective at getting you to working software faster by experiencing the experience early and often.

Save yourself time. Prototype first.

[Jeff]

Image credit: http://cdn.hip2save.com/wp-content/uploads/2010/05/words.jpg

I recently finished reading Influence by Robert Cialdini. It’s a 20+ year old book that details core tenets of persuasion in human psychology, how they work, why they work and how to “defend” against them. It was a fascinating read and one that made me completely rethink the way I design experiences and even approach my work. While Cialdini speaks of how these experiences manifest in physical space, they can easily be translated into online experiences as well. He speaks of the nature of face-to-face interactions and how those affect the “target’s” behavior but most importantly he speaks about the power of messaging.

A message’s structure is made up of two components: sequence and word choice.

Nuanced changes in either one of those components profoundly affect the success or failure of that message. The words we choose and the order we place them in (the sequence of our requests to our customers) determine the efficacy of that message.

It’s these messages that we include in our online marketing and product experiences that ultimately determine whether our target audience “hears” and complies with our requests. This is the power of copywriting and I am now a complete believer in the awesome power that skill holds. That’s not to say I didn’t respect copywriting in the past but, after reading and digesting Influence, I’ve become convinced that good design with poor copy is a poor experience (or worse, an unsuccessful one).

While I don’t want to recap the entire book here (you should really go read it) I do want to point to one experiment that I’ve been running since reading the book to see if just simply changing the words on a page can affect conversion dynamics on a signup flow. I chose to use the principle of consistency because it works well in the job search space. (Full disclosure, I work at TheLadders.com.)

The principle of consistency generally states that if you have decided and declared (to yourself, to your friends, family, etc) that you are going to do something or believe in something, when faced with a situation where you can deviate from that decision you will most likely continue down the path you’ve already decided and declared. In my example, I’ve assumed that customers coming to TheLadders web site have decided and declared that they are looking for a new job. We are a subscription service and, as such, require our customers to sign up and pay for access. We offer two levels of membership – a free membership and a premium paid membership.

Our current labeling for these membership levels simply reads “Basic (free) membership” and “Premium Membership.” There are price points listed to illustrate that the premium membership costs money but that’s about it.

To put the power of consistency to work here, the only thing I changed on the page were the membership type labels. They were changed to “I’m just looking around” for the free membership and “I’m serious about my job search” for the premium membership. That’s it. No other changes to any part of the page. The thinking was that if someone had declared themselves “job hunting” then asking them whether they were truly serious about that declaration would lead to more sign-ups.

The results were interesting and very encouraging. Just by changing the words we saw a DROP in free membership sign-ups of nearly 16% but we saw an increase of paid sign-ups of nearly 30%. All we did was change the words!

This was just one little experiment but if the power of words and copywriting can affect conversion dynamics so significantly, think about what words can do for progressing customers through a workflow and getting them to complete their tasks. Copywriting is the secret weapon of UX.

[Jeff]

I just returned from a week in hot, sweaty and rainy Orlando, FL where I spent the bulk of my time at the Agile 2010 conference. It was my first time at such a specialized, non-design conference and I was doubly excited since I also presented. I went down with many questions — how are other organizations dealing with transitions into Agile? Is Design and User Experience even a consideration? What challenges and ultimately what solutions are people finding that work well for their teams?

I came down to Florida with those questions. I went home with them too. To be fair, I did get a slew of new tactics to try but the general vibe is that many folks are struggling with Agile — especially when trying to incorporate a design team (of any size, skillset or configuration). I focused my attention on sessions that dealt with the core problems with this integration as I see them — personalities and planning.

I found Lisamarie Babik‘s session on Coaching Introverts interesting and useful as it focused on pulling the quieter members of the team into the process more. I also spent time in Jean Tabaka‘s Visioning session. While it was a bit fluffy for my tastes it did give me some good ideas on how to focus the team on the things they want to achieve and not on the negative perceptions of an Agile design environment.

Jeff Patton and Desiree Sy — both UX/Agile legends at this point — provided strong tactical sessions on how to plan product design activities into the sprint timeframes. I found those sessions valuable and both individuals extremely friendly and forthcoming for conversation and differing opinions (Jeff I’d met once before but this is my first time meeting Desiree in person).

My presentation on integrating UX and Agile is embedded below. I feel like it struck a nerve with the folks who attended as it dealt directly with the failures we experienced at TheLadders as we’ve been integrating UX into Agile. But, more interestingly than that, it showed that even when good ideas fail, you can iterate, tweak and try them again — which is the essence of being agile.

Much is said about education, experience and domain knowledge when discussing the potential quality of a design.  If the designer has the right degrees, a solid cross-section of experience and deep industry knowledge the assumption is that the design will be great. There’s a fourth component though: gut.

What is gut? It’s talent, emotion, intuition, a feeling, a belief that a design direction is the right one to go in. It can’t be quantified and it can’t be rationalized and this scares us designers. It makes us perceive gut as the black sheep of design tactics.

“Why did you put the form fields in this order and then place the button left-aligned?”

“What makes this flow better than the one we currently have on our site?”

To a certain extent you can answer these questions (and others like them) with quantified insights gleaned from proper research, your experience and the domain expertise that comes from working in a particular industry. At a certain point though, these rationalizations run out leaving some skeptics in the room and you, the designer, with only one answer left — it was a gut decision.

We fear defending our work with this tactic because it’s “fuzzy” and nebulous. In a sense we’re asking our clients to trust us at this point. And I say, that’s ok. You are being hired because you possess these gut instincts. Because, in the past, they’ve propelled your designs to success and because they are an innate part of your design process.

Embrace your gut instincts. Be proud that you have this tool at your disposal and use it to defend your work. Let confidence in your design drive the public outing of your gut instincts. Ultimately, you will build trust and confidence in your work that quantifiable tactics could never earn.

[Jeff]

I work in an Agile shop. It’s been challenging making the transition and we’re still far from comfortable but we’re making progress. There are many changes to the way “we’ve always designed” when adopting an Agile philosophy. This post will focus on one realization I’ve made recently – there are no job titles, we are all designers. Traditionally we’ve segmented our work into IA, visual design, prototyping, etc. When we first rolled out the Agile framework we desperately tried to maintain these differentiations. This came both out of muscle memory for the waterfall process but also from a respect and understanding of other disciplines and our own limitations.

The outcome of this however turned out that our new two week sprint world was now cut down, in most cases, to one week as each role tried to complete their work in time to hand off to the next one and provide them the time they need to do their work. As if two weeks weren’t short enough to create quality designs, we now had one.

It’s worth mentioning that we eased into Agile with the introduction of a suite-wide style guide that was public, wiki-based (and therefore a living document) and easily reusable. The team was generating prototypes using the assets from the style guide so no matter who created them, IxD or visual designer, the end product looked “designed.” It dawned on me at that point that there was no need to break the design process down in the way we’d done in the past.

In practice, we are all designers. Yes, we each have unique strengths, weaknesses and capabilities and it’s exactly those qualities that determine how the work gets allocated. Each person now owns a feature for the full two week sprint – effectively doubling the time they had to work on it in the past. The style guide has helped us reuse patterns as they’re needed without having to reinvent elements each time they come up. The designers on our team work can now focus more acutely on the design challenge at hand and not as much on whether form labels go on top or on the left and what color to use for secondary navigation. It’s proved to be far more efficient and productive. In addition, it’s empowered AND educated our team on the other disciplines.

Now, this doesn’t mean there’s no collaboration. The team is encouraged to reach out to their counterparts to seek advice, input and fine tuning of their work. This collaboration is a team building approach as well as a cross-pollinator of expertise. Everybody wins when everybody’s a designer.

[Jeff]

In an email exchange with Jason Putorti (@novaurora) this week the term “The Maker’s Schedule” was brought up. I’d never heard it before and decided to investigate. My first inclination was that this was some kind of religious phrase that has carried over into the professional world. Turns out I was wrong. Way wrong.

A quick google search revealed a blog entry from last year by Paul Graham where he describes two different ways of working – the manager’s schedule (hourly increments scheduled at the whim of business needs and co-workers’ demands) and the maker’s schedule.

The gist of the maker’s schedule is that those who “make things” (makers) need solid blocks of time to create those “things.” Having your day chopped up into thin slices of 30 minute availability in-between other meetings destroys a maker’s ability to produce work. Paul advocates for, at least, half day blocks of time for designers and developers that cannot be carved into smaller chunks.

I couldn’t agree more with this approach – especially for designers. It’s been proven over and over that it takes at least 20 minutes to “get into the zone” when you’re making something. Any significant distraction resets that clock. Thirty minute or even one hour slots of availability don’t provide enough runway for the creative zone to kick in, take off and produce quality work. Jason Fried touches on this too in Getting Real though he advocates the abolition of all meetings which, in a 3-5 person startup may be possible (to an extent), but proves impossible in a company with over 25 employees.

I would also add that there is a layer of responsibility for those of us in design management roles to protect these blocks of time for our teams. As design thinking and culture takes hold in a company, it is incumbent on design managers to ensure the success of our team. Promoting and protecting our makers’ schedules is a good step towards that.

[Jeff]

There are some professions where the more time one spends at their station yields greater amounts of productivity. I imagine this dates back to the dawn of the industrial age where the longer a factory worker spent at his post, the more stuff was manufactured. This “work ethic” has transcended time and found its way to the information age. Even in the most enlightened software companies there is still a belief that hours in front of a monitor produce greater output (of whatever it is that you output).

Perhaps with software engineers this might be the case. I can see an argument being made that more lines of code are written as more time is spent at the keyboard. In a waterfall development environment, managers can argue that more time at the computer produces more deliverables and specifications.

I don’t believe these arguments hold true for design.

Designers can spend hours in front of their monitors and produce nothing. Does that mean this time has been wasted? Does it mean that no forward progress was made? No. It means that the optimal solution has not yet been found. It could also mean that the monitor has not yet been used. Sketching, researching, and whiteboarding along with other forms of ideation can take place during the course of a “normal” day inching the designer closer to a convincing design solution.

In addition, design is a creative pursuit and, as such, is subject to the wills of each designer’s creative muse. There are periods of time (sometimes minutes, sometimes days) where the inspiration has not yielded the right approach or has simply not “been there.”

Does this mean designers have no work ethic? Does that mean designers are unreliable when it comes to producing as part of a team? No. It means that the forces that drive the best solutions for designers aren’t necessarily at their peak between the hours of 8am and 6pm sitting in front of a monitor. Designers’ processes need to be articulated to their teams and respected by their teammates.

So what is design work ethic? I believe design work ethic is deadline driven. Each designer knows their process for creating their best work. Mix into that the project requirements and deliverables and the designer should be able to articulate a timeline for producing a desirable outcome. Sticking to that deadline, communicating constantly, being available, raising awareness of challenges and risks — those are elements of a good designer’s work ethic.

Companies that recognize the unique needs of their designers and provide them with the flexibility to exorcise those needs will ultimately reap better output from those designers along with more successful products and services.

[Jeff]