1) Solve Problems

FOWD highlighted how a problem-solving approach to design can improve projects and client interactions immensely.

Paul Boag talked about turning clients into problem-solvers, asking them "does this accomplish goal X, X, and X?" instead of "do you like this?" This shifts the conversation away from opinions and onto results.

Ryan Singer gave a simple example of how solution-oriented design improved four little links in Highrise. Using basic principles of design and an understanding of user priorities, he was able to turn a seemingly-clear set of options into a ridiculously clear set of options.

Near the end, a panel of designers and developers discussed the practice of explaining problems and the resulting design solutions to the entire team. This allows other team members to understand the value of the solutions offered, and it gives them the ability to work with and improve on your ideas.

2) Be The Expert

Again: you're solving problems with your designs. And in order to justify those solutions, you need more than creative spirit or a good eye, you need to be the expert in conversations about the design. This means a few things:

a) Be ready to answer "why?" about your design decisions. If you have a good answer, it helps everyone understand the problems and the process involved, and it turns conversations into collaborative problem-solving efforts. Also, be willing to admit which of your decisions were less important. Not every design detail has solid reasoning behind it, and confessing this gives team members the power to adapt the idea.

b) Research. Mike Kus talked about spending time up front doing research: Look at the current user flow, look at similar brands, look at related visuals and ideas, and be ready to show that you understand the product and the problems. Paul Boag split "research" into two categories: Be both thoroughly versed in the aspects of your trade and to know when to refer back to the experts. Depending on the situation, it might make more sense to justify your decisions with the expertise of others than to go it alone.

c) Have a process. A common view of designers is that we're flighty, mysterious creatives; we take a handful of hours, go into our secret design caves, and return a week later with a comp. However, being the expert means explaining your methodology up front and moving through a defined process. Experts need to have sane, carefully-considered process behind their designs, and clients should expect to hear about it before design begins.

3) Creativity Is Not "My Job"

Creativity isn't something designers generate alone in their secret caves, everyone and everything can provide creative solutions.

During the design/dev panel, someone said: "...if you think you have a monopoly on ideas, visuals, or features, you're dangerous." I agree: designers are trained to manage creativity, but by no means do we have the market cornered on creative ideas. All team members should be able to propose ideas, with the caveat that suggestions should revolve around solutions and can be discussed from a problem-solving perspective

Nick La talked about his illustration style, and revealed that much of the creative detailing is done through mixing and matching patterns from nature, gift wrapping, signs he sees, etc. Nick controls the structure of the piece, but the details flow in from loose associations and lucky finds.

4) Understand Cause and Effect

When you start designing, design without limits: brainstorming anything-goes produces unexpected and wonderful results, and it's a hallmark of really creative design. At FOWD Mike Kus urged us to tell big stories, Hillman Curtis inspired us to shoot for the big ideas, and Nicholas Felton showed an a concept that snowballed into a big masterpiece. But big thinking requires caution, because it ends up dictating development decisions, client expectations, and project scale.

It's your job as a designer to understand the cause and effect of design decisions. This might mean noting that a layout will be tricky in CSS, or that getting live results from a server could take serious development time or hardware. Three factors (as I see it) go into this:

a) Experience. The more people you work with, and the more you do, the more you'll see these issues coming and know how to work around them or take different directions. You get this experience by working, trying out new things, and by cultivating a healthy interest in all aspects of your projects (including the buildout, development, writing, and management).

b) Communication. As you're coming up with your ideas, shoot them past a developer or manager for thoughts. If they say "that's really hard," you can compromise or brainstorm a little more. Paul Boag discussed the client-facing side of this, which is positively responding to client ideas but explaining the tradeoffs and difficulties in play.

c) Compromise. If you're already designing to solve problems (right?) and you're already getting insight from other team members (right?) you'll find that you need the ability to quickly scale and retool ideas. Ideally, as you're designing a concept, you should keep some alternatives in the back of your head. This practice will give you quick, good suggestions when a client or team member wants to adjust the design.

5) Get Out Of Photoshop (When You Can)

At FOWD, we heard two great designers talk about spending as little time in Photoshop as possible. Why?

Ryan Singer explained that PSDs eventually get thrown out anyway, so spending hours tweaking and polishing your designs might be time better spent improving the working copy further down the road. Mike Kus also moves out of PSDs quickly, noting that designer time is more valuable when spent in concepts, research, sketches, and communication.

Thoughts?

Half of this is what I heard, and half is what I sort of constructed around it. Did any Viget Inspire readers go to FOWD and have different takeaways? Or, does anything here need more thought from me? Let me know in the comments.