ChangeOrder

Dirty Little Deadline Tricks

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...

Secrets of UX Design Productivity from Google

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.

The First Point of Failure

The brochure cover design and rough layout were easily approved, you've proceeded to layout and typeset beautiful copy written by a freelance writer, €”and the client hates the copy. It's all wrong.

The changes that he described to you over the phone require the writer to create a new draft. Then you'll need to replace the copy through the brochure with a new content structure that requires redesigning the inside completely. And based on the copywriter "missing the mark," which you don't quite agree with, now the client's thinking the overall concept for the cover may need to change as well. And of course, they don't want to pay for the changes outside of your current estimate...

"But I told him that he needed to read and approve the copy before I'd go to full layout. He said he was too busy / on vacation / (insert client excuse here) and that he trusted me / my staff / my freelancer to do great work..."

More often than not, there is always a first point of failure in a project where an issue like this comes to light. It could be a late approval that influences your delivery date, a round of concepts that the client dislikes, or a misjudgment of exactly how many hours you'll need to deliver that killer Flash advertisement.

These points of failure can be traced back to concerns that rest outside the traditional "design process." Failure is an important and inevitable part of the creative process, often leading to truly breakthrough design solutions. But when major failures occur during the business processes of a project, you can get knocked right out of business.

In this above scenario, the first point of failure was the desire to please a client, no matter what the cost. Wearing your account management hat at the expense of your project process can trump the controls you keep in place to ensure that you don't have to work over your time estimate. While it's tempting to mold your progress to your client's availability, there's always a point of diminishing return (and profit) for the graphic designer. This becomes even more risky in a creative agency setting, where thousands of dollars in staff time can go out the window without client approval at key milestones.

Other common points of failure occur when:

• The creative agency or designer isn't able to enforce boundaries around each phase of a design project. This usually emerges from entering into a project outside their area of expertise without having lived through what it would really take to fulfill the job profitably. In smaller projects in print and online, missteps can result in rework and added time and labor. In large-scale web design and video projects, a lack of boundaries can lead to absolute failure and huge costs amassed to start projects over again.
• The client doesn't want to work within the project boundaries. This can happen because the client didn't disclose there were multiple stakeholders within their company that had to approve each round. If the designer or agency doesn't ask the client about the need for multiple rounds of approvals and changes, they may feel uncomfortable penalizing the client by asking for more money. And like above, the client can feel like they are a hinderance if they aren't available during important approval rounds and want to keep the project moving towards an absolute deadline. There's an endless list here of reasons why the client can strain against an agency's process, and if the designer or agency doesn't stand firm, there's usually no going back.
• The client doesn't understand what they're asking for. They may have never handled a project in the discipline they've been asked to manage. The process you've been tasked to take them through baffles them (branding and web design being the usual suspects). Questions about their business strategy, business process, brand positioning, and sales methodology percolate out of your design work and open new areas they haven't grappled with fully. The design brief may become invalid partially through a project and require scrapping progress and starting over--something every client loves to hear.

While these kinds of situations often seem an inevitable part of a designer's life, they can be eased by making sure that you do the following:

• You have properly researched and digested the business problem in the creative brief. And by digested, I mean that you've thought through, validated, and proposed focused solutions for the client's business problem in advance of any design work. Without the proper context and frame around the business problem, your design won't hold as much weight in the client's mind. In advance of writing the brief, you may need the client to fill out an intake questionnaire that fully examines the kinds of things clients may not have thought through (such as brand positioning and sales process methodologies).
• You devise and keep to a workflow during your entire project--and make your client continually aware of the schedule and their ongoing responsibilities. If the client doesn't know they're on the hook and accountable through the entire creative project, you have no authority to make demands when things go sideways, both in pushing schedules out and in asking for more money. On the flip side, if you haven't properly planned your project out and uncover all the unknown variables, you're on the hook if it impacts your bottom line.
• You keep within the boundaries of the proposal. I have fond memories of developing elaborate pitches at big agencies to try and land projects ($20K time investment). Then, when the work actually came in, we'd show five concepts instead of three at the first round, and then produce an extra brochure design or two if we were feeling nice ($5K). Most smaller creative agencies and solo designers can't afford to throw this kind of money out the window, and it trains clients to have expectations of their design firms that exceed the boundaries of profitability and professionalism.

Strangely, the larger the project, the more that the actual process of designing almost seems to be a mere fraction of the work necessary to make clients happy.

What are points of failure you've had in your design projects? What did you discover in the process that made you a better designer and a better businessperson?