Hitchcock is a storyboarding application for iPhone and iPod touch. From photographs in your iPhoto library or on-the-go location shots taken with your phone's built-in camera, you can quickly built a multi-frame storyboard, animate it with voice over and pan-and-scan effects, then output the resulting frames to an annotated PDF for client review.
Continue reading "Spotted on the Web: Hitchcock for iPhone" »
The website finally went live last week, and the entire staff is throwing a party to celebrate! The developers are huddled in the corner with some microbrews, plotting how they'll splice into the agency intranet to add in a virtual dartboard. Designers are mingling with the copywriters and account people, clinking wineglasses and bonding over the ads they saw during The Office--did you see that amazing CG work, where the car dissolved into a field of flowers?
Not the best time to mention that tomorrow, you're scheduling a post-future meeting (nee post-mortem) to talk about how the project really went.
Yes, the job went way over budget — and the last thing they want to think about is who needs to take responsibility for it. Was the estimate wrong to begin with? Did the designer spend too long tweaking those page comps? How come the developer pulled so many late nights, when he said he knew .NET? Besides, they'll still be nursing their hangovers. If you're the one in charge, you get to take responsibility for the result.
Or do you?
Discovering how a creative agency fails to make profit on a project usually boils down to a series of in-process decisions that, while intended to be good, lead to cost overruns and errors. Isolating and clarifying those agency decisions role by role can be painful and time-consuming if done incorrectly -- but if carried out in the right manner and in a group setting, a post-future meeting can galvanize a team and bring them closer together. By being aware of how they've behaved in the past, they'll be able to see repeated patterns and anticipate ways to stop them from happening again.
A post-future meeting affords more than just saying, "Well, next time we'll do it better." It can give your staff real visibility into how everyone's jobs are interrelated. Those dependencies are what cause true profit on a creative task. Agency professionals get budgets and hourly estimates of what it'll take to do a creative task, but those estimates can be severely influenced by staff interaction. Day-to-day miscommunications may seem like they're out of managerial control, but they aren't. Fostering dialogue and collaboration is what truly makes profit possible, especially on large, multi-phase projects that continue over a series of months.
Even if you're a solo-flight designer, answering the following questions after completing a big project will help you take a dispassionate look at how you're doing business.
Continue reading "How to Conduct Post-Future Project Evaluations" »
Many designers, when they get a strong business process around their studio practice, like to stick to the waterfall. There are clear boundaries for how each deliverable is presented, the client has a set amount of time to respond with feedback, and everything hums along on its merry way until the final piece is printed, goes live, etc. For trivial projects, the waterfall is just fine.
Then there are the rest of your projects: the ones that seem to veer off cliff after cliff of unconsidered demands. The projects that strain, and very often break, the carefully laid schedules and plans that protect you and your client from late work and overbilled projects. Waiter, did I order the scope creep du jour?
Most often, I've been watching these situations arise because the actual deliverables -- the Web site we were tasked to create -- was simplified into a list of pages. Such an itemized list showed a fundamental misunderstanding about what we were tasked to create. Not a Web site. A Web system.
When I was a designer, as opposed to a design manager that also happens to design things, I would always chuckle inwardly -- in a kindhearted manner -- when my creative director, art director, account manager, copywriter, or CEO would tell me to give 110% on every project.
You'll never hear those words out of my mouth. The concept of giving 110% is misguided, and not just for the illogic of exactly where that extra 10% comes from. (Your sanity?)
It's hard to do your work profitably unless you plan for giving 100%. So I say, limit yourself to 97%. The last 3% isn't the meat and potatoes of the work. It's polish. And it's usually where the profit gets burned up on your job.
Giving of your personal time in a self-sacrificial desire to meet a corporate goal is 110%. But in those circumstances, time is the only thing you have to sacrifice. Time is the easiest commodity to give away, but many agency professionals forget it's also the most valuable. It's much harder to keep things at 97%.
One agency that I worked at would dole out an 110% Award for those who had put the most effort into their job in that month, or demonstrated something that showed they went "above and beyond" the level of service anyone would care to expect. I recall being nominated for said award once because I put together a new business PowerPoint with voiceover over a very long weekend, capped by an overnight and an 8 AM team presentation. Bleary eyed, tired out, they patted me on the back and let me leave a little early so I could sleep it off, then be in bright and early the next morning for the pitch, Round 2. (Ding.)
The same agency noted above would assign us very short timeframes for projects in an attempt to keep the projects profitable. "Go ahead, take as long as you want! But the comps are due in three days." Really, if I gave 110% on this project, I'd need a cot in the corner, a personal chef and masseuse available at all hours, and a Schnapps IV drip. Neither of the three were ever forthcoming.
In those situations, we designers on the creative team banded together and hatched what I can call here, posthumously, the 97% Rule. The rule, put quite simply, was save the polish for the very last moment in the project and only allow yourself a narrow window in which to futz around/clarify any small layout problems. Otherwise you'd be there until 11 PM, kerning merrily away, every single night. That's not sustainable.
You'd think the work would suffer. But it didn't. What suffered was your pride, turning work in for multiple rounds of review without perfecting every last detail of every page. There's nothing that drives us designers more insane than turning something into our client's hands knowing that a few details still aren't right. And knowing that our clients won't know it. Sacrilege.
But when you think about it, giving up control of the microdetails until that last round frees your mind and elevates you to make sure the concept and layout are sound. The designers got strategic very quickly, and knew how to battle for the idea first, the layout second, and the micro-details last.
Thankfully, I've been able to shake this 97% habit at subsequent agencies, where the Ford Factory assembly-line model does not predominate. However, in estimating projects, I had to re-account for those extra hours past concept where we would get out the towels and start polishing the silver to a bright glowing sheen. But certain bread and butter projects just don't require 100%. There's no way anyone will ever know you gave 97%. (Except another designer. So don't put it in your book, okay?)
And the 97% rule doesn't hold up well when you're talking about truly artistic projects. A great idea executed well (at 97% percent) can be trumped by a great idea executed fantastically well, with care and attention to every aspect of its being, right down to how the jute strings are tied on the Japanese binding of the annual report that you had to letterpress-print using only wind power and ink derived from crushed Goji berries...
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...
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.
Recent Comments