You know, we use ad-blockers as well.
We gotta keep those servers running though. Did you know that we publish
useful books and run
friendly conferences — crafted for pros like yourself?
E.g. our upcoming SmashingConf New York, dedicated to smart front-end
techniques and design patterns.
I once worked with a digital agency that didn’t know how to hold a kickoff meeting. And they didn’t even know that they didn’t know. Weeks into every project, they’d simply find themselves frustrated over how they’d ended up in a position of following rather than leading.
They would fight to get their good ideas out the door but end up on defence all the time when their clients came back screaming with arguments based on whim and vapor. The agency just couldn’t figure out how to establish itself as the UX leader of its projects, despite being hired to play exactly that role. I’m not even sure they recognized what it meant to lead.
There are reasons you’re still saying the same thing after all these years — still talking about how it always seems like design gets tacked on to the end of the process. You should be at the concept meeting, you say, where you can make a real difference.
I’ve been hearing it for 15 years. I once had a job where I got to say it myself a few times. I got tired of that pretty quickly. I don’t say it anymore. You shouldn’t either. Primarily because it’s not true.
Let’s say you run a UX team. Better yet, let’s say you don’t. Let’s say you just want to do great work. You’re a consultant. You’re a newbie. You’re an intern. Your position is irrelevant. So is your title. What’s important here is that you want great UX to happen. You want it consistently. You want it now. You want it all the time.
No matter your status or situation, whether director or loner, you are in a position to lead, to raise the bar in a place where it consistently sits lower than you think it should.
In my career as a user experience professional, part of my purpose has always been to help push our profession forward. And I’ve had the great privilege of being able to do just that in a myriad of ways — by writing books and articles, speaking at conferences all over the world, delivering in-house training workshops at wonderful companies, and simply doing the work for a great many clients.
If I could be remembered for just one thing, I’d want it to be this, because this is what designers and companies need to know and understand about the nature of user experience as a profession, a goal, an idea.
As I sat in my local co-working space, shoulder-deep in a design problem on my MacBook Air, I could hear him. He was on the phone, offering screen-by-screen design recommendations to his client for the project they were working on. When this acquaintance of mine arrived at the subject of a particularly hairy task flow, he said, “Well, these aren’t going to be very savvy users, so we should probably put some instructions there.” He followed this by rattling off some dry, slightly too formal line intended to clear up any confusion about the page.
It was an act that reflected his apparent belief that some savvier type of user is out there who would immediately understand the screen and could live without the instructive text. I cringed. I’ve heard the same suggestion on far too many phone calls, and it’s been wrong every time. To shed light on my reaction to it and to illustrate why such a suggestion is problematic, let’s consider a quick tale of two users.
Right there in the center of my boilerplate for design proposals is a section that I glare at with more resentment each time I complete it. It’s called “Deliverables,” and it’s there because clients expect it: a list of things I’ll deliver for the amount of money that I specify further down in the document. Essentially, it distills a design project down to a goods-and-services agreement: you pay me a bunch of money and I’ll give you this collection of stuff. But that isn’t what I signed up for as a designer. Frankly, I don’t give a damn about deliverables. And neither should you.
Case in point: for months now, I’ve worked consistently with a particular client for whom I do almost no work on actual design artifacts (wireframes, prototypes, etc.). Rather, I hold frequent calls with the main designer and developer to go over what they’ve done with the product (i.e. poke holes in it) and what they should do next (i.e. help prioritize). Some days, they hand me wireframes; sometimes, a set of comps; other days, live pages. Whatever the artifact, our purpose is always to assess what we have now versus where we need to get to.