Filed under Good Experiences, Management
January 21, 2012 at 4:03 pm
I am looking for the right person join my team as Director of User Experience Design.
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.
Filed under Management
January 19, 2012 at 5:22 pm
I have joined a new company in the past six months and have the great pleasure and opportunity to bring together a few different teams to make up an experience design practice of 40 people tasked with overseeing the UX of all of our company’s digital services. It is precisely the kind of challenge I salivate for so I have been re-energized by this opportunity and incredibly eager and invested in successfully making it happen.
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 —
Filed under Information Architecture, Me, me, me!
September 24, 2011 at 12:42 pm
In Sense-Making theory, identity is a central priority. It assumes that who people think they are shapes their behaviors (how they enact and interpret events). I am an information architect; I have always identified myself this way professionally because it describes information architecture as my core practice, which I simply think of as making the complex clear (Wurman). It defines my professional and personal ethos – and it does so to an extent I was not even aware of until recently.
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.
Next entries »
