As Senior Art Director, my approach to design can impact not only the final product, but the team I work with as well. Therefore, I’ll break down my design approach into “philosophies.” Some of these are about the process, some are about the overall attitude toward design, and some are just tips and advice that I have to constantly remind myself of when I’m burning the midnight oil on projects or hit a creative roadblock.
Here goes nothin'…
The thing about design you may hear often is that it is problem solving. A client is not going to redesign an app or a website or a campaign unless the current one is failing and they need an improvement. It’s more than aesthetics (though aesthetics do play a role, see Rule #2); it’s usability, experience, placement, adaptability, modernity, and all of those have to tie up in a nice neat little bow that makes the client happy.
Therefore, if I can think of how to go about those things, I do so by any means necessary. It’s a good practice to leave no stone unturned in the search for the best solution to the Client’s needs.
That being said, even though finding the solution can be a chaotic process sometimes, it’s still important to figure out that process in the early stages based on variables. Often, the process has so many variables that pinning it down into a narrow path means I’m going to leave something out. So the process is malleable: it depends on the project and the scope and the budget and the content. Is it an app with tons of user interactivity? Is it a site redesign that is strictly informational? Is the content going to be adminable by the client once it's launched? What’s the timeline? Is the Development outsourced or internal? Is the bar in the common area fully stocked? These are important questions and the answers to all of them will determine what the best approach to take is.
Regardless of how that approach might shapeshift by the project, there’s often one universal skeleton I have to my digital projects:
Dave Sim once said “First you get good. Then you get fast. Then you get good and fast.” When it comes to mapping out the process, designers should know how to think on their feet. It should be almost instinctual. The more you do this, the finer you hone your skills, the quicker the answers come, the quicker the process becomes mapped out in your head.
Design in and of itself is not art. As stated in Rule #1, design is about fixing a problem. Good design fixes the problem. Bad design doesn’t, or makes it worse. So I step back and think about if what I’m designing is fixing the issue the client has. For example: John Q. Client has an app that people read the news on. Their problem is that users don’t share their articles enough on social media. Is the design addressing that issue? If it isn’t, the design has failed and we go back to square one. It’s not like painting a portrait, but more like creating a blueprint for a house. Blueprints sometimes look pretty and sometimes they don’t, but in the end if the blueprints don’t address a staircase so people can go to the second floor, you're going to have to sleep on the couch in the living room.
However, all that being said, there is an art to being good at problem solving. In execution, in restraint, in initial presentation: a good designer can run through all that the way a composer conducts an orchestra.
Additionally, being artistically inclined comes in handy on the areas of design that have a strong focus on aesthetics, such as the User Interface, Brand application, or Iconography. But none of that matters if my solution doesn’t have a strong backbone to support it all.
It's healthy and stimulating to try something just a little different in a design to ensure you're not falling back on a bag of tricks (but it’s okay to have a bag of tricks, of course! Any arsenal is good when used wisely.) Maybe I play with motion on the page. Maybe I play with transitions from page-to-page. Maybe I’ll do the wireframes in color, to help get a jumpstart on how I’m going to approach the UI design. It’s always a good idea to push the boundaries of what is possible in Design and usability. Technology is always changing and the way you design will change along with it.
Just remember during this experimentation phase to keep in mind the project’s needs and scope. There’s an old saying in the literary world: “Kill your darlings.” Same saying can apply to design. If all the above examples don’t do a thing to enhance the project outside of mere bells and whistles, it's okay to get rid of them. (But a bell and a whistle once in a while is fine. Think of it as the garnish on the dish.)
Being holed up in a corner staring at a computer for 14 hours a day can make me forget sometimes that I’m designing something for a user. Not only that, I’m often designing it for a specific type of user. That’s important. One of the first questions I ask at the beginning of a project, if the answer isn’t obvious, is “what kind of user will this design be geared toward?” For example, if the design is geared toward Millennials, I might have a much looser approach to design, knowing that Millennials have a bigger grasp of how to navigate modern interfaces. However, if the design is geared toward Retirees, ages 60-70, I would have a lot more hand-holding on the design, and make the type larger, and make other design decisions.
We’re a team here. I’m not a vacuum. I have things I like and things that I fight for in a design, and I admit I might cry a little if something I really liked gets changed or requested to be changed. But as a designer and a director, I have to trust other designers. If another designer has insight outside the realm of my ideas, it's good to take that into account. It might be the diamond I’m looking for that makes the whole thing come together. You never know.
And so we cycle back to the heart of Rule #1: whatever the approach I take, just tackle it. I put on a set of headphones, put on some playlists, and tune out the world until there is a first draft done. There’s no better way to work out the kinks than just doing it and using it and seeing what’s working and what isn’t. If it isn't working, throw it out and start again. If it is working, understand why it's working and keep going, and build on it.
Well, that’s it. I hope this was useful. If it was, I’m glad I contributed to your life.
For my next blog entry, I’ll be discussing code and why it is a good idea for designers to know it. Stay tuned.