Evolving a Creative Workplace: Step 1

Written by: Sandy Greene

When a company or team experiences rapid growth, it’s exciting. But more often than not, that success comes with a price. Behind the scenes, leadership is faced with the challenge of frantically filling positions to meet the escalating client demand, teams are asked to gel quickly and work around the clock to hit client deadlines, and ultimately the quality of deliverables suffers. It can be difficult to keep a handle on exactly who is doing what—much less who everyone is.


But there’s hope. Greg, Tim, and I expanded Intuitive Company more than sevenfold within five years, and our experience proves that building a team doesn’t have to be a haphazard process, and exceptional growth doesn’t have to lead to pandemonium.

I liken Intuitive Company, and the process we’ve taken to build it, to an organic garden. It required some high-level planning upfront, followed by easy-going care and light-touch nurturing. In other words, once we had all of the right components in place, we didn’t need to mess with things too much. In fact, we never explicitly developed a “growth strategy,” per se. We certainly knew from our past experience what not to do. Our goal was to build a workplace environment that was optimal for employee satisfaction. We were confident that if our employees were happy, their level of work would be exceptional, and that would lead to high client satisfaction (and referrals). We were right.

I’m eager to share what’s worked for us in the hope that other small businesses—or teams within larger corporations—might be able to apply some of the same philosophies and experience success.

Preparation was the first step. We founded the firm with a determination not to repeat the management mistakes we’d seen in our previous jobs—mistakes that led to high attrition rates and low morale. If there’s a word to sum up what our goal was, it’d be “openness.”

An open work environment is a must. We believe cubicles and closed-door offices do not help foster teamwork, communication, or creativity. Offices convey a sense of importance, and I’ve seen them be a ridiculous, energy-sapping source of jealousy and competition among employees at larger corporations (“Whoa, he’s got a corner office?”, “How come she has a bigger office than me?”, or “I better get an office after this promotion!”).

What’s more, I’ve witnessed how an office building’s overall location can improve or weaken employee communication and morale. That’s why we took great pains to set up a proper environment for success before our first team member was brought on board, and then moved into an even better space and location as we prepared to enter our next phase of growth.

Our floor layout is completely open. No one has an office, not even me, Greg, or Tim. We enjoy a floor-wide music system, cable TV in certain locations, fun décor, and amenities such as two stocked kitchens (including a beer keg!), vintage arcade games, pool and Ping-Pong tables, and even lockers and a shower. There are conference rooms for client calls and a separate lounge area for when privacy might be desired or required.

But perhaps even more importantly, our space is situated next to a gorgeous running trail in a cool neighborhood that has several coffee shops, bars, and a record store. Many times, employees will hash out ideas while “walking and talking” outside, or could just as easily pop into a café and brainstorm client projects in a different setting. From firsthand experience, I have no doubt that our office is much more inspiring than rows of gray cubicles in a nondescript building within an office park.

Now, I realize that not all firms can choose (or change) their locations. For the first few years after we started Intuitive Company, we were in a less-than-ideal space, but we made the most of it. So I encourage you to take a look at your floor layout and see if there are ways the space could be opened up.

Another key aspect of preparing our company for growth and success was establishing the kind of atmosphere we wished we had at other employers. An open floor plan certainly helps foster communication, but it’s not enough.

In our previous jobs, we’d seen too many managers send important messages impersonally, or in a tone that was condescending, demanding, or both. That’s why we choose to communicate in person as much as possible. There’s significantly less room for misinterpretation that way, and there’s just something about having a face-to-face chat that comes off as more respectful. Sure, we still send tons of emails, texts, and IMs to each other, but for the really critical things? We’ll always pull up a chair or head out on a stroll and take the time to have a real discussion.

I’ll cover our second step, planting, in the next installment. Until then, here are some questions to ask yourself as you get started on the preparation phase:

Opening up your environment

  • Could office doors be removed? Cubicle walls lowered?
  • Could desks be moved into the center of the floor, or perhaps line the perimeter instead of being in rows or clusters?

Encouraging open communication

  • Survey how communication works on your team or in your company as a whole. Is there passive-aggressiveness over email? Is there a lot of gossip?
  • How is good news delivered, versus bad news?
  • Would increasing the amount of in-person communication help cut down on rumors or improve morale? Try it out and see!

Illustration by Ruslan Khaydarov.

Your Boss Works for You

Written by: Fred Beecher

This past June, I stood on the brink of achieving a major professional goal. The UX apprenticeship program I’d been working so hard on was going to begin on Monday. It was Thursday. On my desk lay a curious stack of paper labeled “Manager’s Onboarding Kit.”

Of all the things I’d planned for and anticipated about the apprenticeship program, becoming a manager was something I hadn’t even considered. It’s something I’ve consciously avoided my entire career. The apprentices arrived, and I awkwardly mentioned that “technically” I was their manager. But after working with them for awhile I noticed something that changed my whole perspective.

I was working for them, and I loved it!

Granted, my situation might be unique in that my express purpose is to nurture and grow the apprentices’ nascent skills, but I learned many lessons about management that other managers can benefit from. Each of these lessons revolved around ways in which I found myself working for my team.

I cleared the path

Long ago, Samantha Bailey told me that the role of a UX manager is to shield her team from the chaos above them. I’m glad that lesson has stayed with me for so long, because I was able to put it into practice with the apprentices. I told them that their primary goal was to learn new skills and grow them. If anything got in the way of that, they should come to me and I would make whatever it was go away. I helped them clear a path to their goal through the organizational jungle.

An unexpected but happy consequence of this was that my working hard for my team inspired them to work hard for me. If you work for a consultancy or agency, you’re probably required to fill out your timesheet daily. And you probably don’t do it. The apprentices did. I told them that I relied on their time entries to track their progress and needed them to enter their time, daily, and never once did I have to have the timesheet talk with any of them.

I told it like it was

I wasn’t born in Minnesota, but I may as well have been. I am rife with Minnesota Nice. Giving people feedback beyond, “Great job! Here’s some hotdish!” makes me twitchy. But my role is to help people with promise develop that promise into talent. To do this, I needed to extend myself beyond my comfort zone and give the apprentices feedback about things they needed to work on.

It wasn’t easy for me, but it did get easier as time went on. This was because my telling it like it was led them to trust me. That trust yielded results. One apprentice in particular would make a point of implementing the feedback I gave her. One week I’d awkwardly say she should work on something, and then the next week I’d both hear feedback from mentors about how she’d done that thing and she would tell me herself. That not only helped her grow; it helped me grow too.

I increased my say/do ratio

One of my early mentors kept track of her “say/do ratio” on the whiteboard at her desk. This is a personal metric that describes how reliably a person does what they say they’re going to do. I laughed, but she was serious about it. She was exceptionally reliable. I’m fortunate that this is another early lesson I retained.

When you work for your team, you need to do a lot of things for them. I’ve not always been the most organized person, but I felt was important enough to commit to making a concentrated effort. Working for my team would be no good if I didn’t do the things they needed me to do.

Being an interaction designer, naturally I designed a process to keep track of what I said I was going to do and whether I had done it. Often, apprentices would come up to me as I was at my desk. A to-do would often come out of that conversation. I use Things to track my tasks, and I keep it open at all times. With a simple key combination I could instantly enter a new task, leaving for later the classification of the new task. During our weekly one-on-one meetings, I left a section in the Evernote note that guided each meeting for me to keep track of new things an apprentice would need me to do. Each item had a checkbox, and after the meetings I’d enter them into Things and check off the boxes in Evernote. Once the item was completed, I’d check it off in Things. Maybe this seems excessive to you, but it works for me. Find whatever works for you and do it consistently.

I constantly sought feedback

At the very beginning of the program I let my team know that I had neither managed anyone before nor run an apprenticeship program. I told them I needed them to provide feedback on both me and the program for it to be as good as it could be. Sometimes they’d provide me with feedback I wouldn’t implement, but when that happened I explained why. Sometimes the things they needed me to do for them would take awhile. Sometimes the solutions to the problems they brought up weren’t obvious.

In these situations, I communicated with them about what was happening and I sought feedback on my proposed solutions. I consciously showed them that by giving me feedback they could make things happen. As it turns out, the apprentices and I improved the program together.

My favorite example of how we built the program together is the internal project they all worked on as a team. Initially, I was dead set against apprentices working on internal projects. To me, internal projects were something to keep interns busy. I felt that internal projects would be a waste of time for apprentices. The goal of apprenticeship is to learn UX design through actual client work.

The apprentices were getting that experience, one design method at a time. They’d do stakeholder interviews on one project, then user research analysis on another. What they weren’t getting was a look at how the design process moved from one stage to another, say from research to analysis and then design. After they brought this up enough times, I swallowed my pride and suggested they work on an internal project together, from start to finish, with me as their mentor. They jumped at the chance, did a stellar job, and learned what they’d set out to learn.

I was there

The act of being physically present with your team shows that you support them. I chose to sit right in the middle of mine. Not at one end of the desks, not in an office, but right in the middle of the apprentice team. We have an open floor plan at The Nerdery, where people sit in groups of 6-8 desks rather than in individual cubicles. Being right in the middle of my team made me easier to talk to because I was only a glance away from any of them. The result was that the apprentices talked to me a lot and used the support I offered.

I ran the numbers, but I didn’t let the numbers run me

Running an apprenticeship program for four apprentices takes a lot of tracking. I have to track their time, feedback on them, and feedback they’re giving me. I also have to track how much the program is costing and whether it’s hitting its metrics. If it’s not, I have to do things to move the numbers up. Yes, this takes time. But I did these tasks early in the morning before the apprentices arrived. When they did, I could focus on them.

With management comes administration, but administration is not the essence of your job. Your job is to clear the way for your team, and administration is just another thing you’re clearing from their path. Yes, it’s something you have to do, but it should absolutely not be your focus. Your team is your focus.

Problems I faced

Even though I felt exhilarated and energized by my new role as a manager, it wasn’t all rainbows and unicorns. For example, I was still on a project as a billable designer. Balancing the work I wanted to do for my team with the work I needed to do for my client was challenging. Sometimes, I just wanted to hide so I could focus on data analysis or sketching, but I resisted. When you’re physically present, you should expect to be interrupted. What’s helpful, though, is to remember that they’re not really interruptions; they’re your job. The really tricky thing is that you can’t ever predict your team’s needs, so always expect the unexpected and have someone who can support you.

My own managers and my project team were my supports. One manager had a knack for giving me feedback without pussyfooting around. I appreciated that in her and I tried to emulate it myself. When I talked with her about becoming a manager, she let me in on a secret. She was like that with me because that’s what I responded well to. Other people needed pussyfooting to accept feedback.

When I confessed my newly positive feelings about managing to my other manager, he beamed with a knowing smile. At that moment, I knew that he’d been working for me and everyone else all along. Now when we meet, he encourages me to keep working for the apprentices and he helps me break down any organizational barriers that arise.

My project team supported me by respecting the fact that I now had two jobs. When they needed my undivided attention, they scheduled collaborative work time with me. This helped me balance my client and management responsibilities. They didn’t schedule all my unscheduled time, just some of it. This allowed me to focus on the client for a time without being out of reach. I simply told the apprentices where I’d be.

What you can take away from this

If you are determined to avoid management at all costs, like I was, here’s what I want you to take away. Managing people doesn’t have to suck. It doesn’t have the obvious allure of design, solving problems and making things, but if you approach management as if it were a design problem, it can be incredibly rewarding. Think of your team as your users and their ability to achieve their goals as their experience. Good management is the continual, real-time design of your team’s experience. When you get the opportunity to manage people, take it. Don’t run away from it.

If you are already managing people, try putting some of these lessons I’ve learned into your own management practice. It will make your work more fulfilling. If you are already working for your team, that’s wonderful! Let’s hear what you’ve learned about it!


Learn More from our Archives

Erin Malone’s So You Think You Want to be a Manager

Christina Wodtke’s Career Choices for Designers

Brenda Janish’s Leading from Within

Are You Going Soft?

Written by: Kevin Jeong

When was the last time you read your resume?

Go ahead and give it a look. Read your last job description. It’s impressive, right? Chances are, you emphasize your accomplishments, your ability to create stunning deliverables, and your extensive knowledge of the user experience practice.

Now, think back to your last project. But, ignore the deliverables and design ideas. Forget the budgets and timelines. What are you left with? Aside from a handful of sharpies and post-its, you’re left with the daily conversations and experiences you had with your team. What were they? Did you have to persuade somebody to see your point of view? Was there frustration, misunderstanding, or even a heated argument? Or, did things just “click” and everybody worked in harmony right from the start?

Most of us never stop to wonder why certain projects flow effortlessly while others feel like we’ve entered into a cage match. The truth is that most of us ignore the very stuff that determines if our human interactions are a success or a failure. Most of us ignore soft skills.

What are soft skills?

Everybody has his or her own definition. Some people call them “social skills”; a popular movie scene shows a man humorously screaming, “I’ve got people skills!” at his interviewer, and there are countless books on the subject. I define soft skills as the interpersonal abilities and sensibilities we gain during our journey from children into social adults.

Whatever label you prefer, taking a look at what soft skills are and how you apply them can have a huge impact on your work performance. This holds especially true for us in the UX field where we constantly strive to redefine boundaries, achieve consensus, and persuade others to see our point of view. The road isn’t always smooth, or even paved, and it’s our soft skills that will get us to our destination.

Soft skills applied

Let’s look at three scenarios where soft skills are put to the test. Whether these scenarios are familiar to you or not, ask yourself what you would do in each situation. Ask yourself how you would apply your soft skills and what result they might achieve.

Scenario 1: You say tomato, I say UX.

It’s 12:10PM, and the rumble in your stomach confirms that it is indeed lunchtime. Instead of waiting for your favorite noodle dish to be served, you are waiting in the conference room wishing your pencil were an appetizer.

Finally, the door bursts open and Don, the marketing manager, enters the room. “Hey sorry to keep you waiting! I was chatting with Susan about my landing page, and she was saying how busy you guys are! Thanks for taking the time to meet with me about this UI stuff.”

Did he really say “UI”? Okay, it’s an honest mistake. You decide to return the smile and politely respond, “It’s actually user experience, or UX. There’s a separate group handling UI design.”

He pauses a beat and shrugs his shoulders, “Hey – UX, UI, it’s all the same, right? Now, I was thinking about my landing page design last night and I made some sketches. I know you are probably a wizard at Photoshop, so try not to laugh…”

What would you do?

Option 1: Put him in his place.

You respond, “First of all, UX is not the same as UI. I design experiences, not just interfaces. Secondly, there’s a lot of thinking that goes into it that you are unaware of. I start with something called discovery…”

Outcome: You may have succeeded in educating him on what you do, but you did it in such a way as to leave him few options but to be offended or embarrassed. Regardless of what he says next, Don won’t be coming back to you with the same openness and enthusiasm as he did today. Chances are, he might be asking your boss for somebody else who is “easier to work with.”

Option 2: Respect and be respected.

You smile and say, “Don, you know how your job as the marketing manager involves creating these great strategy plans for the year and outlining each campaign to make sure it aligns with a goal? Well, user experience is similar in that we look at the objectives for a project and strategize on how best to design the system to match those needs. UX…”

Outcome: You’ve avoided bruising Don’s ego by sidestepping the fact he doesn’t know what UX is. You show respect by stating the value of his role and you speak his language by drawing parallels with your own. By pivoting from a head-on posture to side-by-side, you have a much better chance of him accepting what you have to say and forming a new partnership.

Scenario 2: I don’t buy it.

It’s Wednesday morning and you’re ready to present your wireframes. You flip through your presentation even though you know it like the back of your hand. Your diagrams are polished, but not too high fidelity. Your annotations are thorough but concise enough to be digestible. You’ve memorized the talking points and are anxious to present the design to the entire team.

You begin smoothly enough by thanking people for their time and quickly settle into your regular cadence. The butterflies in your stomach perk up as you talk about the ever-contentious homepage redesign. People begin to nod in agreement with your strategy and you sigh in relief since the hard part is nearly over. You pick up the pace and mention the new slider design and how it can handle multiple business priorities. Suddenly, you notice a frown on the CEO’s face and your throat dries like a towel. Here it comes.

“I don’t like sliders. Get rid of them,” says the CEO.

Just like that, your presentation grinds to a halt and all eyes are on you. Even the butterflies want to know what you’ll say next.

Option 1: Dig in.

You fold your arms and say, “Well, I think the slider is the best way to go.”

Outcome: Besides the soundtrack from a spaghetti western, this head-to-head approach yields both a winner and loser. And since it’s the CEO you’re facing, the end credits will reveal you were the latter. You want to avoid win-lose scenarios as much as possible because not only will they undermine somebody’s credibility, they promote a culture that values strength over merit.

Option 2: Just the facts.

You adjust your glasses and respond, “Well, I did try different options but this one seems to be the best fit for our users. People are accustomed to using sliders in our other app and analytics shows they actually look at all of the messages before exploring.”

Outcome: The best way to deal with emotional arguments is by sidestepping the emotion. You can’t rationalize somebody out of a personal design preference. So, defer to the facts of the design. Make it about the users and business goals, not you. You are not your design.

Option 3: Turn the critic into the collaborator.

You nod and reply, “Yeah, the slider is a tricky element on this page. I explored a lot of other options but I’m open to new ideas. Let me walk you through my thinking and maybe you will see something I didn’t.”

Outcome: It’s far easier to criticize a design than it is to create a solution. Engaging people in the design process will let you be seen as a person who wants to make the work great, not someone who craves credit for every decision. Plus, by drafting critics into becoming problem solvers, you minimize on the amount of unconstructive noise without risking confrontation.

Scenario 3: There’s a storm brewing and it’s going to be a doozy.

“I don’t care about rational arguments and I don’t want to talk analytics. I don’t care what you say. I want it designed this way and that’s the way it’s going to be!”

I couldn’t believe I heard these very words during an internal design review. What started out as a simple discussion quickly escalated into a heated debate. Well, only one of us was heated, but we were clearly both debating. Unfortunately for me, he was the project owner.

Conflict is inevitable. People go to war, they fight in court, and there are small disagreements between people all the time. When faced with conflict, think about your options. There’s more than the fight-or-flight response.

Here are your options when dealing with conflict:

  1. Flight. Someone might be having a bad day and are looking for a confrontation. If you think it’s best to avoid it altogether, do so. There is no shame in knowing when to pick your battles.
  2. Fight. If you think you are in the right and don’t mind making it clear that you are to be the winner and they are to be the loser of an argument, fighting for your position is what you want to do. Just be mindful of the potential repercussions.
  3. Give in. When push comes to shove and you don’t have a solid position, you will falter. Giving in is one way to quickly end a conflict and please the other party.
  4. Ask for help. Some situations are too difficult to face ourselves, so we call in somebody bigger and stronger to do it for us. That’s how it works on the playground anyway. In the office, we can call on our boss to handle things beyond our capability.
  5. Compromise. While it sounds like a good thing that a mutual agreement has been reached, compromise is never satisfying. Neither party gets what they truly want. And, the compromise looks a bit like design-by-committee, which always looks ugly to everybody not on the committee.
  6. Consensus. This is the holy grail of conflict resolution. You work through the material and everybody agrees the solution is a “win.”

Reading these scenarios and carefully choosing your option is a bit like living with telepathic abilities. Many times, we make choices in the heat of the moment based on our emotions, our instincts, or honestly the need to be “right.” I suggest we take a page from our own design playbook and first begin with exercising empathy. Even when you don’t know the “right” answer, thinking about what the other person is experiencing will make it far easier for you to decide how to react and have the best outcome.

What about you?

As your resume grows and you travel further down your career path, your may find yourself relying on your soft skills more and more. I’m of the mind that one’s work is never finished. In practice, there is no perfect. And, even the smoothest and most charismatic of us can use a little work. Here are three steps to getting on the path to improving your soft skills.

Step 1: List your work activities that require soft skills. For example, let’s say your list includes “Give presentations.”

Now, imagine the best presentation you’ve ever seen. Maybe it was watching a Ted Talk, your CEO, or even a colleague who works in the next office. We’ll define that performance a “10.” Now, list what skill level you think you need in order to do your job well and be satisfied.

Soft Skill Activities Required Skill Level (1-10)
Give presentations 8

Step 2: Write down your current skill level in another column. This takes some honest self-reflection. And remember, cheating only hurts the cheater. Unless you are delusional, in which case, I say go for it.

In this example, maybe you feel nervous and freeze up during presentations. Or maybe you lack the ability to go “off script” and exude the confidence and charisma you saw in your CEO. But, you still get your point across and nobody really complains. So, you think you’re about a “5.”

Soft Skill Activities Required Skill Level (1-10) Current Skill Level
Give presentations 8 5

Step 3: You knew the gap analysis was coming up next, right? Well, calculate the gap between what you need to be at and your current skill level.

Soft Skill Activities Required Skill Level (1-10) Current Skill Level Gap
Give presentations 8 5 3

What do we do when we see a gap? No, we don’t go shopping. We bridge it. Here are the bricks:

Make a Plan to Better Presentations

  • Brainstorm and talk to colleagues on how they honed their skills.
  • Look for speaking opportunities and practice religiously.
  • Join Toastmasters and refine your speeches along with your listening skills.
  • Try an improv class to boost charisma and trust in yourself.

Whatever the soft skill you are looking to improve, don’t forget it takes both learning and practice. Be creative and most important, approach soft skill development with the same tenacity you do with the hard skills we hone everyday.

Level up

Developing your soft skills will yield improvements both in yourself and your relationships with others. Contentious meetings will run smoother, your opinions will be heard (and valued) more often, and you will win the employee of the month award. Okay, the award might be a stretch, but others will recognize you for your ability to handle difficult situations and influence outcomes. And best of all, you will be doing it in a way that feels natural.

Take a look at your resume again. What is the next job description you will be writing? For many of us, the UX path can wind from practitioner to leader. The transition can happen slowly, but as your responsibilities and leadership duties grow, so will your reliance on the soft skills you have developed.

Soft skills are the leader’s hard skills.

A Perfection of Means and a Confusion of Aims

Written by: Abby Covert

“A perfection of means, and confusion of aims, seems to be our main problem” – Albert Einstein

My work involves helping people to understand how to best plan circumstances in which users are engaged and satisfied with their experience. Yet, I do not call myself a user experience designer.

I am an information architect. I work on clarifying information and the structure it should take to best enable understanding. I create maps, controlled vocabularies, diagrams, flows, hierarchies, and statements of truth to facilitate groups towards a goal. I do my own research. I use interviewing, contextual inquiry, and usability testing most often.

  • I am not an interaction designer. I do not explore, define, and refine the interactions that a user has with an interface and/or service.
  • I do not code, or render what a user will actually “see” through visual design.
  • I am not a content strategist. I do not extend structures and derive templates in order to propose governance and process flow for the creation of new information and the retiring of old.
  • I have done all of the above at one time or another.

I don’t think it is worth arguing about whether you can or should have a job in which you do all of these things. But I fear that the widespread adoption of “User Experience” has had adverse effects on the clarity of our process. It has made concepts like information architecture, content strategy and interaction design harder to explain, to teach and ultimately to learn about. In my humble opinion this umbrella is obscuring others’ view of our reality.

Our hindsight is clear, but our foresight is clouded

I am afraid that there is a shortage of specialist jobs, and it isn’t because those specialities aren’t needed. I believe it is because the value of those specialities, and the impact of not considering each carefully, is in too many cases not clearly called out to our clients and partners.

A simple test of this is asking, “If a UX fails, which part is to blame?” Is it a problem with the information architecture? The interaction design? Or maybe the content strategy? Maybe it is indeed all three or none of those three. Maybe it was badly produced or written? Maybe it has technical issues? Maybe the branding is off or the marketing didn’t drive the right people to do the right thing?

In picking apart an experience, the differentiation of terms suddenly offers tremendous value of focus. In focusing on a specialty we don’t need to throw the baby out with the bathwater. We suddenly have lots of dials to play with in formulation of a strategy for improvement.

Our process is being reduced

In my experience when “UX” is the term sold-in, the resulting project plans are less likely to reflect the points at which various specialities will be relied upon to progress the team. Often prescribing a stacked to the gills list of tasks reduced to the nebulous “Design the User Experience” on the Gantt chart. The makers of these types of plans leave it to “UX Designers” to divide the time they have amongst the various specialities of a “UX” and arrange their time against it.

If you have a great generalist who is also a great salesperson, this model can work well. But more often I fear that we are putting our industry in a bad position by generalizing when communicating about these specialities with others. I hear designers say “I’m doing the UX” far too often when describing the value that they bring or the part of the process they are in.

The worst case scenarios result in teams jumping right to wireframes, prototypes and documentation. I see far too many UX designers that have become wireframe machines.

This approach is directly contrary to the truth of how things get made properly:

1. You must define the why before the what.
2. You must define the what before the how.

In other words, defining a solution before you understand the goal and prioritized requirements is often a wasted effort and a distraction. Whether you define everything on your own and work through the various specialities required is really not my point at all, my point is that these questions and these specialities are always needed and in some cases they are answered by different people.

Our specialists are struggling

I work primarily on large scale, systems-based projects. I am good at the defining the Why and the What. But when it comes to defining the How, I prefer to work with others more dedicated to that craft. Sometimes the user experience designers I work with struggle to understand and champion the value of information architecture. Sometimes they feel like I am taking away their fun. But in moments when they need the information architecture to be clearer, they are able to demarcate it clearly and ask me for what they need. After a few of these moments the process gets easier for all of us and consensus is more easily reached.

Why would I ever have to defend the value of IA on a team of like minded umbrella dwellers? Why do I see important steps skipped in favor of moving right to defining the How so often? I don’t think it is because I am working with the wrong people. I think it is because our industry has a long history of land grabbing of titles, processes, deliverables, and value.

Our road has been paved over by many, and driven over by many more

In the past year I have been told to change my title to product manager, design thinker, strategist, service designer, interaction designer and of course user experience designer.

The convergent nature of this industry has made our road a hard one to name, and I respect that deeply. But I don’t think the right strategy is giving up on naming it, stealing a name, or settling for a name that doesn’t quite fit.

I think this is about hunkering down and creating consensus. We need to define ourselves and our value. We need to learn to sell ourselves and the expertise of others under this umbrella. We need to remember what it is like to not understand these concepts. We need to create ways of explaining what we do that make sense outside of our silo. Lastly and maybe most importantly for our own sustainability as a field – we need to give permission to generalists to specialize.

These are important steps forward as we continue to become a legitimate field of practice. Our students, clients, heroes, and our peers deserve these levels of truth.

Our future is bright

Regardless of what you call what you do, it is a great time to be alive and contributing to this time of our industry. My greatest hope is that this is still fun to talk about when it is all said and done.

I am an information architect. One day I may be something else. For now, I see a need, and I want to keep on filling it.

Mythic Design

Written by: Christina Wodtke

When I agreed to teach a twelve-week course on user experience design, I did what anyone of us would do: I went to find something to copy. I trolled the articles and syllabi I could find online, and I was horrified. Sometime in the years between Jesse James Garrett’s lovely diagram and his incendiary demand that a room full of information architects, content strategists, and interaction designers rebrand themselves as user experience designers, user experience design had grown small. Jesse’s diagram starts with strategy and finishes with skin. His elements of user experience include deciding what to build, and how it looks. Yet the user experience designers I found were the wireframe people.

The wireframe people are designers who don’t design. They don’t make mental models, or do card sorts, or task analysis. They don’t write specs, and they certainly don’t do graphic design! They carefully do a collection of wireframes they then hand to “the designer” who hands it to the engineer. And the engineer, if he’s lucky, has a product manager who did all the interaction design work in the specs. And if he’s less lucky, he does it himself. No wonder many engineers view everyone except the graphic designer as essentially useless. Too often, they are. The wireframes people often call themselves user experience designers.

And forget stealing syllabi! Everywhere I looked classes taught Omnigraffle and touted the wonders of wireframes. No wonder the world was filling up with wireframe people.

So, to paraphrase the Grinch–who I was feeling like–“If I can’t find a user experience designer, I’ll make one instead!” I had a template in my mind of what I thought a user experience designer should look like. I had seen a new generation of designer I liked and hired every time I could.

They were medium-agnostic, code-fluent, and user-centered. They didn’t draw hard boundaries between information architecture and interaction design, and they flowed easily from task analysis into interface. When they did make wireframes, it was on whiteboards in conversations with engineers or as sketches in notebooks to clear their heads. I think of them as Mythic Designers because they would have been called unicorns by the specialists.

But even if these designers are rare, they do exist, just as family practice doctors still do in a world of cardiovascular surgeons and neurologists. These generalists do everything pretty darn well. They make good sites. They might not be the best people to call on if you had to build a Photoshop or a New York Times; complex interaction or massive content stores deserve the special skills of interaction design and information architecture. But if you are a startup, and you can hire one person, you want a real user experience designer. Just as when you don’t feel very good, you just want a doctor who can help.

But I was naive. You can’t make someone capable of designing a user’s experience in twelve weeks. I almost killed my poor students as I pressed five hours of lecture on interaction design into two, pounding them with conceptual models and use cases, activity-object models and task analysis. I knew I was teaching a foundations class and I would do nothing justice, but I kept trying. They wanted to learn Omnigraffle, I said no. They wanted to do wireframes, I told them wait. A student said, “I have never gone this long without designing anything,” and I despaired. They had designed task flows, use cases, site maps, conceptual models, and the basic social structure of their projects; and they thought they had designed nothing?

And then she said, “I’m so glad. We never get time to get our heads around our projects.”

And I got hope. I relented. My TA is going to run a workshop on Omni. I’ll teach them the fundamentals of interface design next week, in the guise of wireframes. Perhaps I’ll even start teaching them one way of doing something instead of three.

It has made me think that maybe the wireframe people wanted to do good design. And maybe they were given so little time to work, it was all they could do to choose between a multiple select list and radio buttons. And maybe they just needed to be taught some thinking tools and classic techniques. Perhaps what they really needed to be taught was to have faith in themselves, so they would demand the time it takes to make something worth making.

Ten years ago, they’d have been called web designers. In a sane world, we would have called them product designers. They chose their own name, user experience designers. And we old farts who have been designing forever need to help them, so they all can be called Mythic.