Your email address:


Powered by FeedBlitz

3 posts categorized "Productivity"

March 23, 2008

Dirty Little Deadline Tricks

Morning Schedule

Here's some dirty tricks I've seen used to get solid work out of designers, and have been used on me in the past. But I don't recommend using them. You'll see why.


Go ahead, take as many hours as you want. Within a ridiculously tight timeframe.

I've worked at some agencies where you had free reign to bill as much time as you wanted to your live projects. The rub was that you only got a few days for what should take weeks. It's a dirty management trick: the shorter the project schedule, the more likely you'll take a profit on the project. So squeeze it out of the creative staff.

Hello, designer. Clear your deck so your design time doesn't get chipped away. Focus, focus, focus. We will keep you out of meetings, push off your other projects, and bring you food to eat. But you only get two days to do those three logos. With color studies. And recommendations for look and feel on two brochure concepts.

Sometimes designers forget, when you're juggling a ton of projects, that sweeping everything aside and focusing tightly on one single problem can exponentially improve your work, especially when you're working with a tight team that meets every hour or two to compare notes and inspire rapid progress.

I've seen great results come out of this approach. But also spectacular failures. And the failures would often happen when management got greedy and did this to the same designer over and over again, since they hadn't grumbled that it was unfair. They would also happen when staff got "nickeled and dimed" with small tasks from other live projects. Without enough clear space to focus, there really isn't enough time to succeed without dragging into evenings and weekends. And who wants that?


Every deadline is equally important. You can't miss any of them. Or else.

Some designers respond well to this lie. Others have it used on them so often that they start to see through it.

What's useful, when working through a project schedule, is knowing what deadlines are somewhat arbitrary and which are crucial to a project's success. Time can then be redistributed to ensure no one gets crushed.

What does a designer hate to hear? That they've lost time on their luxurious design schedule because of something they can't control. The client needs a few days to forge a new business strategy, but the publication date for the ad won't change. Your vendor needs two weeks to produce your beautiful design, and can't give you any wiggle room to assure quality. The testing plan for your Web site is forcing a few late nights, because your testing resources have a fixed schedule and if you miss your window, you'll lose days on your schedule.

Knowing when to negotiate is critical. This is a matter of quality of communication, and shared values across your company -- that you won't make a staff member or team fully pay for an internal mishap or a client's revised needs. Time is money, and this is where it can be appreciated.


Our internal project deadline is just as important as a client project. No leeway here.

Personal and internal project deadlines should always be somewhat flexible, within reason. Here's why.

There's a distinct path your design will take on a trip through your studio or agency, through their company and their partners and focus groups and testing. Sometimes your designs even make it out into the world. But the ones that really shine above all the others rarely appear without, say, a creative brief, some kind of rudimentary competitive analysis, research, and an understanding of the psychology of your audience.

The same thinking applies for internal work. Many designers and agencies think they can step around their client-facing processes to do a task because it's "for themselves." This is a fallacy. It will require just as much time, or even more, to negotiate a project through your own internal politics. This is the time that we usually sit around and wait for client feedback on our paid work. While we wait, they're working hard, reviewing the design and getting feedback from key stakeholders. In an internal project, we have to deal with that stakeholder feedback firsthand. This takes more time and energy.

There should definitely be strong general deadlines for internal work, especially when it results in something that needs to be delivered to an external vendor by a specific time. But there always needs to be more room to negotiate timing than a traditional client project.

That is, unless you only have two days to do those three logos. See above...

March 05, 2008

Secrets of UX Design Productivity from Google

Google UX

Last Thursday, I attended a free session organized by SIGCHI, Puget Sound region at Google Seattle HQ. Jake Knapp, a very well-spoken user interface designer, entertained a packed house with a speech on 17 tactics that he uses for creating strong UX work in "the flood" of projects that pour through his UX department from month to month.

Since Google is well-known for its sprint approach to application development -- working quickly in small agile teams, touching base often to assess progress, aiming for short-term goals instead of having a long-term target, changing course to aim for quick wins -- I was very interested to see what methods they used to keep their many trains on the rails.

Jake did not disappoint, and unpacked his toolkit to show how he managed his workflow. I can't fit his whole talk into a single post, so instead I'll share what seemed like the top four main topics and their highlights.


Have Strong Project Foundations

The UX team at Google is fairly small, so they need to choose what to focus on wisely. When they start new design projects, they ask the following questions:

How much does this project matter? Is there a value for the UX department to take it on if they're extremely busy with big projects?

What is the business impact? If it's an app like Gmail or Google's search home, improving the user experience could have a huge impact on Google's bottom line. Better focus some attention on it.

How much UX impact will it have? How complex is the system to represent? As an example, Jake showed a view of a sidebar menu from Google Talk versus a chart that needed to explain the whole process of going through a signup process with Blogger. A well-rendered chart could have a big impact on user experience for Blogger, so this is where they'd likely focus the most attention at first.

Is the whole team (a.k.a. internal clients) willing and ready to engage with the UX team in the right way? This question dovetailed right into Jake's next key point: when you're working with new clients, you need to know what their expectations for UX are, then aim for quick wins to establish trust with them and build up a strong relationship. This is consistent with what I hear from many designers that work in-house within a large corporation: behave like you've been hired as an outside designer, and approach each project with the same level of professionalism and client service.


Let the Code Be the Mockup

Since Google is in the process of getting great ideas produced quickly, Jake noted that they often whiteboard the implementation of an idea with the engineer, then let the engineer build it. Wherever possible, they reuse code and existing patterns from other applications, then iterate the user experience with actual working code to get to a result faster.

Often, this investment in application prototyping will pay off. Many of the Google engineers are strong designers as well and they bang out super-functional prototypes. This allows the UX design team to try it with users, find all the edge cases, then shipping it -- often saving a buck or two on engineering in the long run.

While I can't imagine taking this approach to a heavy Flash piece, it sure makes sense for the kinds of apps Google is looking to unleash on the world on a regular basis.


Be Smart About (Re)using Research

Within Google, researchers talk to each other all the time, ensuring that they don't duplicate each other's user studies. This research is then shared wholesale through the corporation.

When new research is required, Jake noted that they try to hit multiple projects simultaneously. Through field research, diary studies, and ethnography, they'll map out their personas and other necessary use cases. Then, as their project narrows into tangible prototypes, they'll enter into usability studies to confirm their research and ensure it's functioning well.

Research-based workshops were another interesting twist to their overall research methodology. In order to solve certain UX problems or brainstorm improvements, large teams will take part in an immersive research approach. The rough structure that Jake outlined was thus:

Research Immersion: 2-8 hours long, with 10-35 people

1. Show the group rough personas of the users they're looking to target.

2. Identify unmet user needs. As an open-ended exercise, everyone would write on Post-It notes their imagined needs. As a group, these needs were categorized into themes.

3. Brainstorm solutions. The overall group would brainstorm possible solutions to those top themes that seemed most relevant.

The work from the immersion session would then enter UX design. The most promising concepts would be mocked up and presented to an overall committee, which would critique the ideas. From these concepts, project managers would step in to help the UX team build a rough schedule and plan out next steps.


Designers Need to Create Memorable Presentations

Since much of what Jake presents is evidence-based, and much of his work is reviewed by a committee before it can be implemented, he's become expert in giving top-flight, simple creative presentations. His rules for getting a great presentation together were:

1. Have a singular goal for your presentation.

2. Start on paper, and see the big-picture story. His metaphor was, "Don't use a periscope to map the ocean."

3. Make horizontal and vertical storyboards. Jake showed a photograph of his presentation written out on Post-It Notes, from left to right. The "vertical" storyboard was a way to ensure that each Post-It, when pulled out of context, still made sense as its own contained message.

4. 3 words or less per slide. 'Nuff said.

5. Follow the 10/20/30 rule, per Guy Kawasaki. 10 slides. 20 minutes, even if you have an hour to present. 30 pt font for your text, though Jake advocated 32 pts or larger.

6. Be careful how you present mockups. Often, Jake would grayscale his tight designs, then slap on crappy graphics for the approval of the rough markups in PowerPoint to ensure that they were discussing the ideas behind the UX, not the design itself.

7. Drawings invite people to participate. Keeping the design work rough cues everyone to know it's a work in progress -- and treat it as such in discussions.

February 14, 2008

The Self-Critique Checklist

I've distilled my post "Mastering the Art of Self-Critique" into this simple 11-point checklist. Enjoy!

If you have any suggestions or additions for this checklist, comment away and if they're great I'll add them. Thanks!

Selfcritiquechecklist_2