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 blessingsI 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)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 "
Designer – "Oh… I see you've got the old one."
<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 h2ly 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 sheetsWhen 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 fireFortunately, 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
WindowInfoincluding a new button 'Save' →
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")
ExpandingWhen 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.
ConclusionWhat 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 ;-)