Tags to Richness

Having studied film in college and having made a few short films, the thought has crossed my mind once or twice, what if development shops made software the same way they make movies?  Imagine this scenario:

1. Assign a director, find the right writer

Today’s software has so many owners that the end result is often a muddled mess.  A product owner is the closest thing the software industry has to a director, but the product owner is often not intimately involved with every aspect of the process nor given the same kind of ownership as the director of a movie.

After the software director is chosen, they would then find the right writer, which in the software world would be the right interaction designer.

2. Pre-production, 3-6 months

After hiring the right Interaction Designer, begin the following tasks:

• Requirements gathering
• Conceptualizing
• Wireframing
• Site maps and flow charts
• Prototypes
• Usability Labs

2. Production, 2-4 months

This would be the development phase.  Notice the development phase is much less than the pre-production phase.  What would a product be like that spent more time nailing down the particulars of the design than time spent developing?

3. Post-Production, 6-8 months

This is the QA phase, the loop of finding bugs and polishing them.  Notice this is the longest of the phases.  And appropriately so, because this is where the software would be polished as close to perfection as time and money would allow.

Summary

The software industry can stand to learn a thing or two from the movie industry.  Unless you’re a Microsoft or an Apple, software today is often very messy, made by messy processes.  What would it be like if the software industry followed a similar process to the the process of making a movie?  I’d be willing to bet that the end product would be much more well conceived and executed, just as the majority of movies are today.

I’ve developed a design method I call showing the wrong thing as soon as possible.  The idea is this:  When I start a new project for a client, I have an initial meeting with them where I hear their idea.  I then go off and design the first thing that comes to my mind that fits their need.  It’s often not polished and not the right solution, but it represents a complete and concrete idea in higher fidelity.  I then hurry to get the design in front of the client.  What happens next is always the same, the client rips it to shreds.  And that’s exactly what I want them to do.

Humans are very skilled at noticing differences, it’s how our brain is engineered.  So when I’m showing a client something wrong, what happens is their brain freaks out about all the differences between what they are seeing in my design with what they are seeing in their head.  So the client’s feedback starts flowing like a river as they describe all the problems they see with the design.  I quietly write down everything I hear, encouraging them to talk as long and as harshly as they need to.  I take none of it personally.

This is how I am able to read my client’s mind faster than any other methods I’ve tried, by forcing their brain to point out all the flaws.  With all those flaws verbalized I can now easily go back and design the right picture based on the negative space left behind by the wrong picture.

Recently I was given a small budget to hire some freelancers to help with the large backlog of design tasks we have.  Below are some of the steps I used to find the right people.

1. Posted on a design specific job board

I ignored the general job boards like workforce services, craigslist, hotjobs or monster.  I went straight to authenticjobs.com, a very well known job board in the design community.  My second and third choices would have been jobs.37signals.com and krop.com.

2. 30 seconds and three folders: Yes, No, Maybe

I didn’t read the emails I received.  Instead I scanned them for a link to a portfolio.  Obviously if there wasn’t a link to a portfolio I threw the email in the No folder.  If there was a portfolio link I clicked through and could tell within 30 seconds of looking at their work samples if this was a Yes, No or Maybe.

3. First paid task is a test

You really don’t know what someone is going to be like and what their skill is until they actually do a job for you.  So I would hand the freelancer I was considering their first task, paid of course, and the result would tell me what I was getting into.  If the result was so-so I might ask for a second task and decide from there whether to keep them or move on.

Agile at my company tends to be a very heads down speedy process in which design and development are always producing customer ready work.  What Agile at my company doesn’t account for yet is any kind of long term planning.  We desperately need a “planning” sprint where-in the design, dev and business teams purposefully spend time on foundational and long-term needs.

In UX long-term needs are things like a sitemap, ux bugs, personas, a style guide and our primary use cases.  For the longest time I kept expecting someone from the product group to create or ask me to create any one of these items.  But they never did.  In our Agile process it became so easy to be focused on sprinting that no one bothered to think about or define where exactly it was we were sprinting to.

In our flavor of Agile, “documentation” tends to be a swear word not unlike the bad blood Agile has towards the word “waterfall.”  But the sad truth is good planning requires good documentation.  This is the fatal flaw of our Agile, in our effort to eliminate time-wasting documentation we also threw out the time-saving documentation.

How I’m doing my part

I known I’ll never be given a formal opportunity to stop what I’m doing and create a foundational element like a persona or a sitemap.  Instead I have to slowly build them and grow them over time, a little here and a little there.

I’ve forced my schedule to include what I call the 5 UX buckets.  I make what time I can along the way to slowly build and document the following foundational UX elements.  And as Dan Brown says in his book Communicating Design, these documents are meant to be living breathing documents.  So I’m ok with the fact that they are never “done” but are slowing growing and evolving over time.

My five UX buckets

1. Sitemap or content audit

Every time a new feature comes up no one can remember all the parts of the site that feature might impact.  With a sitemap I am able to build a mental model that significantly aids in the recall of every nook and cranny of the site.

2. Regular usability labs to generate what we call UX Bugs

Every other sprint we end up asking ourselves what should we do next.  Without the prior groundwork of regular usability labs and a backlog generated from them, we end up guessing in the dark about what we should do.

3. Personas and Customer Segments

For now this is a simple list of the types of people we encounter in our market niche.  What ends up happening is we talk about them off and on here and there.  And as we do I keep a master list of these features that slowly evolves as our understanding of our customers grows.

4. A style guide

When we are designing in some isolated piece of the site it’s easy to get caught up in a design that is unique to that problem but that ignores the consistency of the site as a whole.  Until now we’ve been rushing so fast to get something done that we haven’t had the time to create a proper style guide.  It’s easy to turn a style guide into a massive time-consuming inventory project that no one will end up using.  Instead, as I come across a reoccurring UI or graphics pattern that I know will be too hard to remember later, I write it down in a master list.

5. Primary use cases

What are the critical paths that have to work, and work well, for our customers to get what they came for?  The Primary use cases provide us with a way to prioritize the growing list of UX bugs we are generating from the usability labs.  I can quickly rank a given list of UX bugs when I know which interactions of the site are more important than the others.

A little over a month ago I had a budget to hire freelancers and after settling into a pattern with them, this is how I’m getting value from them.  For this discussion there are essentially two phases to design, the critical thinking phase and the polish phase.  The critical thinking phase deals with mocking and feedback loops until the key ideas are captured in rough drawings.  The polish phase is when the website’s specific aesthetic details get applied to these mocks, like line width, color, margin size, etc.

I’ve found that it’s really fast and easy to get critical thinking from the freelancers, but that the polish will take a significant investment of time and energy in the freelancer before they are where I need them.  The issue has been that because I have a limited freelancer budget and because the freelancers tend to have day jobs I end up only getting 2-10 hours a week of their time at most.  For now I’ve found it’s more valuable to keep them cranking out critical thinking in the form of mocks while internally we apply the polish.

This method is similar to how Mike Shinoda describes Linkin Park’s album creation process.

In the new version of our process we’re no longer making albums and then touring and then starting from scratch and making new albums we are just writing all the time so that is to say when we’ve got a collection of songs we think is an album we release it

Like Linkin Park, I am having my freelancers create a pool of fleshed out ideas.  And when the various priorities align I can easily take one, apply the polish and hand it off to the development team.

(Quote Source: Meeting of a Thousand Suns (Video Documentary) on the iTunes A Thousand Suns (Deluxe Version) LP)

I’m by no means an expert at this kind of thing, but I thought it’d be worth sharing the strategy I employed recently for dealing with a difficult situation at work.

The Problem

I want to do my best to avoid hurting anyone here, so I’ll be as vague as I can without losing the insights.  Basically we have a large project going on for our flagship product.  The project is in the conceptualizing and definition stages.  Our biz dev guy is driving the project.  The problem is that one of the lead dev guys got involved and started negatively affecting the project.  I could tell almost immediately that the project was going to quickly derail into a real messy battle of wills.  What to do?

What I did

I put my foot down.  In a series of email exchanges related to the project I tactfully made it clear that I felt strongly we were making the wrong choices.  I was specific and provided alternatives, and why those alternatives had value.  My boss has always told me that if you feel strongly about something, he wants to know. I knew this was an appropriate time for resistance.

I spent the weekend framing the problem for myself.  For the better part of a weekend I wrote a series of notes, thoughts, streams of consciousness and mock email drafts.  I didn’t intend to send any of them, they were purely for me to work through my emotions and clearly frame my issues in writing.  At the end of that excersize I felt like I had a very clear strategy for dealing with the situation.

I wrote a small set of strengths and challenges.  I basically made a mental model of the individual in question.  This list gave me a strategy on how to best navigate the individual.

Strengths of the individual

• Highly decisive and direct
• Highly skilled at getting a group to get things done
• Amazing depth of memorized knowledge
• Highly skilled at logistics
• No bullshit
• Very experienced at what they do

Challenges and what to watch out for

• Lacks critical diplomacy skills
• Does not pick up on subtle social cues or doesn’t care
• Passive Aggressive in communication
• Lack of thoughtfulness in regards to people and processes
• Has very low tolerance for the activity of thinking and discussing
• Kryptonite to creativity
• Not the kind of person who’s going to think about “why” we are doing something, only “how” we are gonna get ‘er done

Resulting strategy

• The individual is going to be harmful and unhappy in phases of projects that require creativity, cooperation and exploration of ideas.  Make sure to keep them out of these situations and focused on what they are good at, logistics and getting the final decision built.
• Use their bluntness to my advantage, as an alert that maybe I am thinking too much and just need to act at that moment in time.
• Learn from them about how to get things done faster personally and with a group

I stopped taking it personal.  Once I had this strategy in hand I was then able to stop taking the individual’s actions personal and I stopped getting emotional about it.  As the following week progressed I was able to clearly identify a behavior they exhibited and categorize it appropriately within my strategy.

And finally, I discussed my conclusions with my coworkers.  I’ve learned the hard way that even when you’re right, others have to come to that conclusion on their own before they will embrace it, you can’t just tell them.  I met with each person I felt needed to know what I had discovered and asked what they thought about what I’d concluded.  Within days I saw the effect, they started seeing the individual’s actions more clearly and I felt that the potentially harmful situation was being managed.

Conclusion

I’m obviously leaving out a lot of detail here and over simplifying some things, but I hope I have been appropriately tactful and presented something useful.  If you’d like to know more details please contact me directly.

At my job I have to be the web designer, the print designer and the flash animator.  So it’s easier for me to stay in the one drawing tool that makes the transition between those tasks easiest.

That doesn’t mean I’m poo-poo-ing Fireworks, I’m not.  Fireworks is freakin’ awesome.  It’s just not the best tool for my specific role at my company.  But rest assured I spend time in Fireworks weekly so I’m ready for the day when I work at a company that has Fireworks as it’s primary work flow tool.

So until that day, here are the main reasons I still prefer Illustrator over Fireworks.

1. I’m always Flash ready.  If I’m always in Illustrator then I’m always sharpening my vector drawing skills, which means I’m always ready to create artwork for Flash.  Bitmaps do not work in Flash for the simple reason that they are HUGE in file size, let alone the fact that you lose all the transformation abilities of a vector image.

2. I’m always Printer ready.  We all know bitmaps make horrible printing compared to vector illustrations.  Besides that, who would ever work in 300 dpi when they are doing web design?  Maybe the iPhone’s retina display will change this.

3. It’s the best damn 2D vector tool out there.  People always tell me “But Fireworks does vector too!”  That’s like saying WordPad lets you write term papers just like MS Word.  Yea Fireworks does vector, but why would I purposefully hurt myself like that?

4. I’m just way f-ing fast in it.  I spend time every week trying to make myself just as fast in Fireworks, but you can’t argue with the speed I can go in Illustrator.  I’m definitely at that point where there is no delay between idea in my head to realized drawing in Illustrator.  It will take years to get that fast in Fireworks.

After repeatedly and methodically constructing comic strips on a monthly then a weekly deadline for years, I started to get the hang of it.  I learned to write out a bunch of ideas to discover the best one.  Then I learned to rough sketch the panels until I found the mix of drawings that told the joke best.  And finally I would put on the polish with detailed ink and shading.

Interaction Design wasn’t too much of a leap after constructing strips for so long.  Like comic strips, the best way for me to start designing an interaction is to first write it out.  I write scripts that tell the story of the user performing the critical actions of the design.  Then I follow up with sketches (wireframes) to find the right delivery and finally add the polish with ui and graphic design details.