It’s going to offend someone. If it doesn’t offend them, then it will make them nervous. The Vietnam Vets memorial offended a lot of people. The design of Google made plenty of people nervous. Great work from a design team means new work, refreshing and remarkable and bit scary.

You can’t tell me you’ll know it when you see it. First, you won’t. Second, it wastes too much time. Instead, you’ll need to have the patience to invest twenty minutes in accurately describing the strategy. That means you need to be abstract (what is this work trying to accomplish) resistant to pleasing everyone (it needs to do this, this and that) and willing, if the work meets your strategic goal, to embrace it even if it’s not to your taste.

Don’t get stressed about your logo.

Get very stressed about user interface and product design. And your packaging.

I had the pleasure of speaking on the same panel with Ambrose Little years ago. He’s Director of UX over at Infragistics, and he wrote this great article discussing skewmorphism (trying saying that five times fast) on the company blog. He illustrates that it may not be bad in certain instances. More importantly, it’s about context and user expectations.

Great post anyway you look at it. Read on.

You’ve probably heard someone say “skeuomorphic design is bad” by now, or maybe they wrote “skewomorphic” or even “skuomorphic” (who knows, maybe even “skeumorphism”)–it’s a tough word to spell. However you spell it, you can read the article on skeuomorphism on good ol’ Wikipedia to get the more or less official meaning. Also, here’s an article that lavishes you with skeuomorph screenshots from the iPad–sometimes it’s better to use examples to learn a concept. Of course, with the iPad, it’s more than just pretty pictures. Some of their skeuomorphism uses interactions as well, because it can thanks a lot to its primary touch interface.

My colleague @brentschooley pointed out to me the other day that Apple’s new Podcasts app in iOS 6 not only looks like a reel to reel, it has realistic motion, and as the time progresses, the thickness of the tape on each roll inversely changes (as it would if really playing), in addition to a host of minute details that really make it seem pretty magical (bouncing tape guide, for instance). And I guess I’d say that more than anything, that’s what skeuomorphism does for digital interfaces–it adds a certain kind of magic.

The point is not metaphor. The point is not even strictly usability, although something could be said for that, depending on how well the original source of inspiration was designed. It’s magic — it’s taking something you’re familiar with, maybe even seen as old and dated, and making it new, and more than it was before.

The point is not metaphor. The point is not even strictly usability, although something could be said for that, depending on how well the original source of inspiration was designed. It’s magic — it’s taking something you’re familiar with, maybe even seen as old and dated, and making it new, and more than it was before.

Some designers are lambasting skeuomorphic designs because they theoretically interfere with usability. But let’s think about that for a minute, and not just in terms of initial learnability (which is commonly seen as the only benefit of this kind of design). Many of the physical objects we use were designed. Not only that, they have had years, even centuries, to tinker with and improve their designs for human use.

Consider the book. The earliest writings (that we know of) were on the walls of caves. Later came clay and stone tablets. These pose many practical challenges, so designs were improved. Papyrus. Scrolls. Parchment. Individual leaves. Still more improvements could be made–bound books. Not all bindings are created equal–small books that fit in pockets, large books for public use in ritual. The simple, physical act of turning a page. The point is not to argue for books as the ultimate in recording and reading technology, but there are few designs as well tested and well used and well known.

If you read, for instance, The Design of Everyday Things, you begin to appreciate better the design that did (or didn’t) go into all these physical artifacts that surround us. So much of what we take for granted was designed. Much of it was improved upon after years of use and pressure to improve. Give someone a modern hammer (with the teeth to pull nails on the back) who has never seen one, and they will wonder at what the two prongs are for. They sure look decorative, but no, they were added, designed, honed over many years.

Consider the reel to reel Podcasts example. The reels moving is feedback that it is playing. The increasing/decreasing tape thickness is feedback on progress. (You don’t see a knob for volume but rather a slider, which works better on this device than a knob.) Or take the classic page turner example–the page moving with your finger as you drag it is direct feedback. The design of the calendar, especially month and week layouts were done well before technology, tried and true ways of mapping out time. People don’t get anxious that most calendars and pickers in software try to emulate that layout.

“But but!” you’ll say, “those aren’t technically skeuomorphism, which singles out elements of design that are no longer necessary due to new material/technology.” I’d say this is both true and not true. Surely we could come up with novel ways (and have in some cases) to tackle the similar design challenges, provide such feedback in other ways that are more “digitally authentic.”

People argue that using skeuomorphs or even just metaphors doesn’t bring much more to the table than this initial learnability, but learnability can make or break software’s success.

Sometimes we can find new ways that are less cumbersome (e.g., tapping the edge of a page or a flip button). Yet that doesn’t mean that the old ways have to be discarded, or even that they can’t work together (the iPad apps fuse both skeuomorphic and authentically digital designs often quite successfully). That doesn’t mean that they don’t work at all. That doesn’t mean that they are less aesthetically pleasing.

And this is in addition to the learnability win that such design brings with it.

People argue that using skeuomorphs or even just metaphors doesn’t bring much more to the table than this initial learnability, but learnability can make or break software’s success. Especially in a market flooded with so many little apps–the initial experience people have can mean everything. If you can hook someone in with a familiar design, even a metaphor that only partly works, then let them discover the more efficient “authentic” design elements in time, that can be a win-win. Consider the post above that leans towards non-skeuomorph preference:

It uses a “book” icon next to the blog label. Surely the label is enough, and what place does such an outmoded thing as a book have in digital graphic design–for a blog? Icons are notorious for this kind of “baggage.” Even just considering metaphors, it is rarely a simple binary yes or no, as to whether they are employed.

We’re not babies. We don’t need to rediscover the world completely, slowly, building little by little on new experiences. We have a wealth of learned knowledge to draw on. Even what seems “intuitive” (like touching and dragging something on a surface) is not innate knowledge.

I have five kids, and while I’m no child clinical psychologist, I have watched them learn and explore their world, first just learning that they have arms and hands, then learning to control them, then picking up more understanding of what they can do and are good for bit by bit year over year–things that we take for granted as adults.

The point is, categorically eschewing a design approach because it relies on metaphor or design elements that are no longer necessary to the material is, to put it simply, naïve.

It is always a question of how much we draw on past experiences in the design and how much we introduce new ones. I guarantee any new design that tries to be completely innovative first of all will be a non-starter and secondly would be completely unintelligible to those not involved in the design process.

Good design is not just about functional efficiency (and it’s certainly not just about novelty or supposed “authenticity”). This brings me back to magic. Apple has been mocked for using “magical” as a buzzword, but there really is something to it, and the sense of magic is, at least in part, created by their fusing of skeuomorphic design with digital design (and capabilities). I don’t need to drag out the cliché Asimov quote on this, do I? Taking something that seems ordinary and familiar and granting it new, unexpected, and to the uninformed, inexplicable powers is magical.

Sure, familiarity will eventually rub off the initial tingling sensation of awe, but the lingering sense of wonder or at least appreciation will stick with you. And if it is, for instance, a gesture that you used (or visual you have seen) all your life and have many happy memories associated with it, those happy memories will transfer quickly, creating an emotional attachment (a GOOD THING for both usability and general product success), and you’ll find yourself lingering on these design elements occasionally, long after the initial amazement wears off.

I don’t think any designer would argue that you should always use skeuomorphism, but this meme that “skeuomorphic design” is bad or “weak” is something that designers need to stop and rethink. Maybe your app could use a little magic.

This is republished from Onward Search, where I occasionally blog. Read on.

As a UX professional, it’s almost guaranteed that you’ll be working in a consultancy or contractor capacity at some point during your career. You might work for an agency, or as a solo freelancer, or you may work your way from contract to perm. Consulting is par for the course in user experience, and it’s a great skill to have.

Joining a team as a consultant is much different than coming in as a full-time employee, and has a completely different set of inherent politics. Not everyone is fit for this role, but those that do fit will find that they excel both in consultant roles and eventually back in employee roles. Being a consultant also offers you a great deal of flexibility.

To get you started, here are some tips that I’ve picked up through my years as a consultant:

Know your role

Remember, you are the solution to the client’s needs, even if it’s outside of your core skillset.

This is harder than it seems, because it changes from one client to the next. With some clients, your role may include just improving and enhancing existing documentation. For other clients, you might provide thought-leadership as you help to define the product, including conducting research that is far and beyond what is normally considered user experience.

Remember, you are the solution to the client’s needs, even if it’s outside of your core skillset.

Baseball is a great analogy: either you’re a high-priced free agent or you’re the callup filling in during the pennant stretch. Knowing where you bat in the lineup greatly helps you judge how you should interact with the client.

Whatever that role is, act accordingly. Fill in that role and fit in with the team as much as possible. The more they like you, the longer they’ll keep you around.

Listen to your client

Remember, you are the solution to the client’s needs, even if it’s outside of your core skillset.

It’s like a usability test: ask a few questions, and let them talk. That’s why they hired you – so someone will listen to them and give them solutions to their problems. They’ll tell you about everything: how the project is off the rails, politics within the company, what they had for lunch, and so on. They’ll tell you about their weekends, their dating life – I mean everything. And that’s good, because you’ll want to take notes.

As you listen to them, not only will you get information about how they want their project run, you’ll also learn how to navigate the company culture. You’ll make better decisions – which leads to better results.

This doesn’t mean that you should do everything that the client says.

If you think that the client is going down the wrong path with the product development, it’s okay to follow up with some research. Your job is to offer your expertise to the client. When clients don’t listen, your time might be better spent elsewhere.

Make your client look good

Clients that feel good about the experience will tell everyone they know.

I’ve seen this happen a few times: a user experience consultant is brought into the project, and the first thing they do is screw over the key client contact. They talk about how they don’t know user experience and/or how poorly the project is run. They talk about how the rest of the team isn’t very good. They’ll talk about bad platform choices.

That’s the wrong way the impress a client, because there are a thousand decisions that were made before you got there. You don’t understand the context of the decisions.

Your main goal should be to do everything you can to make the client look like a star.

It means:

Fitting in with the team

Presenting your work as a team product

Talking about the team they have in a very positive way

Never, ever going above their head, even if their superiors ask questions

Your secondary job is to build a relationship with the person that brought you in – because there’s a pretty good chance they’ll bring you in again if they like you. What you want is for them to endorse you to other people within the company and/or to other companies.

For example, there’s a lot of user experience work to be had with Disney in Los Angeles. If you do a good job for one part of Disney, like Parks and Resorts, there’s a good chance you’ll get recruited to work with another division, like the Disney Channel.

Many of the consultants that work with Disney have worked there for years – just for different divisions.

Clients that feel good about the experience will tell everyone they know. Those that don’t feel good about the experience will also tell everyone they know.

Document everything

The minute you don’t document something, there’ll be questions.

I know we’re trying to get to a lean world.

Until that changes, there will be one truth of user experience: we are in the business of deliverables.

Especially if you’re a consultant, which means establishing wireframes and personas so clean you can eat off them.

When you’re brought into a project, there’s a pretty good chance you won’t be working with the developers — they’ll come by later or will be in another country. Clients will bring in resources in phases. This isn’t the most efficient way to do things, but it is the way most projects are run, because clients view this as the most cost-effective method.

This doesn’t stop with the wireframes. Document what’s said in meetings. Document your time in tools like FreshBooks. Document change requests. Document everything.

The minute you don’t document something, there’ll be questions. It might be a meeting note, an annotation — or the worst case scenario, it’s about the bill. There’s nothing worse that arguing over a bill that isn’t documented well, and that can lead to legal issues.

Clients will question everything; if you can provide them with answers, you’re protecting yourself and the client.

Know when to walk

Having great clients is better than having a bunch of nasty clients whose names you curse as you pound out their coveted documentation.

Repeat after me: I am not a fit for every client. I am not a fit for every client. I am not a fit for every client. Say this several times.

You’ll know when you meet the client – or, at the latest, at the beginning of the project. There are several signs: they think that your job is to document what they want verbatim: the mantra that research is for the weak, or when you see unrealistic deadlines looming. Whatever the signs are, the best way to mitigate this is to agree to a one-month trial period to see if it’s a fit. This way, you’ll get a good idea whether or not working with the client will be successful.

A couple of years ago, I worked with an agency where I was clearly the wrong fit for the project. There were a couple of other mitigating factors (the project manager wasn’t very good his job), but the account manager and I agreed that this job was not for me, and we decided to part ways. In the end, it was the best thing for their client.

One of the best pieces of advice I can give you is this: “Choose your clients wisely.” Having great clients is better than having a bunch of nasty clients whose names you curse as you pound out their coveted documentation. This, more than anything, will determine your success as a consultant.

UXmatters has a great article about building a UX Services team, the qualities a team builder is looking for, and how consultants are “always on stage” when working with clients. When you work with a client, you never really get a second chance like you would in a company.

I look for four qualities in a UX person working in services:

A willingness to travel up to 75% of the time

Having a true consultative nature. This means being comfortable talking to an hourly call center employee, then walking into a meeting with the CIO right afterward without skipping a beat.

Deep technical knowledge. In services, you are pretty useless as a UX person unless you not only know how to design a beautiful user experience, but actually know what it takes to build it.

A solid UX background. This can come from formal training or a lot of experience in the design world.

…

My success in this area stems in no small part from the fact that a client can call me up and be assured that whoever I send from my team is going to do a quality job for them. The first time I fail to deliver on that promise, I will have effectively damaged a relationship and failed to radiate within that client. Deliver poorly on a first project, and any further projects the client is doing will not include you.

User stories don’t just communicate to engineers what they should build, they communicate why. This is a unique advantage of user stories over PRDs. Yes, there’s nothing stopping you from writing the why into your PRD. And yes, many people write bad user stories, where they forget to clearly define the actor or leave the benefit off altogether. But let’s focus on what we, as product managers, can control.

Suppose I create a great PRD. It doesn’t just explain what the engineers should build, but it provides all the requisite customer knowledge to set the context. Let’s say it ends up at 15 pages. I hand it off to my engineers. What happens?

They might read it through once. After that, they probably will refer to screenshots, or skim for relevant technical bits as they build. What do they ignore? All the reasons why.

Now let’s suppose that instead of writing a 15 page PRD, I write 50 user stories. I hand them to my engineers. What happens? They may read through the list of 50 once. That’s fine. Because what happens next, they start with the first user story and ignore the rest. But if each and every user story, communicates information about the actor, explains the desired action, and the benefit to the user, as the engineers implement each story, they have the why right there in front of them. They never lose sight of the content of why they are building what they are building.

You are, as a class of human beings, responsible for more pure raw time, broken into more units, than almost anyone else. You spent two years learning, focusing, exploring, but that was your time; now you are about to spend whole decades, whole centuries, of cumulative moments, of other people’s time. People using your systems, playing with your toys, fiddling with your abstractions. And I want you to ask yourself when you make things, when you prototype interactions, am I thinking about my own clock, or the user’s? Am I going to help someone make order in his or her life, or am I going to send that person to a commune in Vermont?

There is an immense opportunity—maybe it’s even a business opportunity—to look at our temporal world and think about calendars and clocks and human behavior, to think about each interaction as a specific unit, to take careful note of how we parcel out moments. Whether a mouse moving across a screen or the progress of a Facebook post through a thousand different servers, the way we value time seems to have altered, as if the earth tilted on its axis, as if the seasons are different and new.

So that is my question for all of you: What is the new calendar? What are the new seasons? The new weeks and months and decades? As a class of individuals, we make the schedule. What can we do to help others understand it?

Nadyne Richmond writes a wonderful blog called Go Ahead, Mac My Day. She published this post a couple of days ago, and I thought it was very relevant to the content that I push out here because of the day job. I asked her if I could republish in entirety, and she was gracious enough to give permission. Read on.

Every once in awhile, I get an unsolicited resume from someone who is in user experience and is looking for a new job. I don’t mind this — I know that finding a job is hard, and reaching out to people who have previously said that they’re hiring for a position in your field is a perfectly reasonable thing to do.

If your resume is unsolicited, you’ve got to do an even better job than usual of telling me why I should hire you. If I’ve posted here on my blog or on Twitter that we’re looking for a new researcher or designer, you’ve got a pretty easy opener for your email to me indicating interest and how you would fit into the team and meet the requirements laid out in the job ad. But if I haven’t posted anything like that lately, or if you’re responding to a very old post, you’ve got to work harder.

I’ve had a rash of unsolicited resumes recently. All of them have consisted of 2 or 3 sentences asking me to consider them for a position on my team. And I’ll be honest: I don’t even bother opening the attached resume or looking up their LinkedIn profile. I do respond to say that we don’t currently have any openings that match the type of position they’ve told me that they’re interested in in those 2-3 sentences, but I don’t look at the resume. If you can’t be bothered to tell me why I should hire you, I can’t be bothered to find out why I should hire you.

Writing a cover letter is hard. It’s hard enough when it’s for an actual advertised position. I understand that it’s doubly hard when you’re sending out a blind resume. But if you don’t even attempt to do so, then I have no reason to consider you.

When I’m hiring, here are a few of the things that I’m looking for:

Articulate

Great communication skills

Can express how their experience and expertise would fit into VMware

If you’re sending me an unsolicited resume with only a couple of sentences, you’re not meeting any of these requirements. If you don’t meet any of these requirements, it’s not worth my time to try to dig deeper to see if you might meet other requirements. If I don’t have a position open but I have a great candidate, there’s a lot that I can do to try to create an open headcount. I can have a conversation with my management about why we should go to upper management or to HR to fight for a headcount. I can make sure that they understand how awesome the candidate is and that they would add a lot to our team, and that we should try to figure out a way to make this happen. But this is quite a lot of effort on my part, and it’s probably a lot of effort on the part of my manager too, and it’s all effort that we weren’t planning on expending.

If you’re going to essentially cold call me, you’ve got to have a very convincing story. If we talk and have a great conversation but I don’t have a position open now, and I can’t shake loose a headcount from my VP, I’ll remember you in the future. That means that when I do get a headcount, you’ll be one of the first people who I contact to let you know that my team has an opening that might be a good fit for you. Without that convincing story, you won’t stick in my memory, and I’ll never remember to contact you when a relevant position does come available.

Regardless of who got played in the deal (read: small investors, as usual), the market is actually responding appropriately to Facebook’s current situation: the site is be a behemoth of traffic and attention, a platform underlying the very fabric of the Web, and an indispensable part of the lives of millions, but that doesn’t meant it’s safe. Sure, Facebook has conquered the Web, but the Web as we know it may be a dying medium. The Facebook killer won’t be a Website at all: it’ll be born mobile, just like the generation who will use it.

…

Traffic from mobile devices is growing at an astounding rate — by some estimates, mobile visits now account for fully 20 percent of Web traffic. Every measure of mobile growth borders on exponential: Cisco estimates that global mobile data traffic will increase 18 times over between 2011 and 2016, the amount of mobile data consumed will go up 17-fold in the same time frame; mobile video will account for 70 percent of mobile traffic by 2016, 25 times more than in 2011. Global mobile data traffic more than doubled in 2011, for the fourth year in a row.

As a User Experience designer, you can help employers shape the jobs they advertise. Educate them, and you pay it forward for the designers of the future.

Most hiring managers don’t understand the skills needed for great websites and web applications because the field is still relatively new. They understand that skilled designers can lead to amazing successes (read: they want to be like Apple), but they don’t grasp what the process is, for or which skillset they should be hiring. It’s not entirely their fault.

User Experience still isn’t well defined (think of our industry as television when color first came out) so it’s especially hard to come up with a job description that’s still being written. Even most college programs are still in flux, meaning that some degrees in the field aren’t worth the paper on which they’re written.

As a User Experience designer, you can help employers shape the jobs they advertise. Educate them, and you pay it forward for the designers of the future.

What’s the Lay of the Land?

Reach out to other people at the company through social media channels to get their assessment.

During the interview process, ask a lot of questions:

How many developers do you have?

Do you have a visual designer?

Is there a front-end coder?

How big is the team?

Is there a product manager?

Have you had a UX designer before?

What’s your development process?

Is your team talking to the customers?

Who’s writing the requirements?

Are there requirements?

These questions give you clues about whether or not the organization has the right makeup for success, and whether you have the tools available to effect change. For example, if this is the first UX position among ten developers and the team lacks even a project manager, it probably won’t work.

Double down if a previous hire went sour. If they’ve had firsthand experience with one who’s spent two to three months there and couldn’t even deliver a wireframe, hiring managers become especially suspicious of people in the field.

Reach out to other people at the company through social media channels to get their assessment. This is a very effective way to find out if User Experience will work there, because you can make judgments on more than just the hiring manager’s viewpoint.

I love his bit about his life goals as a “mountain,” and his mission to do only work that would bring him closer to the mountain. Of course, we should all be so lucky to work only when jobs are adventurous and stop when they become work, but there are some wonderful nuggets of artistic wisdom throughout Gaiman’s speech.