This is the first part of a serie dedicated to one of my biggest career moves. I started at my current company as a web developer and, after a few years, I was given the opportunity to become a UX designer. I’ll turn the spotlight on some major differences I noticed during the progress of my mutation.

Paper blessings
I discovered the benefits of sketching long ago. Sketching complex ideas has always helped me understanding and communicating them. A sketch is also a good way to make sure you’re on the same page with your interlocutor when discussing rather theoretical subjects. When it comes to remember a concept’s unwritten details, I haven’t found a better help than a sketch yet.
I’ve seen accurate memories swept away by nicely formatted digital meeting minutes. I’ve also seen the very same piece of – in the meantime worn-out – paper with a drawing on it travel through a whole company, from the employee who generated the sketch to the boss making a decision based on it. On the other hand, I’ve witnessed inefficiency due to the disappearance of paperwork, and great confusion due to its ambiguous relation with time.

Developer A – “Is this the new one or the old one?”
Developer B – “I don’t know exactly… I thought this was the new design, but there’’s no date on it.”

Developer – “I’ve implemented it according to this spec” (waiving with spec in the air)
Designer – “Oh… I see you’ve got the old one.”

In my daily work as a web developer, I used sketching to simulate the interaction between flexible and fixed GUI components, to visualize hidden amounts of padding and to identify others’ CSS classes (before Firebug was born). I remember those “<tr>” and “<td>” written on top of boxes while I was learning HTML tables; later I drew the same sketches to explain how to build those tables. I’ve been strongly reminded of school while defining a container’s coordinates relatively to a button’s edge on the x and y axes of the stage.

So it was obvious to me that I’d never even want to reach the paperless state at my desk some of my developer colleagues seemed so eager to achieve and preserve. Still, I sometimes wondered why Liz, our User Experience Analyst at the time, was surrounded by all sorts of sheets. She was carrying a bunch of them at any time, she took a few of them to every meeting and basically never left her desk without a pen and a piece of paper. (The latter being an advisable habit.) The possible explanations I had in mind went from a little almost-messy tendency (sorry Liz!) to the widely spread desire to keep useless stuff instead of throwing it in the bin. I imagined a better system could have helped her managing her growing piles of paper, and I thought that 2 months of good ol’ GTD would probably have gotten rid of both the cause and the consequences of the “paper problem”.

That was until I got her job.

Holy sheets
When Liz left the company, I inherited a big shelf full of heavy-packed folders, additionally to the digital files. Survey questionnaires and results, annotated screen captures, ideas, user research protocols, paper prototypes, user flows in big format… were things I could call mine. (Nobody else had a claim on them anyway.)
I was focused on interaction and technology, principally working towards Development, rather than towards customers and stakeholders. Thus there was still hope that I wouldn’t succumb to the paper flood Liz had had to fight.
I placed the first paused interaction design ideas for the first 3 features in a folder. My “To do” pile grew exponentially, almost none of its parts ever becoming a “Done”. I had to divide it, so that every feature would be isolated. I discovered I had better keep my files ready to grab and to present at any time, due to the spontaneity of the internal meeting schedule.
I had to answer the question “What is the current concept state of feature XYZ?” precisely and shortly, without fiddling with unsorted sketches. Oops.

Suddenly I saw myself doing exactly what Liz had sometimes done: rummaging through the depths of a single concept’s printed history, desperately seeking an answer. When asked a question, I had no more time to build and trigger a search statement in my brain or to foster the code later.
So additionally to providing the latest document containing the (agile) design decisions on demand, I had to know them, together with the pros and cons enunciated during the last meeting.

Taking notes, until the paper catches fire
Fortunately, I never lost the habit of taking notes while attending work-related gatherings. I see taking notes closely related to sketching, helping connect memories to tasks and concepts.
In the past, I wrote important things down, like

• info (“Boss will be on holiday from 12 to 20.08″),
• own tasks (“Find a way to reduce the framework-generated row heights before Friday”),
• or to immediately capture my thoughts about a specific topic (“Create a component inheriting from WindowInfo including a new button ‘Save’ → WindowEdit“)

Although I’m not keen on writing down meeting minutes (who is?) and make sure they’re coherent, I can do that too. I can extract everybody’s next tasks and communicate them adequately.
The new challenge was now to simultaneously

• present design concepts
• moderate ensuing discussions
• document decisions and steps in-between; make them fit into a time plan (“Place a single dispatch status at once in Release 1″, “Place multiple dispatch statuses at once in Release 2″)
• keep track of generated ideas, ranking from small improvements for currently discussed functionality to unrelated killer features
• provide solutions and ideas on the fly
• record references and resources related to one topic (“Talk to Mara about the archive, then organize a meeting with Michael to discuss the technical possibilities”, “Look at the file ABC.pdf at part 3 for requirements for new tracking functionality”)
• identify my own to-dos, which are not necessarily dictated by the discussion’s outcome (“Redefine the interaction and generate a high-fi prototype to convince boss next time, but first get real data from the database from Oliver”)

I no longer could talk confidently about the code that I knew every part of, like you know the rooms of your house and their contents. Instead, I had to struggle to keep people focused, to advocate the user’s rights and to deal with the what-ifs in real-time.

Expanding
When I was a web developer, I usually came out of a meeting with a few next actions. Now, I fill 5 or 6 pages with all kinds of subjects of different nature. Afterwards, I can’t just program and commit the solution to mark the task as “done”. (By the way, I had to drastically reduce my expectations concerning a job being “done”, since an information architect’s job is never really “done” or “finished”.)

As time went by and my field of activity grew, the little and bigger features had to find their place within different encompassing so-called “projects”. I added colored labels to my first suspension file folder and got a second one for support. I’ve banned the paper monsters – like these printed sheets resulting from the testing of some print functionality – into separate folders on the new shelf I had to find. I keep the really big features (the ones that wouldn’t fit in the suspension files) in their own folders. I can’t get rid of many layout trials on paper, since we may need the wisdom they showed us later. Of course, I could digitalize them if I had lots of spare time at work.

Conclusion
What I’ve learned: cope with the fact that the User Experience Designer’s position includes paperwork. If I don’t sort the papers on my desk on time and meticulously, I’ll be submerged by waves of sheets within a short time, losing tracks, tasks, and time (and thus money). I need solid methods, an established and reliable system and the appropriate infrastructure to manage my job efficiently.
…So basically, it’s a bit like programming within many projects, in different languages and with lots of commented code

Exactly what you always wanted to know…

1. I’m able to write with both hands
   At the age of 10 I decided that writing with my right hand “only” was not enough. I taught myself how to write with the left one. Today I regularly switch the mouse’s side, together with the primary and secondary buttons. I don’t notice differences anymore while working with image editing software.
2. I’ve got a green thumb
   Plants just don’t die around me
3. I dream in 3 languages (at least)
   French, German and English are all mixed up: people in my dreams are very skilled and change their language in the middle of a sentence. It becomes funny when old french friends can speak german perfectly at once.
4. My favorite drink is water
   Plain water, without bubbles. I’m not afraid of asking for water from the tap, regardless of where I am.
5. I like reading before going to sleep
   I enjoy the experience a lot but I just wish my fingers wouldn’t always get that cold during the winter.

I felt like a pilgrim – a mix of awe and expectation – as soon as I knew about my coming to the CeBIT this year. I’ve never got the occasion to visit either the CeBIT itself or its host city Hannover before, and I’ll give you a quick report.

Preparation
I spent a reasonable amout of time gathering information about exhibitors and products I’d like to see using the online tool myCeBIT. I subscribed the newsletter and took a look at the mobile website of the fair.

Voyage
Despite a strike of the train workers on the day of my departure, I had no problem travelling from Ulm (south of Germany) to Hannover (north of Germany) on Friday 5^th March.

Accomodation
I got a room at the Hotel Plaza in the city center and I’m totally happy with this choice. A special mention goes to the breakfast buffet, which offered a vast range of different tastes in a nice atmosphere. They even have waffles during the winter!

CeBIT highlights
Since the media coverage of the CeBIT is pretty high out there, I’ll just pick some personal highlights out of the big memory bag.

On Saturday morning (6^th March) I arrived at the fair after a short trip with the train. Of course it was crowded, Saturday being the last day of the exhibition and also the day most people don’t have to work on. Still, I was amazed at the smooth flow at the entrances and the wardrobe, as well as within the halls. I had absolutely no waiting time. The CeBIT’s organisation team did a great job there!

I discovered the cool post cards containing sound and video from HoneyPearTree.

I had fun tracking the CeBIT Twitter-Spy and almost caugh him once. Hunting, armed with a cellular phone in the middle of such a big exhibition, made the serious side somehow spicy. Talk about triggering the play instinct… (Am I ready for Geocaching nao?)

I was a pleasure to meet the big fluffy fox (alias Ludovic Hirlimann) at the Firefox stand. Firefox stays my favorite browser; I’m using it since a bunch of years and I still love it

While I was having a special glance at eReaders, I noticed there were always many visitors around stands selling… books.

The german magazine com! was giving away tons of software DVDs, magazines and mobile phones for free throughout the whole day.

Sightseeing
Unfortunately there was no time for a guided city tour for my first time in Hannover. That’s why I chose to buy the brochure “The Red Thread”. It provides information about lots of noteworthy locations in the town, all linked with a red-colored line on the ground. Following the line was a nice way to explore Hannover on my own, and I’ve found many interesting places to take pix. (Stay tuned to my photoblog to see them.)

In conclusion, I can say it was a great weekend and recommend the CeBIT and the city of Hannover.
If you’ve been there, how was your experience?