Devise

The results are in, this phase is where design happens. (Not to be confused with production, the practical design process that is phase 3, where graphic is the design applied to the solution).

The previous step examine the actual problem. With an accurate picture of a problem in mind, the purpose and goal of the current step could be described as follow:

-> With better results from the research, the more obvious the solution
-> The more obvious the solution, the easier the design.

The opposite holds true as well. The more vague research the less obvious solution. The less obvious solution the more t*rd polishing patching up needs be done. The less desired results.

Before the very, very common rushing into what may seem like sketching up obvious solutions (I know, I’m eager too), there’s one incredibly important part I insist need to be done.

I will be mentioning some paths to solutions but first this one very important thing: Holistics. Inside and out.

Holistic (out)

Perhaps the most important segment I know of design: taking it all in.
All of it.

Sounds simple. But...

1. It eats all the time and effort
2. To onlookers it yields seemingly no result whatsoever all the way up until everyone’s disappointed and frustrated.

I really can’t stress the importance enough.


To some this idea of an approach might be new, and expect instant kickoffs straight into production by exploration through trial.

Very common. I understand the reasoning, who doesn’t like instant gratification combined with engaging all teams? However I’ve find the more intuitive and efficient design comes from this less common approach.

Read on below...

Before determining a technical or creative solution...

In short this encompassing view means mapping-, understanding- and finally considering every single aspect of a product before solutions are devised.

This because of a long, long line of correlating actions.

To metaphorize:

It is in our natural interest to start figuring out A, to then move on to B.

When done with A we’ll share A with the rest of the people learning the alphabet so they can start devising up words.

But this means that we don’t really understand how to work the most efficient with language because we’re constantly have to revise the scope.

Gee. Thanks a lot, B.

The more we found out, the more we know we could have done better and/or in the first place.

Taking a holistic approach means figuring out the need of all letters before starting to compile words.

Granted it’s not for everyone and every time.

Commonly, especially as teams, ideas for every single aspect are thought out, sketched - and connected. It works for most, it’s a de facto in many regards, scrum/agile/what have you (all good in their place) do kickstart a project and fights delays in a great way.

However this path will often simultaneously deny that very important benefit of the all encompassing view:

Breaking projects into smaller chunks is necessary but before segmentation start I found the end result to be far more coherent, seamless and intuitive if one consider every single aspect of the complete solution first.

Obtaining an Information Design mindset (shameless plug: ...or degree...), structured dissection in way, really helps from the get-go. Learning graphics or whatever is for later (shameful antiplug: ...started with it). 

Initial ideas vs. Honed ideas vs. Overthinking

Simplify3
Famous buzzwords

My father used to say that my initial ideas were usually the best. When I started honing the ideas I derived from the very solutions most intuitive. He was right in a way: honed ideas were feature-rich and smart but often resulted in sprouts which had to be bridged back to intuitive in the later stages. Not optimal.

The first ideas are often right.

Except when they are not.

Paradoxically, dialectically, simplicity through initial reactive impulse isn’t always without obstruction in the reactive solution impulse. Detaching the solution from the initial idea can generate great design.

As an example about detachment of idea and solution; the early iPod vis-a-vis most other mp3 players around the time it was launched - but not for the obvious reason.

The ring on it was most likely never, ever really the initial idea. Because the idea was originally new (well, I think Braun had something to do with it before but let’s not open that bag) and likely not the absolute first thing that popped into mind when hearing the idea of creating a music player.

Just imagine:

“Hey team, we’re making a new music player. What do we need?”
 
A) Designer: a ring on it!
 

or

B) Designer: people say they want to be in control with as many options as a cockpit have at their disposal, but we know from research that the options are rarely, if ever, used, and tend to get in the way or otherwise spawn visually unappealing products to carry around. We need simplicity. So let’s draw up simplicity and take it from there, boys.

Keeping things simple is not just difficult - it is complex. Some loath it.

...and some add expansions and a wifi connection to it and call it a smart product...

Things in general tend to follow the path of least resistance. Simple really does it and something towards which to always aspire. Anything else is adding thorn to roses.

On the flip-side simplicity can be seen as a lack of control for the uninitiated. Perceived lack of control can turn messy. Good intentions, by the wrong people, can create grave missteps.

Once, at a large gaming company in Japan, producers insisted on showing everything and everything all at once under this premise. A common reactionary treat. Problem is that research has over and over again shown us that most don’t need everything. Most of the remainders doesn’t need all of the rest, and more rare everything simultaneously.

To sum up the overthink antidotes: meeting the true requirements and not the abstract fantasy of pleasing every single person and scenario.

Problem solving - User focused solutions

There is of course a multitude of methods for user testing out there. From focus groups, individual interviews, surveys or recording people in boxes. Obviously situational and requirement dependant, meaning picking any single one in particular won’t fit every process or project. Less to write for me that way.

User focused is, of course, also an incredibly played out word. Not entirely necessarily because it’s overused but because it’s not always understood. Even at the largest design places around I’ve heard “I think the users would ….” which rustles my jimmies. I can appreciate intuition, even prediction, but only if born from a substantial (very substantial) history of years of relevant and contextual researching.

An Information Design degree helps too.

My objection of intuition or prediction authority is furthered by relevancy. Previous research can be dated (despite the slow rate habits evolve) or simply not applicable.

Sidenote: a capital U “User” might benefit from being labelled “receiver” (or the very least “Consumer” in the sense of consuming our design).
We’ve since long muddled the intersection between printed and digital solutions.

This naming convention to include most of any produced solutions in the creative industry regardless of the decided media output.

Regardless of type, method and approach in testing:

  • Exclude all preconceived ideas of a users receivers behavior.
    Acquiring proper objectivity is difficult but generates the better findings.
    Who knew that coca cola is used as a rust remover.
  • Separating attitude and behavior in the findings.
    What people say and what they do aren’t always the one and the same.
    Too many examples to give.
  • Separate contextual use.
    Some drink coke, some drink pepsi.
    Some use rust removers, some use coke.

Tangent: zero is still a budget
If there’s no budget for proper user research there’s still a budget. Just ask people.
Old fashion perhaps. Ask regular people. Or wake a couple of sleeper account on forums. Ask, let simmer, weed out the know-it-alls and focus on the regular people. I occasionally get riled up about “there’s no budget for that” situations at agencies. As designer getting in the know should be taught alongside every design degrees.

Additionally, “Scenarios” and “Personas” can be deceiving in that they are leading, but if critically honestly manufactured indefinitely better than nothing because of budgetary constraints.

Holistics (in)

Any user focused solution (as a designer in the real sense: oppose to what?) would do well NOT starting without a holistic view of the project owner. As an Art Director every decision, every design, should come after a throughout view, nay, understanding of the full scope. And I mean full. Starting design without the start and finish of the solution means glueing pieces together. Take a few days, a week (if plan allows) to immerse in the full scope. I’d like to consider every possible aspect, every step and every part, before I even start talking design. Or even comment on current solutions.

Take the previously mentioned “I think the user would…” nonsense. Like any action there’s a reaction. And after that another reaction. Since abc would lead to xyz you need to consider 123.

Also in the holistic approach: strategy, planning, the unforeseen

Long term goals. Like expansions, or further building the solution over time should it be necessary. If it is, would xyz solution accommodate that or should we consider an abc solution instead.

Bonuspoint as a project and/or design manager: do we even have time and manpower for that, what with xyz being on leave for the holidays?

Design happens

Once we have identified the problems, done a proper problem search, looked at our extensive market research and the analyses, we have a substantial idea of the reasons why things are how / where / what they are, design happens.

Initial reasonings, formulas and solution

To recap: we know people relate to X in this way. They gravitate towards X in this way, and / but from our testing we know that they prefer things in X way. Our solution caters to it in X ways, but not in X way, and our competition caters to it in X way.

I have taken a holistic approach, outside and in, where have encompassed the full scope of the problem to consider an incredible array of solutions for X, the design has gotten more evident and I have fodder to devise the most efficient solution from this accuracy.

One final thing to consider in regards to our solution is the strategy we may have defined earlier / just did / will define later, which could shape things to come.

Just what solution gets decided is too specific to write about in this process sheet. (For inquiries about specific portfolio pieces shoot me an email).

I developed the complete Blick brand to specifically penetrate a very closed off luxury segment of safety products in japan, by focusing on "a present of safety of mind". Building the brand narrative, the products and everything around it as the "gift of safety" and luxury-level high quality proved successful and through sheer design blick is now available at high end retail department stores even where safety products aren’t normally sold. Designed truly changed everything.
Not without a number of explorations, proper user research and taking it all in, of course.

Idea package

The devised solution, i.e. design, might be crystal clear to us now but not necessarily so to whoever's paying. Unless it’s a self-started project.

Final Device

Every solution is different so it’s hard to write in specific what I do to test, hone and perfect a solution. Packaging it, shaving off excess and putting it through the gauntlet of elevator pitching.

It’s in our nature to please. Pleasing sometimes means adopting and adjusting, which I favor enough to put at the top of my resume. At this stage however, between devising and pitching, I’m vehemently against it. Iterations are always a possibility no matter what, but the more solid the solution the lesser revision would tear down its essence - and it would be foolish to start it off by giving a solution those encouraging properties.

It’s also a good idea to run the final idea with the people ultimately in need of the solution. More about that later.

Framing

Over the years I have found that whoever's asking for help may not always have their problem fully understood. Thus, when presented to, whomever might have a somewhat inherent skewed view of what a good solution should be or looks like.

Understandably presented material may then look like a solution looking for a problem. Like hearing an answer without realising you got the question wrong.

The more efficient way is to reiterate the problem, to correctly reframe the problem, before announcing the solution.

When framing in presentations I try incorporating as much data I can which have led up to shaping all choices and decisions. Not just for the current audience's comprehension, but future ones as well.

Not just interactive products. Logos, too, can use a little (albeit artificial) framing.
See them in the portfolio here

Over delivery vs extra delivery

With everything covered this far the proposed solution should be extremely clear, concise and targeted. Anything on top of that would just be over delivery. Which can be nice if done right and needed, but comes with some potential headache. More work, for one, but also that it can take away needed focus from the solution I’d be proposing. Getting hung up on details, especially those that were just icing on a cake, is not the kind of headaches needed now. Overdelivery.

That said sometimes a proposed solution means tweaking the initial ask.

Sometimes that have meant inception-esque pitches in a pitch.

 

An example of this is a pitch I art directed and produced with Amana, for JWT Japan. Their web presence needed a total revision. About half way into our solution we realized it needed to be split into three projects. 1) Their website, all the ways for JWT to showcase their work, so on, which would require a lot of technical hurdles 2) Our pitch to them of this, including short films both visually for the motional parts as well as instructional when showcasing functions. And 3) as a bonus extra delivery, a proposed part of their site while we’d update it all.

To sum up: extra delivery can be successful when the situations allows for it.

Pitching

Pitching isn’t exclusive to clients. For instance:

  • Internally it forces me to vocalize and (re) evaluate ideas out loud for myself.
  • Extra-externally, to a clients clients (the ones that really matter from a designer's solution creator's viewpoint) it is an excellent opportunity to gather feedback.

It is exclusive to the project solution and frame. It can entail a finished product or just the idea.

  • Presenting an idea and letting others visualize it is an excellent opportunity to gather unfiltered and unbiased feedback on expectations.
  • Presenting it with visuals is a great idea to set expectations (and possibly adjust if needed).
  • Pitching the final product is saved for very busy clients, or for extraordinary egos who are definitely right all the time, like yours truly.

It’s bit too specific to write about everything I’ll start off with just ideas.

The process of including prototypes or near finalized visuals into the pitches isn’t that advanced with a solid production process in place.

Internally

If I can’t back up the proposed solution, let alone convince myself that it would work, I’d have trouble convincing a client. Which is not to speak of their customers. It would waste everyone's time and efforts.

I dissect and try out my proposals out loud to myself and others. It allows me to troubleshoot all of the encompassing ideas in the open on good terms. You’re your own hardest critic, which is a good thing in the long run. Callout: Your Ego takes a lot to whip into shape. Thank god I’m self-whipped.

Not only does it weed out potential snags or fallacies that allow me get on the right track, it also comes with a couple of bonuses. Like:

- I naturally get more committed to my resolve, I can more easily stand by my decisions.

- I’ve prepared myself for the client pitch

It also help further define the project. Like with planning.

Dissecting my solutions includes mapping out all aspects and their connections. This also helps defining the actual full scope. When describing a project out loud you may realize it requires- or can at least benefit from certain additions or subtractions.

- As a result of mapping everything out I am often able to better estimate production hours, which mean I can plan more accurately.

- If I map out the complete production I may realize more about the requirements in resources. Whether they’re in manpower or otherwise.

-…and if I can map out this complete solution I might realize needed missing parts for success.

Sometime the internal checkoff also happens to be the client checkoff. Above is branding-, promotion design and website work done for a former employer. Sidenote: I enjoyed hiding some messages in those tigerstripes

Clients clients

Aah, the burden of a designer. A client's client matter more than the client. They are the receivers and user of the final product after all, but they are at the mercy of a client pitch and a ultimate a client's decision.

Bridging that gap is up to me, you or whomever's pitching.

Mercy is such a strong word. In reality a clients clients (let’s call them CsCs, that’ll shave off some precious seconds) feedback won’t just help in devising the more efficient end-product (sure, that may or may not get butchered) but also credit your solution in a client pitch.

CsCs pitches come in many forms. If the situation…

  • allowed for user testing early on there should be fodder to back up decisions leading to the solution.
  • Presenting an idea and letting others visualize it is an excellent opportunity to gather unfiltered and unbiased feedback. More fodder.
  • Presenting a final- or near final product (before a Cs pitch) allows for corrections if needed, and even better fodder if the results are as good as our research previously confirmed:

This is the actual problem.
This is the solution.
And they agree.

How could you say no to that?

Clients

There isn’t that much I can write about client faced pitches because they have all differed in one way or the other.

Sometimes it’s in a client's office for approval, sometimes it’s at a show to monitor reception. Sometimes you’re your own client and you’re presenting to a groups of journalists for reasons other than verifying ideas.

Preparation, research-backed material and our evaluated solution have been covered up to this point, laying the foundation to this step. Over delivery vs. extra delivery is a good measure to fight unfortunate outcomes.

Outcomes

  • Success

    Move forward to production

  • Part Success

    Revise depending on specific feedback. Problem recalibration or Solution recalibration.
    It is an ongoing process after all, and being allowed to remain onboard shows trust and belief.

  • Failure

    Hurl pitch and work into space (or see if there’s something to learn in there, time/cash-flow depending)

Lessons in failure

Even with methodological, research-backed impeccable sexy solutions pitches do fail.

Some reasons: the presentation not clearly conveying the benefit of the ideas and solutions, being too lenient toward serving the client oppose to their customers (i.e. didn’t properly stick to the resolve), impersonal client relationships (ask me about working in Japan), the way people felt that day.

Sidenote 1: As I mentioned before about pre-pitches I get invested and sold on my solutions (for reasons that aren’t emotional investment or similar egotistic pitfalls) which may seem devastating in failure. It’s not. Killing your darlings is nothing I have a problem with: design isn’t art.

I worked as a senior UI artist on FIFA WCS, an exclusive mobile game title for Japan. In-game soccer player cards revealed to be problematic as all the information they carried were hard to visually process, especially on certain smaller screens. This sparked a smaller investigation, which resulted in this presentation of a redesigned set of information using existing assets. Sizes, leading ones eyes, even more visual stimulation was addressed - all thanks to the initial failure.

Honest feedback on why things didn’t resonate is invaluable. Client relationship might dictate the level of honesty, but learning from mistakes avoids similar future missteps.

Even internally, failures and post mortems are useful as a mean to evolve.