Think about how differently design happened, say, ten years ago. Most of us remember days of being asked simply to “make the logo bigger” and “bold” certain content. It’s not that anyone at that time didn’t *want* to make great experience for their products and services, it’s just that they didn’t know how to ask for it. Frankly, there’s still a lot of opportunity to educate others on how to ask for that, but we’ve largely made great strides at the organizations we work within.
The world isn’t made into neatly defined paths. Our place in society, business and relationships are never concisely defined by a title or label for the role we play. The journey we take through our career will never be fully defined by a statement on a piece of paper, such as a diploma.
There’s been a tremendous groundswell for doing UX design faster (and arguably smarter) over the past year or so. I’ve experienced many occasions where a client comes to us and asks that we take a “lean” approach. The true meaning of Lean UX as I can understand it is to remove ourselves from being in the deliverable business (read: wireframes, sitemaps, flows, etc.) and shift the focus to the actual design process where the real value is provided. Most often, my colleagues and I think that’s just great. We don’t want be simple creators of artifacts, but rather really help solve problems through our thinking and approach; deliverables be damned. Whenever a client asks for this kind of approach, however, some interesting things can happen if the situations are not ripe for a lean approach. The inherent danger of pushing hard for a lean UX approach is to improperly suggest that it’s universally cheaper or more efficient.
Part 1 of this article largely discussed how being a design leader requires us to effectively provide autonomy. Dan Pink, author of “Drive” posits that autonomy over task, time and technique are essential for instilling internal motivation within team members who do creative work. Providing autonomy, however, is only part of the equation. If we’re to become great leaders of design for the people we work for as well as the organizations we serve, there needs to be more. Autonomy alone provides a happy team, but little else. Teams need to be inspired by vision, while having a sense of purpose while they work towards their own definition of mastery.
Leadership is one of those somewhat tricky subjects to discuss. Most of what you read comes from “business books” that have a tendency to send creative types into a manic state and plugging their ears. While I can understand our natural aversion to such things, it’s important to consider that we’re all being tasked with becoming more business-savvy as designers and developers. Let’s face it, we’ve all asked for a “seat at the table” and now we’re being held accountable for our decisions. I happen to think that’s great, but one of the results of such acknowledgement is a bigger team and greater visibility in your organization.
In part 1 of this post, we examined how customer experience is defined and how UX could move further upstream to facilitate and execute on those customer experience efforts. Essentially, customer experience is meant to consider all relevant touchpoints between a “customer” and the business itself. As we considered further, there are current methods and approaches of user experience design that account for the recognition of and design for such touchpoints. It seems that between UX and Customer Experience (CX) lies a hotbed of potential for partnership and shared effort.
Customer service. I can feel confident saying that all of us at some point in time have had a run-in with customer service. Let’s wager a guess that the interactions you’ve had with customer service probably involved your dissatisfaction about a product or service and a phone call with a person from that company assuring you that everything would be ok. No? Then it must have been a time when you had a really tough error or confusion with a product or service and you contacted “customer service” for help, hoping they would walk you through the event.
A typical scenario here at The Nerdery is a client that approaches us with an idea. That idea can be for a new product or service, or one that already exists. The most common request is one where the client asks, “Can you help me design my idea?” Most often, that request really means, “Can you do my project?” The answer is obviously, yes. We often find ourselves asking, however, “Where did this idea come from?” For optimal design solutions, it’s necessary to understand, especially for existing products/services, the history of the idea, how it’s evolved and the aim for the future. Answers to those questions, among others, empower our UX team to provide rather innovative solutions to a design problem. As user experience designers, we analyze problems differently than most people, and through methodologies we build in design work we’re regularly able to synthesize data about the problem to make an informed decision on the solution.
“We need help creating this new <insert mobile app/website/etc>.” “Our existing <digital thing> needs redesigning.” This is how a great deal of User Experience design work gets started. Somewhere, someone gets an idea for a new experience, or feels that an existing experience has gotten long in the tooth. Both of those things inevitably happen; ideas and time. As is most common, the idea and/or problems with an experience get communicated to UX practitioners and then translated into a “project”.
As UX people, we’re good at doing projects. We have many methods, approaches, tools and methods to do great design. The stickier situation for me frequently occurs when I get started on a project and suddenly ask why we’re doing this project. See, by the time the project is under way, asking why we’ve decided to commit precious time and resources to doing this is not only an uncomfortable conversation, it’s often an unwelcome one. There is a choice to be made, by many parties, as to whether or not that conversation is important enough to have, yes, but more importantly, when.
A colleague of mine recently attended SketchCamp Chicago. She was talking to me about all the things they discussed and ways of using sketching that she hadn’t readily thought of before. We ended up talking about how she was going to take pieces of what she’d learned and apply them to a current project on our team to design a mobile app.
Forgotten But Not Lost
This conversation reopened my eyes to something I’ve been doing for nearly my entire career thus far of calling myself a UX designer. Sketching is so often overlooked in the shuffle to produce visually compelling, highly polished documentation. I personally was able to take for granted that the “real” effort behind any design is the thought work that goes into creating the document, not the document itself. That is to say, the document deliverable is only a communication of that idea or concept. We all too often lose sight of where the priority should lie in our effort; the thought work.