Design, per definition, is purpose. Whether product-, fashion or graphic; design solves a problem. Unlike, say, art, which is about expression if not downright ambiguous in nature.

“Good looks” is something you can slap on something, say a car engine, but that won’t make it run smoother. Or a dress perform better. Or a sign more understandable.

Instead good design is researched, seamless, and sometimes opaque. If it’s only one thing good design is calculated. Previously mentioned dress is thus more about cuts and fabric rather than an extra meaningless but edgy zipper.

There is no one calculation or solution to get there, there is no one process. In dynamic environments adapting and adjusting processes and methods are necessary. Increasingly so; shit change.

Which is why a solid process foundation, a base, together with the ability to change with it might be a designers best asset. I’m sharing mine with hopes that someone may derive something positive from it. Here it is:

The 90s were one of the absolute best decades ever, and if you disagree you know deep down in your heart that you’re awfully wrong and should be ashamed of yourself.

You may remember some of the following if you happened to find yourself in design back then:

Internet startups everywhere

Methodologies everywhere they were

“Experimental design” a ticket to get in

Let’s focus on the first two.

The IT bubble-economy had us all sitting in our Aerons contemplating how to separate everyone else from ourselves. Because we were totally not doing essentially the same thing. Part of this dissection were the buzzword-packed methodologies.

Once all the shifts of paradigms, real-time outside box thinking, so on, was decoded, it had created thousands and thousands crafter blurbs covering more or less the same process.

To paraphrase:

To expand: explore and understand the problem. Because they are problems. Device a solution, because you learned the problem. Act on said solution, because you deviced the perfect solution by learning the problem. Follow up with examine how that solution went, and correct if necessary.

Prerequisites

Whether through the process explained here or otherwise, there’s a few things that need be defined before initiating a project. For clarity's sake, when further reading this documentation, but mostly because preparation cut short project startup-phases as well as cut short early headaches. Fitting exercise for any downtime.

No single project is the same as the other. As such no single process should be the same.

Before taking on any project, and initiating any sort of process, planning is my friend. That, and common sense. A week's job may not accommodate, say, extensive market segmented research. Or require an Art Director. Or absolutely require one, but due to unfortunate financial constrains can’t afford one. Suddenly the scope change; and with it, the process.

Financial- and time constraints aside, even before they’re defined, having a sound design strategy should account and prepare for a bit more than just the frame one is to operate within.

Experience (and monitoring others experience) tells us that these kinds of projects includes these types of productions and solutions. By being aware-, loosely mapping or even documenting common scenarios with its requirements there is fodder adaptable to rapidly structure roadmaps and plans for upcoming projects.

Getting rough estimates this early on doesn’t just aid planning purposes for team-leads and project owners, it allows for fast- and arguably better budgeting estimates in conjunction with it.

Before initiating a project having a number of shared beliefs, expectations and even pre/post-plans internally defined in advance is key for smoother internal workflow as well as better informed client communication.

A couple of questions worthy of processing:

• What constitutes a finished project?

  “When it’s ready to be used” might come up as an obvious thought, but that might cut short your purpose. A simplified example: a website can be produced, up’d and ready to launch with a click. But how’s traffic coming in? Were ads, events, promotions, so on, consider in the scope? If you were specifically tasked to just make a website, sure, “when it’s done”, but were you tasked with something like increasing sales through a new website the tasks finality look a bit different. Add to this the quantitative measures following a project launch.

• Are there long term strategies?

  As mentioned just before in task & planning, by mapping out project trends (say, by looking at results internally or externally) one may also see needs to develop and incorporate new proven strategies to respond actual problems.

  Granted it’s too early to create a roadmap before a project is undertaken but monitoring trends help predict the more efficient scopes.