I recently had a meeting with our Testing department, and the thought came up again: within a company producing software, User Experience and Testing persons are both strongly dedicated to a product’s quality. Of course, developers are, in the best case, too. Still, as my friend Liz, our former UX analyst, often reminded me when I was a web developer:

You are not the user!

Fighting my brothers

Representing the user within a company means getting into lots of work-related battles.
My first ones were against fellow developers. My programming colleagues weren’t “us” anymore, facing challenges together under the banner of the code. It was “the users and me” against “them”.

In my developer role, I had to evaluate the feasibility and the cost-time factor of features; my response to the “strange requests and utopian feature designs” of our UX person was often “No”. Depending on the technology, I was able to provide one or more alternatives that would also work.
As a UX designer, I was suddenly in the position to ask my former crew for these strange features. That’s when I faced the infinite – and worth being admired – willpower of developers (resembling that usually attributed to dwarves in fantasy stories). That’s when I had to make use of my own programmer strength against them. Not yet painful, but highly interesting: I was confronted with replicas of myself, knowing maybe more than I should about the technical background (“Did you create a class for that? You did, right?”).

Knowing that friction breeds greatness, I carried on with convincing and winning my developer colleagues for my new cause, the user’s experience. It surely was a positive aspect that we’ve all been working closely together for years.

Fighting authority

When I dealt with our principal stakeholders (mostly from Management) as the user’s advocate, I had to

• admit that I was being even more a pain,
• cope with the fact that I probably always would, in this position.

I had to accept it as an important part of my job.

I told my bosses “I have to disagree once again” and “I don’t think we should do it like that” many times.
Was I going too far? Should I just have shut up instead?

Time gave me the answer: Hell, no!

Pointing out at dust piles under the carpet is the first part of what I’m paid for.

The second part is to elaborate the best way to clean them.
I learned that the messenger delivering bad news wasn’t likely to be shot at if she stuck to reality and objectivity.

The path

While continuing being a pain, I pushed my coworkers into thinking harder, developing great ideas to overcome the issues I revealed on their way. I see myself as a sort of trainer, helping people generate great usable software and shaping our path to success.

What about you?

• Do you believe you are a pain in your job? Why?
• How do you manage to keep a healthy balance between being a pain and still go on well with your colleagues?

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

Less meetings
I tend to reduce meetings to a minimum since I believe most of them are wasting my time. I have nothing against a good brainstorming session or a longer project kick-off gathering. (Preparation, moderation, and documentation are keys to a productive meeting and should be provided.)
Sitting numbly in a poorly aired room with 9 other people, everyone knowing the others are bored except for the two who are vividly fighting over the choice of a button instead of a link, is definitely not efficient.
The reflection process occurs quicker when you’re arguing with yourself – hopefully. In most cases you will be able to make a decision at the end, enabling you to go on with the next step.

Less communication
Since you are both the sender and the receiver of the information you communicate, the loss of information on the way from your brain to your colleague’s brain is minimized. Explaining complex ideas occurs rather seamlessly inside your own head. Although you may need to write down things for yourself to understand them better, you’re still lucky you don’t have to make them fit into your co-workers vision of the world.

More standards
No-one messes up your files!
It also means you can establish standards, templates and whatsoever you need for your daily work, without having to share, discuss or justify every change.
You manage your team’s image in the broadest sense. You’re in control of your efforts towards your goals. (Already been caugh singing “I did it my way…”?)

No personnel management
You don’t have to decide about your subordinates; you won’t curse your team leader twice a day. You have responsibility for only one person, and fortunately, it’s you! You will gain time while not bothering about organizing personnel meetings, and you’ll be able to reduce friction between your team member(s).

More ownership
Everything that comes out of your team is produced by you. You are the one who’s responsible for what you deliver – good or bad. I believe that in this case empowerment helps building a notion of responsibility, thus strengthening the will to become better. Endorsing responsibility leads you to improve yourself; embrace it!

Further readings

• Leah Buley’s material on being a UX team of one
• Scott Berkun’s article “Why you should be a team of one”

Would you like to become a team of one? Why, or why not?

Usability timeline
First I listened to the keynote by Franz Koller (User Interface Design GmbH), who talked about the roots of usability in the work environment. He pointed out that the word “Usability” slowly gets replaced by “User Experience”, which covers a broader range of expectations towards a product. Franz also showed the iterative quality of a UX professional’s work and the difference phases of the process: analysis, concept, prototype, test. He emphasized on the fact that interfaces have to be designed for the users to have fun and interact together at the same time, possibly with the same device. As an outlook he gave us to think about the merging of the worlds: reality and virtuality converge and melt into each other with cross-platform applications, mobile identity, augmented reality, etc.

Usability and communication
Then I took pleasure in Claus Wagner‘s vivid presentation about communication between human and machine. Claus compared the ways of communication between people with those between a human being and a device. With lots of examples he showed that the interactions are alike, regardless of the person or machine we interact with. (Raise your hand if you’ve never ever talked to your computer!) He also warned about the dangers of the technocratisation of media: technology shouldn’t be systematically seen (and reinforced) as superior and humans as eternal newbies.
Seeing the process from this perspective will lead the (UX) designers to plan for humans, even if they are interacting with a machine, and to take the rules of human-to-human communication into account, moving one step further than “just HCI”.
With a nice card game outside the session, Claus showed the visitors how a UX professional is like a pilot, who has to keep an eye on many different factors to do his work efficiently.

Bits and pieces

• There were many companies and schools presenting their work and discoveries parallely to the sessions, and I had the chance to chat with Ingo Pokora from NETFORMIC GmbH.
• During the talk about usability patterns by Michael Gerlinger (WidasConcepts GmbH) I was relieved to hear that other people also have problems establishing names for their patterns among their companies.
• I saw other interesting presentations, met people, got to see some art exposed on the walls to complete the experience.
• Many companies present at the event are hiring UX professionals and graphic designers, so have a look at them if you’re seeking work in or near Stuttgart! The event’s sponsors are listed on the WUD’s website.

Conclusion
The World Usability Day in Stuttgart was definitely a great event and I got lots of ideas to take home with me and incorporate into my daily work. It was completely free, so everybody who had time could attend.
If you are on the verge of deciding what to do with your future, you may consider becoming a UX professional, an Interaction Designer or like. These people will be given work even more during the next years (decades?), as the need emerges to define interactions between humans and machines in new and meaningful ways.

Paper prototypes, low-fi and high-fi samples were pasted on the walls. Books, personas, surveys and other deliverables laid on the table.

My trainees got some time to figure out on their own what to do in case of a web application crash. Did they want to restart the app? To provide an error message?
They presented their concepts to the audience afterwards, explaining why they choose a specific solution. They came up with nice ideas, e.g. “It’s not an error, we’re just currently updating”!

According to their professional background, they focused on providing technical details about the crash and steps to check the browser’s health (developers), or on the Support team’s reachability and the system feedback’s wording (consultants). Some formulated their ideas with words, others drew the interactions. We discussed the pros and cons, and met a lot of aspects that also play a role in the design process (technology knowledge, expert users, multilanguage support, etc.)

At the end of the exercise the brains were ready to convert the information – about UX in general and UX within the company, visualized with a presentation – into their own way of thinking and with the colors of their own experiences. And “experience” is what it’s all about, right?

The space factor
Whether you’re sitting at your desk in the office with all of your preferred office supplies, or you’re just trying to get an idea out of your head before going to sleep in your bed, you only need a pen and a piece of paper to do the job. You don’t have to get up and turn on the computer, you don’t have to beg your boss once again to buy this expensive prototyping software. You can carry you prototype with you around the house and the office effortlessly.

The time factor
Sometimes ideas are ephemeral. Turning the computer on and starting the appropriate software – how long does it take? Do you need to wait until some drivers are feeling ready on your machine to begin to get things done?
Or are you a perfectionist and tend to optimize your drawings before you even finish to insert all of your ideas into the software?

The dirt factor
Are you tired of people discussing designs at your workplace and constantly pointing at your monitor, leaving blurs and fingerprints on the surface?

The cost/eco factor
I use already printed paper left from the printer’s ramblings and unwished sheets to draw on (containing no confidential information, of course!). First, they’d go to the bin anyway, since they’re unusable for anything else having a longer life. Second, I like to draw only on one side, so I can compare the pages directly without having to flip them. Third, the sheet’s way leads to the trash can after I’m done and if I have moved on to a digital prototype.

The interaction factor
I have noticed that an informal drawing on paper rather invites people to interact with. It is possible to touch it, to write on it without compromising its holiness (as if digital was “carved in stone”). People can add modifications and notes without feeling guilty or the author of the prototype feeling hurt.

The distraction factor
PowerPoint presentations ideally should look nice. Your paper prototype has to be useful.

The upgrade factor
For some reason I like to believe it’s easier to take a paper drawing to the next level if needed (e.g. to scan it or to redraw it in a drawing software) than to really start over with a document that’s already digitalized. Applying Agile, I don’t need to beautify every concept I may produce – only the one or two which will be relevant for future work.

The reminder factor
I almost never forget what I thought and wanted to tell the stakeholders when I’m showing a concept I’ve drawn myself. Somehow, the same concept, digitalized and maybe even printed aftwards, doesn’t support this.

So  I hold a presentation about our User Experience department and its work. I explained what UX is and what responsibilities and activities are related to it. I spoke about the UX workflow in the development team and the role of the UX Designer (me) in the making of our new platform.  We looked at samples of personas, task flows, use cases and acceptance criteria in detail. Finally I reported about the training “Designing complex applications and websites” at the Usability Week in Berlin last week, and what I learnt from the cool sessions with Lynn Pausic. My colleagues came up with interesting questions, e.g. “How many developers can be kept busy by one UX professional?”.
I chose to display some real work on the walls to make the experience more practical. There were documents used in the daily work like design concepts drawn on paper, low-fi interaction design sheets, or full-grown specifications.