I am in the process of creating one integrated multi-disciplinary experience design practice (the organization used to have several separate compartmentalized/specialized departments). To become one team, I’ve consolidated the existing groups (40 people) and identified four main areas of oversight for our service so we can divide and conquer. For each of these areas, a director of UX design will oversee a team that will focus on a core aspect of our offering, developing subject matter expertise over time and establishing a long-term design vision.

This role has two core responsibilities: 1. To support and grow a team of talented UX people 2. To define and steward an experience vision for the aspect of the service they focus on.

In a year’s time this person will have taken a group of folks with information architecture, interaction design, content strategy, graphic design and other core skills and expertise, and successfully turned them into a team that acts as a unit.

They’ll have contributed to creating a work environment that fosters productive design practices, including training and practicing critiquing, presenting, storytelling, sketching and facilitation. The team will be capable of designing solutions that adequately translate into device-agnostic experiences employing a foundation of modular, responsive design.

Individuals on the team will have a clear picture of what their role responsibilities entail and what opportunities for growth, improvement and career advancement are available to them. They will be confident in the UX design director’s leadership and management skills, knowing they can be counted on to act in the best interest of the team and its members.

Executive leadership will trust the UXD director’s long-term design vision and have an understanding of how it aligns to the overall department and company-wide strategies and pursuits. That vision will be easily articulated by any member of the Experience Design team and used as a reference point to direct long-term design decisions.

The organization will have become accustomed to modeling approaches of varying fidelity as a method to explore design solutions and feedback cycles with users as a foundation for incremental improvements. This will signal a particular focus of the UX Design team on delivery over deliverables, solutions over documents.

Moreover, the quality of users’ experiences will be markedly improved by a concerted effort to establish a cohesive design system that unifies the service offering, addressing the core issues users experience. Given the breadth and depth of our offering, this will have been made possible through the establishment of a strong foundation of design standards and guidelines combined with a robust design practice and a team of individuals empowered and prepared to make decisions.

Are you that person? If so, please apply today.

Update: We are in the middle of updating our HR recruiting tool so if you have any difficulty with this process please email greg.killeen@marriott.com

As a manager there are many things I try and do to establish and keep clear goals in mind as well as a simple and direct line of communication across the team. This month we are finally going to make the deeper structural changes needed to integrate this team and organize ourselves so among many other things I sent this email to the team.

I’m posting it here because I thought it could be interesting to see how I try to articulate my intentions for the team and what I’m trying to portray. I’d love to see how other people do this so I thought I’d start. Note that this is not the only time I am expressing these things; I’ve talked about all of them at different times before and will talk about many of them and others again many other times. Learning doesn’t happen on single exposure.

— beginning —

<introduction omitted>

Priorities should help us make decisions about what to pay attention to and what not to pay attention to. Priorities are not projects. Priorities are not deliverables. Priorities should be criteria for decision-making, the WHYs, not the WHATs. As a rule of thumb, more than two priorities are too much for a person. The larger the criteria set to make a decision, the harder the decision becomes; as a tool to make decisions, priorities should be top-of-mind and not in any way overlapping or conflicting.

Having said that, as we start this new phase with an integrated team I would like us to work off of shared goals so we know where we are all going long-term and have specific priorities on a quarterly basis to help us focus our decisions. For the first quarter this year, this is our team’s priority:

Support the team transition into one unified experience design practice

That’s the only one. As you commit to a project, talk to other people, make decisions and define next steps for things, I want you to ask yourself, is this supporting the team transition into a unified experience design practice?

This includes, being flexible with the ambiguity we will experience during this transition such as work on projects or activities that you haven’t worked on before, work with people you haven’t worked with before, work on areas of our product you are not familiar with, take an active role in ensuring communication is clear, and so on. I am asking you to embrace the opportunities that will be presented and really do what is the best for us as a team; you will be doing these things with many unknowns until we get more established.

See someone struggling with a new thing? Help them.

See someone doing something that is just completely wrong? Try and understand why. And help them.

Having difficulty getting something done or dealing with someone? Ask for help.

Conversely, don’t take the established things for granted. This is the time to question why we have operated in certain ways, done things in a certain fashion and revisit decisions we have made but struggled with since. But please take this seriously; this is not about complaining. This is about identifying an opportunity or a problem and pursuing a resolution. It assumes follow-through. If you identify something and alert someone else of it, follow up and see where it goes. The goal is to improve things for us all not to make problems for others.

Annoyed about how much time you spend creating documents? Question if the level of detail is adequate. Then address that.

Disappointed that a particular process is cumbersome or has no clear path forward? Contact the responsible person and present the problem/opportunity. Take some responsibility for resolving it.

Reached a dead-end for trying to figure out a solution to something? Escalate the problem. Ask for help.

Tried everything and everyone and have no idea what to do next? Come talk to me.

There is room for failure. We can try our best and fail in our execution and still learn from the experience of failing. As long as you use this priority as your compass and reflect on why and how you are making decisions to help with that, I am confident any and all failures will be the best failures we could possibly get. In fact, I welcome your notes about things you are trying, failing or succeeding, and what you’re learning in the process.

Our team’s mission is to ensure the quality of users’ experiences with our services is the best possible. None of us can accomplish this goal individually. We can’t do that without being a team. This is why this is our one and only priority.

I’m delighted to be working with you and having the opportunity to build this team together. Let’s get this year started and make this team the best team you’ve worked with.

— end —

I, like many of my peers, went through various crisis as I matured professionally. First existential, wondering what my purpose and value were. Doing that while a discipline is starting to established itself is both a privilege and a curse. A privilege because you are both defining yourself and your broader collective without the shackles of traditions and ingrained habits, making progress easy and fast; a curse because when the vast majority of people “like you” are questioning what you are at the same time, it is hard to find the comfort and support that gives you the confidence to advance.

Peter Morville and Lou Rosenfeld wrote a book that described what the IA practice meant for a particular context. That provided enough confidence for five or six years of truly amazing development in the practice of information architecture. I am happy I was around. However, I have not been happy about my community of practice in the past several years. The level of energy, enthusiasm and possibility I felt and experienced in the first half of the 2000′s became marred by attempts to find a solution to a problem that was not ever really articulated.

Known as “defining the damn thing”, we talked ourselves into a circle trying to describe information architecture and its place in the world. In that process, I watched information architecture erode as a discipline. The forward momento became stagnant. When DTDT is described as naval-gazing, it’s because it accurately portrays information architecture’s adolescence. Our struggle with DTDT is because we were in effect, telling IA to grow up, “be a man”, when it was still a child verging on adolescence. That’s the second crisis, a crisis of identity. Unlike the existential crisis, value was not the core question: we learned our worth and felt (mostly) confident about it.

Identity crisis is the failure to achieve ego identity during adolescence. Psychology research (Erikson) has found that peers have a strong impact on the development of ego identity during adolescence. I, in retrospect unfortunately, spent most of my energy trying to figure out my identity and grow professionally while our collective identity crisis was taking place. I would have been a really happy diplomat. Or engineer. Or software developer. All of which I considered seriously at different points, but because I pursued this path, I needed to push myself in ways I could have never imagined and watched others do the same – and I spent several years frustrated with the lack of progress.

Information Architecture’s crisis of identity reflects our inability to change our self-image. I find it funny that the stage of psychosocial development in which identity crisis occurs, according to psych theory, is called the Identity Cohesion versus Role Confusion stage. Defining Information Architecture and being an Information Architect are different things. We spent years conflating the two. Since our daily reality is the work we do, this work exists in a setting that requires role definition. We thought that role was “information architect” and in trying to make progress figuring that out, we stopped making progress on what information architecture was becoming.

Many smart people have repeated over and over that these are separate issues, but to this day I see people not making the distinction. This is when User Experience Design won the battle. At the same time all this was progressing, User Experience emerged as a term to describe the intent of these efforts we were trying to figure out. User Experience seemed to me like a way to refocus from the dogma of User-Centered Design to a more meaningful overarching understanding that imbues various disciplines with meaning and purpose. I feel this has been wildly successful. But what of the IA discipline?

That’s when our poor framing of the question came back to haunt us. “What is information architecture and where does it belong” was now being asked in this larger User Experience context. And Peter and Lou’s definition for the context in which it was defined was not enough. Also, the same question was being asked of other disciplines. This is where Design with its deep and rich traditions emerged as a great foundation – as a practice – to form the identity that could deliver on this promise.

By declaring and accepting we are all User Experience Designers we embraced User Experience and left Information Architecture behind. Apples and Oranges. But – I hope it’s obvious now – taking the identity of user experience designers could/should have simply broadened the identity of information architect, not dismiss information architecture as a practice. Unfortunately for information architects, this amazing progress of the field (UX) happened while we were having a major identity crisis and extremely ill equipped to distinguish the two.

There is no conclusion to this. I see seedlings of the right sentiment starting to re-emerge in information architecture from people who are not interested in what we call ourselves. That problem will always get in the way and I have come to terms with it. I am an information architect because that’s a meaningful descriptor of my identity – TO ME. I don’t care if I need to describe that meaning as User Experience Designer so I can be understood, but I no longer struggle with the identity. The label is just a translation of meaning into different contexts. I absolutely embrace User Experience as the field in which I practice my work and I draw from a few different disciplines to achieve what I need to achieve. But information architecture is still the principal discipline that guides me. It took me a long time to realize I didn’t have to move away from information architecture to get to where I wanted to go. It is nice to know this instead of wondering about it.

Explaining our discipline succinctly in a context-agnostic fashion seems to be the holy grail for most – I feel ‘making the complex clear’ already did that over 30 years ago. Explaining the discipline in context-sensitive terms, well, that I can’t do and I don’t feel I need to. Describing information architecture (as in DTDT) is the top down way to answer our identity question. As an information architecture practitioner I know damn well that the most meaningful structures emerge from the content, so my base assumption is to continue expanding the boundaries of our practice by DOING THINGS and then calling them something when we need a name for them. That name may be information architecture. Or not. I don’t care – as long as we don’t conflate the practice development and our identity we can start growing again.

I was meant to give a talk sharing my story growing the UXD practice at Comcast for the past many years. I was excited to do this because I felt it could be useful to new managers and because it would help me be diligent about reflecting on that journey, which I wanted to do but had had difficulty committing to. Also, the timing was perfect. So what went wrong?

Bad choices all around

Things that contributed to the failed presentation:

* I was sick and feeling quite ill. 
I contracted a powerful stomach bug from something iffy I ate the night before. Cold sweats and trembling do not inspire confidence in your audience. I had also been on a panel the prior day and had already set an expectation with the audience on what my delivery style and energy level were. I could not live up to my normal. 

* I was intensely tired.
Because I was actively fighting the stomach bug all night long, I was unable to sleep and felt like my brain was in a haze. I was prepared and know the topic deeply, but I had a really difficult time recalling the order in which I had decided to expose the material and which specific points I wanted to make. The cues in my notes triggered nothing. It felt like having memory hiccups. Also, when I am excessively tired, English, my second language, doesn’t flow as well from my lips and I unknowingly omit words mid-sentence. I can’t hear it as it happens, but I know that must have happened.

* I took on unnecessary technical risks.
I prepared my presentation using OpenOffice and on my Dell Mini laptop. It was great for preparing but proved a poor choice when the projector refused to recognize my computer and the presentation would not display appropriately on PowerPoint on the computer I borrowed. All this happened 30 minutes before the presentation. I should not have experimented with non-standard technology since the visual aid was important, but not testing in advance in the final delivery space and setup is, always, a huge mistake (and I know better). Also, I did not have a plan B. Unnecessary anxiety piled on at the worst of times.

* I didn’t synthesize the story well.
This presentation did help me reflect on this journey as I wanted. I was able to gain perspective on the story in a way I had not seen it before. Unfortunately, I diverged too widely in analysis and ended up with less time to synthesize what I found into a cohesive story. I was sufficiently happy with where things were and it would still have been ok if the above factors had not added up, but they did, so the outcome was mediocre when contrasted with what I knew could have been done. Had I worked more on reducing it further to its essence, I could have managed the other issues better.

* Timing was disrupted.
Never allow external arbitrary inputs to break your planned delivery rhythm. Editing and being more concise in language on the fly are very doable, but only when you are feeling very comfortable in the flow of the presentation. I wasn’t comfortable, obviously, so when I was asked to wrap it up, I couldn’t figure out how and conclusion was completely derailed, which made the story seem like it did not have a real end.

I can’t have a do-over, so I’m going to re-craft this presentation and look for opportunities to give this talk elsewhere to see if I can tell the story I actually wanted to tell.

We know quite well the value of Design to business, and Design Thinking to problem solving. But what remains a bit fuzzy for many organizations is the distance between thinking and doing—the proverbial gap between strategic intent and execution. Or, how to make it happen. This year’s design thinking conference will focus on closing the gap—and moving from design thinking to design doing.

What one actually does. I enjoy the conversations about design thinking but they tend to lead to a lot of hand waving and I have found many designers and specially young managers struggling to grasp just what it is they need to do (not just talk about) to produce the positive outcomes discussed in this context.

My talk, which could not have been more appropriately timed, will be a journey through my work at Comcast between 2004 and 2011. I’m going to talk about how the UXD practice was established, how it grew, changed and evolved over the years, and what impact it’s had in the company culture and products.

What aspects of this journey would YOU be interested in hearing about? DMI is recording the video for this session so you’ll have the opportunity to see it later in case you can’t make it to Seattle. Please let me know what points in this story you’d find most useful learning about or any questions you may have.

I’ll post a summary after I’m back. Thank you!

• We’re more inclined to live in DC than surrounding areas (Columbia Heights, U Street, Mount Vernon and Dupont Circle are areas we’re looking at initially), but we would not discard Bethesda, Silver Spring, etc.
• Virginia is a no. As long as they hate the gays more than the average state we’re not living there.
• We want to rent not buy. Annual lease sounds good.
• 1 bedroom with a den would be perfect. 1 bedroom also ok. Studio not so much, we like doors. 2+ bedrooms only if not in the city (as the prices are ridonc)
• Must accept pets (we have 2 cats)
• Parking garage highly desirable (Amelia works odd hours so it would make us feel safer)
• I don’t drive. Walking distance to the metro is important. Red Line is preferable.
• Amelia works at GW and Prince George’s County so easy access to the roads that lead there is important.
• Proximity to supermarkets and entertainment is a big plus.

If you have suggestions for neighborhoods or particular places, please leave a note or email me. Thanks!

This is one of the most significant steps in what has been a decade-long quest. My wife and I met in 2001 while we were living in different countries, at different stages in our careers and pursuing other goals. We made a commitment back then to figure out how to be together and we’ve been working towards that ever since.

The hurdles were many and significant, but we successfully managed to move to the same country, then the same state and eventually the same city, up until last year when she took an International Emergency Medicine Fellowship position in DC (she is an EM physician). We’ve been commuting on weekends to be together ever since. It’s not very fun.

In the intervening years, we accumulated a number of degrees, diplomas, jobs, careers, greencards, relatives, wedding vows, real estate, pets and an innumerable amount of possessions and memories which now fill our home and our hearts. That’s a lot of baggage to commute between Philly and DC every weekend so we discussed this long and hard and decided it was just not worthwhile. We are done waiting. This move means we can finally be together for good.

I am leaving my position as Principal, User Experience Design at Comcast, which seems unreal even as I write this considering how meaningful and important this phase of my life was. I could not possibly express what it has meant to me to have done this for the past 6 (six!!!) years in a few short lines but I will talk about it more in the future. Suffice to say I am thankful for the experience, memories and friendships.

I will surely miss all the people I’ve met in Philly though I am glad to know I won’t need to live here to keep those friendships. I am very excited about living in DC too. I love the city and I am fortunate to already have many friends and family there. Not to mention how great the UX community is locally (I often attend the local events even though that means a hike from Philly every time), which means I can continue my UX community shenanigans just as much (if not more than now).

This is not an easy transition and there is so much to do that I can barely look at my to-do list without cringing, but I could not be happier and more delighted to finally come to the end of this long and hard journey feeling a complete sense of joy and accomplishment.

Thank you all who have been there for me and for us along the day. This is possible, in no small part, because of your love, friendship and support.

Update: Reason 0: It was the only opportunity to see Kevin Hoffman speak on this tour. Boooo!

Reason 1. Luke Wroblewski: I want to quit my job and be Luke’s apprentice for a year. That’s how much I value this guy’s expertise. A few years ago when he came out with a book on form design I was all “WHA??? FORM design? B-O-R-I-N-G!”. But think about it: If he can get a whole community of practitioners to see past the inane nature of form UI and into how impactful small design decisions like that have in the bigger scheme of things, he’s a person to pay attention to. And so I have. I have paid lots of attention since. And he’s delivered gold over and over and over and over again. And I missed him at WAMT in my city. Ugh!

Reason 2. Josh Clark: When his book Tapworthy came out early in 2010 I had never heard of Josh, but due to serendipity (I cannot recall how), I ended up with a copy of it, sent by him, with probably the nicest note I’ve ever received, which ended with “if you were an app, you’d totally be on my home screen”. I had not designed a mobile application before reading the book, and I finished it feeling confident about doing so (and so I did). Josh & mobile design were meant for each other: he is really good at providing concrete guidance on how to design for its unique contexts of use, while being careful about categoric approaches given how nascent this whole thing is and how quickly it is evolving. Fortunately, I was able to take a whole-day workshop with him at the IA Summit last month, which cemented my impression and expectations. Now you can get some Josh action yourself.

Reason 3. Stephen Anderson: I’ve known Stephen for a long time now and was able to see him present numerous times (if you haven’t, this is your chance, don’t blow it). At first it was his brilliant visual design skills that caught my eye (you will not find more beautiful presentations anywhere. I dare you), but also, he brings a really interesting perspective to UX; a blend of education theory and psychology that I have not seen anyone else pursue and offer to our community. Every single time I hear Stephen speak, I come out having learned something I did not know before and, more importantly, a dozen questions on things I had not thought of before and an enthusiasm to pursue them. To me, that’s one of the most valuable things you can take away from a professional event.

Reason 4. Steve Portigal: I can count in one hand the number of people in the world I really look up to in the area of design research. One of them is Steve Portigal. I’ve been reading his blog since before smartphones existed. Yes, we are old. I’m not formally trained in research methods and mostly picked up skills as I progressed in my career. Everything Steve has shared with our community I have voraciously consumed. He talks about the stuff that makes a difference when you are actually doing research. Stuff that other people who don’t do research think is boring, like how to ask good/right questions in an interview and how to do analysis once you are done with the fun data gathering part. In short, he leaves the general hand waving about design research to others and gives you all the juicy bits. On a platter. So don’t screw up and miss the opportunity to ask him questions in person, like I did. #facepalm

In conclusion

I could really keep going and tell you in excruciating detail all the reasons why it was stupid of me to miss the Web App Masters Tour (there are 7 more: Bill Scott, Kate Brigham, Mike Lee, Aviva Rosenstein, Noah Iliinsky, Julie Zhuo and some guy named Jared Spool), but you get the picture. Even if you can only see a few of them speak and have to run back to work (maybe share with a colleague?), it is definitely worth going. I’ll go beat myself up about it offline now. Luckily, you don’t have to make the same mistake: They will be in Seattle (May 23-24) and Minneapolis (June 27-28), so go get some. Tell them I sent you. My name + $5 gets you a free coffee.

UPDATE:

I just found these: