{"id":12252,"date":"2017-09-15T11:37:42","date_gmt":"2017-09-15T10:37:42","guid":{"rendered":"https:\/\/marvel7077.wpengine.com\/?p=12252"},"modified":"2017-09-15T11:45:36","modified_gmt":"2017-09-15T10:45:36","slug":"approach-not-process","status":"publish","type":"post","link":"https:\/\/marvelapp.com\/blog\/approach-not-process\/","title":{"rendered":"It\u2019s an Approach, Not a\u00a0Process"},"content":{"rendered":"

A mechanical engineer by training, I\u2019ve always chaffed at using the word process<\/em> to describe something as messy and nonlinear as design. At MIT, I learned about processes for solving problems like how quickly heat moves through a block of metal, or how to calculate the impedance in an electrical circuit. To me, a process is something with a set list of procedures you have to do (draw a diagram of the system, then sketch the force vectors, then calculate the forces on an object in the X and Y directions, etc.)<\/p>\n

I remember the story my thermodynamics professor told about the importance of order of operations in a process. He described a professor who\u2019d brought a gun into the classroom (apparently rules were a little looser back then). The professor proceeded to point the gun at his head and pull the trigger. Then he lowered the gun and loaded it. This was a reminder to the class that the order in which you do the steps is important, and every step matters in getting to the final answer.<\/p>\n

<\/div>
<\/svg><\/div>

\n\"The order in which you do the steps is important, and every step matters in getting to the final answer.\"<\/p><\/span><\/blockquote>\n

What is this design process you speak\u00a0of?<\/h2>\n

The Stanford d.School uses this fairly straightforward diagram to explain the steps a design thinker goes through during a project:<\/p>\n

\"\"<\/a><\/p>\n

<\/p>\n

This diagram is often presented with the caveat that you can do the steps in roughly any order, and often need to iterate through many of the phases multiple times. It is a fantastic teaching tool, and helps simplify design down to its essence so beginners can learn. However, saying these honeycombs represent a professional design process is like saying my attempts in a barre exercise class<\/a> are just a simplified form of what professional ballerinas do.<\/p>\n

Tim Brown, CEO of IDEO, comes a bit closer to describing a professional workflow with his diagram of how design can transform organizations:<\/p>\n

\"\"<\/a>

The design thinking process as illustrated for Tim Brown\u2019s Change by\u00a0Design<\/em><\/a><\/p><\/div>\n

What\u2019s the problem with a formal\u00a0process?<\/h2>\n

When one has learned that good design has a certain number of steps, it can make you feel like you\u2019re a bad designer when you don\u2019t do every step for a given project.<\/p>\n

Weren\u2019t able to access end users to interview? #fail<\/p>\n

Didn\u2019t have a chance to brainstorm a hundred different Post-Its worth of ideas for that new widget? #fail<\/p>\n

Didn\u2019t have time to test out prototypes for that new landing page before shipping it? #fail Too busy with your next project to iterate on the landing page you just shipped without testing? #doublefail<\/p>\n

When one is working in a company or startup, things are often much messier than what you\u2019d encounter in a school or consultancy setting. The sense of failure that comes from not being able to do every step of a process can be immensely demoralizing, especially to young designers who are still finding their footing and often have the least ability to change the way an organization works.<\/p>\n

I think it\u2019s fair to say that every designer, at some point or another, will play fast and loose with her work. Whether it\u2019s because there\u2019s a tight deadline at work, or we\u2019re building a personal project that scratches an itch we don\u2019t care if anyone else has, we designers all have our times when we skip a step (or two or three). And I think that\u2019s okay. Let\u2019s not let perfect be the enemy of the good.<\/span><\/p>\n

If design isn\u2019t a process, then what is\u00a0it?<\/h2>\n

I prefer to think of a design approach<\/strong> to solving problems, which often feels like plain old common sense. Below are a set of roles I believe a good designer (from entry level to leader) can own in an organization, or at least within the slice of the organization she has control over:<\/p>\n

    \n
  1. Defining the problem<\/strong> a product is solving, and continuing to redefine the problem as time passes and the landscape changes.<\/li>\n
  2. Communicating the story<\/strong> of the product and the problem(s) it\u2019s addressing across an organization in order to inspire and direct those who build and support the product.<\/li>\n
  3. Building consensus<\/strong> from diverse stakeholders throughout an organization on what problems the team is solving.<\/li>\n
  4. Connecting product decisions to a larger purpose<\/strong>, like a company\u2019s mission, values and design principles.<\/li>\n
  5. Rejecting the obvious solution<\/strong> when a more nuanced approach could cleanly solve multiple (sometimes seemingly unrelated) problems.<\/li>\n
  6. Advocating<\/strong> for everyone who touches the product (not just the end user).<\/li>\n
  7. Curiosity<\/strong> about how things work with a drive to improve upon the status quo.<\/li>\n
  8. Seeking critique <\/strong>and feedback regardless of where it comes from, but with an opinion about whether it\u2019s relevant.<\/li>\n
  9. Driving a timeline<\/strong> by understanding the features to prioritize, and the teams to collaborate with in order to ship the product.<\/li>\n<\/ol>\n

    The list above is not meant to be comprehensive, and I expect to add to it over time. I\u2019d love to hear thoughts and comments from other designers about what they believe they own (or should own) within their organization.<\/em><\/p>\n

    <\/div>
    <\/svg><\/div>

    \"Designers are people who are curious, and relentless in their pursuit of optimizing what they\u2019re working on.\"<\/p><\/span><\/blockquote>\n

    While there are similarities to our methods, designers must be able to adapt to navigate the constraints of the organizations or clients they\u2019re working for, and the timeline and resources of the particular issue. Every project requires a slightly different approach to arriving at a shipping product; there is no single process that makes sense in every situation<\/strong>.<\/p>\n

    With my thoughts on process out of the way, next time I\u2019ll share my opinions on the narrow way design thinking defines the Empathize <\/em>step.<\/p>\n

    This article was originally posted on Laura's Medium page<\/a>.<\/em><\/p>\n

    \n
    \n
    \n \"Design\n <\/div>\n
    \n
    \n

    \n Sign up to the Newsletter <\/h2>\n<\/p><\/div>\n
    \n

    \n Get notified of the latest product updates and news at Marvel.<\/h3>\n<\/p><\/div>\n
    \n Sign up <\/div>\n<\/p><\/div>\n
    \n \"Design\n <\/div>\n<\/div>\n<\/section>\n","protected":false},"excerpt":{"rendered":"

    A mechanical engineer by training, I\u2019ve always chaffed at using the word process to describe something as messy and nonlinear as design. At MIT, I learned about processes for solving problems like how quickly heat moves through a block of metal, or how to calculate the impedance in an electrical circuit. To me, a process is something with a set… Read More ￫<\/a><\/p>\n","protected":false},"author":171,"featured_media":12267,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11],"tags":[],"class_list":["post-12252","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-viewpoint"],"acf":[],"yoast_head":"\n\n\n\n\n\n\n\n\n\n\n\n\n\t\n\t\n\n\n\n\n\t\n