Category Archives: Me, me, me!

Sustainable file system hygiene

“Does anyone have good tips/tricks for file structures? I keep losing track of my projects.”

I hear this question or a variation of it frequently. Just got asked today during a skill share session I was in with the other OpenNews Fellows so I thought I’d write this up.

It is very easy to generate data (whatever form that data comes in — photos, project files, databases, notes, etc) so data accumulates rapidly. No matter how systematic you are about putting it somewhere, your context will change or the volume of data will exceed your ability to keep it under control.

It’s a challenge for everyone whatever their occupation or workflow so how do we deal with it? Here’s my solution:

  • Projects
  • References
  • Archives

Let me elaborate.

First, what problem are you solving? The central question is not “How do I keep stuff organized?” it is “How do I find this later?”, so your goal is findability above all else.

Rule #1: Everything needs a place. If you don’t have a place for things to go, they will go wherever and you won’t find it later.

Second, your data deluge problem is cross-platform and ubiquitous so you need to solve the issue for that scope, not just for one platform or device. It’s not just how you nest and name folders on your laptop but also how you organize things on Dropbox, Google Drive and so on.

Rule #2: The system is inherent to YOU, not the place where things are, it just gets mirrored there. It needs to be abstract and simple so it can be applied wherever you go and wherever your things might be. Over and over again.

Third, we are talking digital things so presume a file system will be involved and acknowledge that a file system is a constrained hierarchy which forces a certain set of decisions to be made.

(Yes, you can always search, great, but you also want to know where stuff lives so you can put more stuff like it along with it. Also don’t minimize your natural desire to want to browse because you will want to do that too.)

Rule #3: It’s a file system and hierarchy is inherently insufficient because categories evolve in meaning over time. Deal with it.

Your system is going to evolve over time so more important than what is the system, is how are you going to respond to the change over time. I have 5 active projects now but what will happen when two of the projects end? What and when do I back things up? And so on. Also:

Rule #4: Hygiene is about maintaining a healthy state. Only you can tell if the state of things is not healthy or going downhill. It’s also up to you to put the time to get things back to shape before it falls into a complete state of disarray.

Ok, back to the solution:

  • Projects
  • References
  • Archives

This is no surprise to anyone who has practiced Getting Things Done, but even if you haven’t, this is a sufficiently good place to start. Why does this work?

  1. Too much nesting is bad (for your own recall and because some backup reasons – some systems really choke with 8+ levels)
  2. Too much scanning is bad (for your own speed/efficiency, long list of projects you are not really working on won’t help you find things quickly)
  3. Trash/distractions are bad (also for your own speed/efficiency), but random stuff will accumulate. You don’t necessarily get to put things where they belong as you are working with them, but you have to at some point.

Projects

Whatever you are actively working on. Be descriptive. One folder per project. Anything that involves more than a step that has a supporting set of data/files needs to live in there.

“But I have 100 projects!” That’s not an organization problem, that’s a lack of priority problem. “But I don’t like mixing personal and professional!” ok, create those two folders and then put your projects in them – but remember, the more nesting/complexity, less likely to stay functioning and healthy.

Usage frequency: You will use what’s in this daily or every few days until you are done with the project.

References

This is a library; things you need to consult on a regular basis or review periodically. They don’t need to be cluttering your projects but need to be accessible and readily available. I have a copy of all my important IDs and docs in folder here. Also all my purchased fonts live here.

For example, when I finish a professional project, I move it to a folder in references called /Portfolio. I know that when it comes time to update my resume, LinkedIn profile or website, I can review this folder for the history of what I’ve worked on since the last update.

Usage frequency: Occasional or on recurring basis in service of active projects.

Archives

I put all my backups on the archive folder of my home computer. I back up my various devices to that location as well. Periodically I check my computer’s download folder and move any software to a /software downloads folder in there should I ever need a previous version of an app. I put all my photos here. I have albums I publish to places and such, but every photo taken is put away here.

Usage frequency: Rarely if ever. This only exists for an eventuality but also helps you get rid of stuff from Projects and References that is not that important to your day to day but you don’t want to get rid of.

Over time when I check that References/Portfolio/ folder I find projects that I have no interest in ever talking about again so I move them to archive. If I ever needed to read my graduation thesis ever again, this is where I can go get it (Chances: 0.000001%).

Rule #0: A sustainable file system hygiene depends as much on your workflow maintaining the system as the organization of the files themselves.

(It’s last to make a point, but really, it’s the first rule in importance and impact)

If you focus on organizing, you can go down a rabbit hole of eternal taxonomization that will not stand the test of time because when you are trying to find a thing your focus is on the thing itself.

The file system really should reflects your workflow. Your workflow needs to include a) put things in one of those places b) put the right things in the right places c) move things between those places as the context changes and they evolve/change status d) give all the orphans a home when you come across them (and if there isn’t one, the trash is where it needs to go).


If you do this across all your various systems you will find that findability improves but you also become ruthless about what’s occupying your attention and as long as you use the same pattern over and over, and periodically restore the pattern when it starts to deteriorate, you can stay on top of things.

So you think you can dance

You made it. You are a Knight-Mozilla fellow. You are past all the self-inflicted anxiety of applying, interviewing and getting in and you are ready to start this thing. Now what?

Or you are considering and waiting until the 11th hour to put in your application. Or you are telling yourself the many reasons why this sounds like the coolest thing every but how you are not qualified.

I was you once. I did all of the above and I am here to tell you: DO IT.

What you want out of this

There are many reasons to become a fellow and one is unlike the other. To me, the fellowship was the right thing at the right time; as an experienced design manager with over 15 years of UX design practice, I had decided I wanted to have a more hands-on technical experience: programming, shipping code. Having accumulated more and more responsibility over the years, I both missed the satisfaction of shipping code myself and the depth of knowledge I like to have in order to manage developers. I was going to make this happen one way or another, and the fellowship offered the setting to do so (among many other reasons I can tell you all about if you ask).

Pick something; even if it seems only somewhat aligned to the spirit of the fellowship, apply. The OpenNews team is really excellent and will be completely honest with you about matching; don’t presume you are not a fit because you are probably wrong. They know better.

Shaping your fellowship experience

I asked several fellows about their experience and scarcely saw a pattern among them. Each fellow’s experience is distinct because it comes out of a combination of:

  • one’s goals, skills and expectations,
  • the culture, projects and work/team dynamic of the newsroom, and
  • whatever is going on with the community of nerds in journalism at the time (conferences, hot topics, talent pool, etc).

As you probably presume, the newsroom is constantly changing (breaking news! new staff! new business models!), the community if ever-evolving (new amazing things get open sourced every day! people change jobs! cross-disciplinary pollination!) and most of all, YOU change (because, humans) so picking something to start with helps keep you grounded, but not fixed in your path forward.

To me, how the fellow approaches the fellowship can be seen (and planned) from these three perspectives. (I framed these as questions to myself to make it easier to remember and answer):

  • Q1: What/how am I doing towards my main objective/reason for doing this?
  • Q2: What/how am I contributing to my newsroom/team?
  • Q3: What/how have I engaged with my peeps across the community?

You can use this to plan how you’re going to tackle these brief 10 months as well as to assess what you are trying at any given time (taking stock of what you have done and what you have planned next on a weekly basis is a good level of granularity and keeps you honest/sane).

Note: I treat this entire thing as a big experiment. That’s why I say “what you are trying at any given time”. Experiments are great; there is no pressure to get the outcome “right”, just to get to an outcome. In that sense, an experiment cannot fail. You set it up, you run it and you see what data you get at the end and hopefully you can draw conclusions and learn from it.

This helps with the anxiety that comes from starting something new, and the weirdness of doing something so unlike other things you’ve done before. It also helps make concrete what things you might try since OpenNews sets this up completely open-ended, where you can decide every single aspect of how you want to do things (more on that later).

Here’s my hyper-summarized list of answers to those questions:

  • A1: Immerse myself in all things programming; Learn how programmers approach projects and problems; explore any and all languages and approaches to building things for newsroom; contribute to projects primarily through code.
  • A2: Work on newsroom projects only (no independent projects); Bring in my UX practice development expertise to bear on projects and team process improvement opportunities; help optimize process by which apps are made by advising on workflow and governance (my strengths); finish things in a timely manner; collaborate with all involved.
  • A3: Remain constantly involved in the community; offer contrasting perspectives to UX Design on whatever I encounter new; hang out with people I don’t know, who do things I don’t know; Find out where they are and follow journalists, data scientists, developers, writers and researchers across media, government, academia and the arts; Ask why things are done the way they are in this space; Figure out what are barriers for entry to UX people and how to overcome them.

Nobody told me what the above should or should not be, which is why I am offering my example here. Knowing that the three different types of concerns should be related was not obvious to me at first, but once I saw that it became easier to reconcile them.

For example, *because* I am with the NPR Visuals team and they launch a lot of 2-3 week long projects that span graphics, tools (internal web apps) and full-on stories (external web apps), it didn’t make sense to have a separate fellowship-long independent project. It would have been distracting because of the short project timeframes AND all the traveling I have to do for the fellowship, and I didn’t have sufficient skills to really do it efficiently. Also, their variety exposes me to the breadth of approaches, languages and skills I was seeking, so better to focus on that then create something else I would not get support, pairing power or advice on unless I sought it out specifically.

Also, one item influences the other. I call out collaborate with all involved specifically because I knew the NPR Visuals team is an incredible group of highly capable people and I wanted to make sure I got to work with all of them in their various areas of expertise. Where some other fellows may not have such explicit goals around becoming a competent developer because they already are, that is pretty central for me, that’s why it’s so front and center. Consequently, when I participate in the broader community, my interest in/concern for helping the new learner is pretty obvious and I am constantly raising that angle when discussing things, whatever the topic.

I am very interested in how teams and organizations frame their objectives and how they ultimately assess what they do, which is why all this stuff above emerged naturally without me thinking about whether or not I needed to do it.

What the day-to-day is like

  • I work 9-5, Monday-Friday. And so should you. I’ve found the broader community of journalists, specially the coding kind, is really bad with their personal time management. Barring breaking-news that you have committed to working on (if that’s the kind of thing you’re focused on doing), do your work and GTFO.
  • I travel at least once a month. That’s a lot of travel, specially if you have people in your life you like to be with, like friends, a spouse, or children. There are events happening constantly (seems like every other day), so you end up speaking, presenting, facilitating and/or attending at least one in any given month.
  • Consequently, I spend a lot of time dealing with logistics. In my case it’s mostly due to having a 2-year-old I need to tend to and a spouse who does shift-work so schedule planning is very time consuming (as is booking flights, hotels, researching transit options, timing of things, etc). Making the time for this as work as well as filling out expense reports and such should not be downplayed.
  • I talk to people about what I am doing practically every hour I am awake. Twitter is very convenient for this and I am already comfortable there so it was an easy decision to use that primarily. It’s also a good match as 100% of the journalism nerds community is present on Twitter (Disagree? Fight me). This includes meeting new people, having lengthy debates and letting serendipity drive discussions that lead to projects, collaborations and more.
  • I write code most days. This is relevant because it’s my explicit goal for the fellowship. I know exactly how hokey it is to do this, but: Github contributions
    (I was working on an audience research project in May)

What you do, specifically

The NPR Visuals team works on many things, including daily graphics, storytelling web apps, tools and photo editorial for all of NPR. I work on whatever project the team is working on that week.

The capacity in which I work varies, but mostly it’s been playing a supporting developer role, pairing with the ever-patient Tyler Fisher and David Eads.

As a new developer, I have a lot of basic concepts I need to grasp, so I am not learning any one thing at a time; it’s more opportunistic: I need to do X, X requires Y so learn Y and keep trying to make X happen. Oh now it needs W, go learn W and come back. Oh now…

I spend a lot of time asking questions of my peeps and Googling how things work. I’ve learned that programming is many parts trying things out that sound sensible and then reading how to actually make it work on Stack Exchange (I’m only sort of joking).

I also have just enormous amounts of fun being silly with the process of learning. This is where being in an environment that’s welcoming to it (and therefore allows me to pursue my primary goal) as well as having ubiquitous access to the community of people doing similar work (via Twitter), creates a really rich and self-reinforcing cycle of learning, sharing and getting the positive feedback (building confidence) one really needs to keep going.

What’s really important is at the end of the day I’m contributing to work that a) actually gets shipped and b) is open-sourced. I know I lucked out with the NPR Visuals team because open-source and working in public is in their DNA, so that was a smooth transition.

But I was also unprepared for the neck-breaking speed they publish things, so getting in that mode has also been great. This is a list of things I’ve worked on in my 5 months of fellowship so far so you can get a sense of the kinds of projects I touch and what I actually do on them:

  • Look At This/Photo I Love: A Brother and Sister In Love
    Web app showcasing the story of John Fugelsang’s parents as narrated by the comedian, in the Photo I Love series for the NPR Visuals Look At This blog.
    My role: Paired with Tyler to build story using the NPR app template, implemented first multivariate testing for NPR Visuals. I touched CSS, HTML, app template, Google Analytics events.
  • Multivariate Testing
    Live experiments using a research method that allows users to interact with slightly different versions of the same page and assess which version people respond to more positively.
    My role: Paired with Tyler to plan and evaluate outcomes of multivariate testing across three projects. Created reports for test variables in Carebot and co-wrote lessons learned in comprehensive blog post. I touched CSS, HTML, app template, Google Analytics, data analysis.
  • California Civic Data Coalition Campaign Browser
    A Django app to refine, review and investigate campaign finance data drawn from the California Secretary of State’s CAL-ACCESS database.
    My role: I closed small issues during Fellowship orientation and at NICAR. It’s the first project that gave me exposure to the workflow and opportunities in open source projects for journalism, as well as meeting some of the smartest and funniest people in that space. Covered: Django, HTML, CSS.
  • Can’t Go Home
    Story about four Syrian families struggling to stay together during wartime.
    My role: Paired with Tyler/Aly to build story; Touched CSS, HTML, Bootstrap, navigation design, NPR app template.
  • Look At This/Photo I Love: Space Pix
    Web app showcasing a favorite photo of astronaut Reid Wiseman in the Photo I Love series for the NPR Visuals Look At This blog.
    My role: Paired with Tyler to build story. Touched CSS, HTML; NPR app template, Google Analytics events.
  • IA Summit Bingo (I was presenting at the IA Summit so decided to do this as a side project to learn how to work with Twitter bots and deploying a game)
    A bingo game played via Twitter using photos and hashtags. It generates a card from a spreadsheet of terms (hashtags and descriptions). Users interact with a twitter bot to request a card and submit their filled boxes by tweeting photos with the relevant hashtag
    My role: UI design and development, deployment, promotion at IAS. Touched Python, SQL, HTML, CSS, Twitter API, Twitter bots, AWS deployment.

  • Audience Research (not public)
    Assessment of performance of 6-months worth of NPR Goats & Soda stories for a specific target audience. Found correlation between type of photography and story subject among other interesting patterns that became guidelines for stories in an upcoming series the Science Desk is developing.
    My role: Google Analytics, data gathering, analysis, reporting and presenting.
  • Reverse2nsScreen
    Reverse Second Screen helps set the mood and context of a story through ambient sound and images presented on a secondary screen, while the user is going through the core story content on their mobile phone. Better suited for longer form features as it helps to set an enduring mood by creating a sensory experience that stays with the user throughout. Project done during SNDMakes.
    My role: UX design, documentation, presented the final concept at SNDMakes. Covered: HTML, CSS, JavaScript, JSON; video editing, device management/broadcasting.
  • NPR Concept Modeling
    Concept model to illustrate how NPR works done as part of NPR Serendipity Days (2-days of open time to hack at things). We accomplished a lot in the short time but the value of completing a complex model like this is dubious. The blog post expands on lessons learned and the whole process.
    My role: Ran the 2-day project, facilitating concept modeling exercise with two others. Covered: Concept modeling, content modeling, facilitation. Fun fact: all the whiteboarding for this became background for the NPR One ad (0:26)
  • Graeae
    Graeae is a tool to aggregate data about published web content. It includes a growing set of scrapers to collect data from Facebook, Google Analytics, and others, store, analyze and report on usage and performance across several criteria. Includes a UI for photo editors to evaluate quality of images used across stories so we can correlate photo quality and story performance.
    My role: Paired with David to build scrapers, perform data analysis, create reporting UI. Covered Python, SQL, CSS, HTML, JavaScript; data analysis, DB modeling, scrapping, RWD.
  • Lunchbox
    Lunchbox is a desktop-based suite of tools for newsrooms to create images intended for social media sharing. It collects 3 tools that provide photography watermarking with attribution, conversion of textual quotes into images and bulleted list of facts into images.
    My role: Paired with Tyler to combine three previously existing tools and wrote documentation to open-source the project during a 2-day code convening put together by OpenNews.

Other things I’ve done:

Why did I list ALL this stuff? Because my fellowship is not about a really big project, but a lot of small and medium sized contributions with different emphasis and I wanted you to see what they are like. Also because the things I work on vary in how they leverage all the expertise I bring in versus all the enthusiastic ignorance with which I tackle things (and how I learn from those experiences).

Your fellowship experience I am sure will be completely different!

I hope this is relevant to anyone, but I specially hope that user experience designers of all stripes—those with content strategy inclinations, UI design proclivities, service design aficionados, consider taking on this opportunity. (I did not come in to it with a programming background, just an explicit commitment to get into it. And look how far I’ve come in 5 months. You can too.)

The newsroom is a fantastic place to be (and I spend very little time talking about that in this post) and journalism is a domain that’s transforming rapidly, influenced by cultural and technological shifts. It’s a particularly great industry that’s ripe for design practice to make a contribution. It’s up to you now.

Back to Information Architecture

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.

Kaboom

Yesterday I presented at the DMI Seattle conference and I bombed. As Scott wisely points out: “Everyone is polite and tells [speakers] they were great, even when they bombed.” You know when you bomb. [edit] In truth, it was not horrible, but it was not great either. I haven’t received any feedback so it is also hard to tell. My point is, if you feel it didn’t go well, no amount of reassurance will convince you otherwise. [/edit]

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.

Make it happen 2011

Next week I’ll be giving a talk and participating in a panel at the Design Management Institute’s Design/Management Thinking “Make It Happen” conference in Seattle. I’m excited about this event because they’ve framed it as:

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!