How can I make my UX work more "fun"? [closed]

Question

I work as a User Experience Specialist at a relatively big company (400-500 employees), I sit here all day mostly cranking out big UX documents telling other people what they should do with their interfaces. Documents such as:

• interface guidelines
• interface requirements (before the project starts)
• competitive analysis
• heuristic reviews
• usability test report/analysis

This is really starting to bore me. I'm used to working in agile environments where I don't have to document every freakin' thing, where I can just tell the developer my observations, he notes them down and fixes them right away (or maybe dive-in myself and fix the issues since I'm a developer as well). These guys I work for now have a (almost) waterfall approach to project management.

So any idea what I can do to make work more fun in such environment? and do you guys even enjoy writing these documents? I just want to tell whether it's something wrong with me and the career I'm persuing in UX or in this particular job.

Answer 1

It seems like the work environment isn't that interesting for you, and I would suggest finding a start up or a small company to work for. But that doesn't seem to be the question. So here are some ideas to spice it up a little:

1. Design your documents. Add some color, lay it out on a grid to give good example images. Take a look at skype's brand book for inspiration. Its got a great layout and really goes above and beyond to present the guidelines needed. Practically only internal users and contractors would see it but it has polish and impact on anyone.

2. Write a book or blog. You are writing a lot, why not share that wealth of knowledge. You may have to alter it or get permission but knowing that these documents will be seen by other UX professionals will help. Not to mention you could make a few extra bucks.

3. Try to do something new. See if you can create a new law of UX, see if you can push the boundaries in some way. See if you can get your company on the forefront.

4. Try to win an award. You can submit your work to the MEX Awards, or others.

5. Make 'em laugh. Spice up your docs with some light hearted humor. Still get the information across but make it fun! If you take another look at Skype's design book you will see that it has so much fun flavor and tone in its copy as well. It makes reading through the boring material fun and readers end up reading more and retaining more.

6. Speak at schools. Your work should allow you to give talks at a local design school.

Answer 2

I would definitly recomend Steve Krugs book "Rocket surgery made easy". Just like his first book, "Don't make me think!", it's a pleasure to read and you'll get some new views on things. This might be the closest approach to agile usability engineering.

He suggests that you schedule regular usability tests (once a month at first) and involve developers and management to these events. Make sure that this becomes a happening that people want to attend. Get some snacks, combine it with a lunch event, etc.

It is also important to involve these observers in the decisions. Have a quick debriefing after every test, and agree on 10 items to fix before the next round at the end of the day.

This is obviously a getting-started book, but you might find some tips on how to loosen up a tight routine like you describe on your place.

Answer 3

• Make your big UX documents smaller by using cartoons.

I'm serious.

Usability test report/analysis - Show a map of the key routes through the site, with 'Users get stuck here'.
Competitive analysis - Sketch key features of competitors, sized by relative importance.
Interface requirements - Draw a cartoon with the different types of users/stakeholders, and the same world seen through their eyes.

As long as your artistic skills stretch to drawing stick people, you can get your message across faster and with more creative fun for you by using hand drawn images. Don't use clip art. Don't consciously try to be funny. Just focus on what quick-to-draw sketched illustrations will best make the key points.

Answer 4

Change a job dude. I mean - seriously.

UX specs are the thing of the past. If your company is still doing them, they're doomed.

Answer 5

It sounds like the main problem is that you're dissatisfied with the organization's bureaucratic, documentation-heavy process; you've worked elsewhere where talking face-to-face and actually working on stuff gets things done faster than writing and passing around Big Documents (which often don't get read).

Trying to convince a company or a project team that has an entrenched "waterfall" mentality to even consider some iterative and agile ideas is difficult (I've tried).

So maybe start small: Try proposing a Lean Documentation or Agile Documentation strategy for your internal UX materials. The goal is not to "eliminate" documentation -- obviously there are things that really do need to be written down -- but to cut down the number of documents and to simplify them:

1. Try to focus on recording only what your audience really needs;
2. Use documentation tools that encourage iterative editing and collaboration;
3. Do away with elaborate formatting;
4. Use the written word only when appropriate (e.g., retaining specific details for the long term, recording design rationale for future reference, or explaining something complex to many people); where possible use diagrams, illustrations, interactive things like what-if spreadsheets, etc. And some things can be communicated perfectly well face-to-face, on the phone, or in a presentation.

For example, rather than writing up a formal usability test report, suggest instead that you sit down with the designers and developers to explain the problems you've found, and then write down and keep track of those issues to be corrected using a defect tracker like Bugzilla. (This also makes it easier to track what has been fixed.) Keep your problem descriptions short and illustrate them with screenshots.

Consider introducing a wiki, if your company or team doesn't have one. In my experience it's pretty hard to motivate people in a corporate environment to actively contribute to a wiki, but if you put all of your UX material there (and only there), team members will have to check it out, and then they'll probably love the ease of editing and collaboration.

I very much like the suggestion of using cartoons and illustrations to keep things short. A 200-page text-only document surely won't get read but a 30-page document full of pictures might... and maybe what your target audience really needs isn't a document at all but something else, like a high-fidelity prototype.

(By the way, this answer is too long to be a good example of Lean Documentation.)

Answer 6

You're working at a relatively big company, which also has its advantages. There are lots of other people around, are there any tasks you could delegate? There might be someone else who actually enjoys writing, and focusing more on your actual skills could make you more valuable to the company. Are there any students around looking for an internship?

Answer 7

You could start trying to sneak some of the techniques from this 'gamestorming' book into your requirements gathering, etc?

Answer 8

Work with a few teams to create some consistent working examples of how you want the software to look/act/behave and let the software speak for itself as a living piece of documentation. Maybe take a few screen shots if need be to explain some concepts or practices in further detail. This should be a much more conveyable and engaging way to document your practices. Let's face it, no one likes to "read the manual," let alone write the manual! :)