Why do I need a design process?

You might be asking yourself why you need to define your design process. Having a process to solve a problem, and knowing how to show it is a big part of the industry. It adds value to the work you do!

Imagine handing a quote to a potential client – (likely someone who doesn’t understand the value, time, and energy put into a branding project) that it will cost $10,000. That would be sticker shock without providing any context, right? They would question where their money was going and why it costs so much! Showing the process and methodologies you will use to define and solve their problem helps them understand the time needed for the project. People like knowing what they’re getting for their money, so being able to show and communicate the value is important. Seeing that you have a process for problem-solving will give them peace of mind, make you more confident, and them more confident in you.

Imagine you’re applying to intern at a design agency – Most agencies have very clear processes they use in-house for different kinds of projects. Being able to show your process, how you think, and how your problem solve will help them decide if you’d be a good fit for their team.

You know that feeling when you hit a creative slump?  – Developing a process and strategy for defining and tackling design problems helps ensure that you will always have a roadmap to a solution.

---

Why a Critical  Journal?

A critical journal is a way for you to record your whole design process. You can document your research methods, feedback, information, progress, questions, and many more things. It becomes a collection of all your work, thoughts, content, and experimentation with required weekly reflection. At the end of the semester, you will organize your processes, analyze, and present your curated journal in a digital format so someone outside of the project will be able to understand. We will look at a few process journal examples when we discuss your first big project to give you an idea of what they’re all about!

---

Debriefing – Ask Questions & Define the Real Problem

Let’s say that you start a project and for a while, things are going according to plan, great! But after a while, you hit a few setbacks. The timeline has to get extended, decision-makers get pulled away from the project, it’s difficult to hit certain milestones. At this point, you have a few options.

You could:

1. 1. try to keep pushing through the project and hope that it all turns out well
   2. forget the project plan and go rouge, or
   3. make some adjustments, then jump back into the project

A) is a disaster waiting to happen, and will usually end with both you and the client frustrated and not willing to work together. Option B doesn’t set you up for success either, as it will allow the issues to become even worse. Option C would help you and the client learn from the setbacks and continue with an updated plan.

This is where Debriefing comes in! Debriefing is a structured learning process designed to continuously evolve plans while they’re happening. The term began in the military as a way to learn quickly in rapidly changing situations and to address mistakes or changes in the field. In business, debriefing has been widely documented as critical to accelerating projects, innovating, and hitting difficult objectives. It also brings a team together, strengthens relationships, and fosters team learning. It is a great tool for collaborations and group projects, but can also be useful to self-analyze what works and how you yourself can improve.

Sounds great, doesn’t it? So how do you do it?

Debriefing is more than just a casual conversation to discuss what did or didn’t work. Debriefing analyzes why certain things happened, and explores how they could impact the future. The desire to truly understand the root causes of their successes and failures needs to be there to truly understand what to repeat and what to change. It can be uncomfortable, but realizing what needs to change can only help you succeed in the future.

How often you should debrief depends on the work you’re doing. For example, in 2011, when the NY Giants won the Super Bowl, they held debriefings 1-2 days after every game to understand what did and didn’t work. A lot of software development teams and design agencies hold smaller debriefing meetings every morning to review yesterday’s progress and today’s goals—then they hold longer debrief meetings every month or two to understand big picture successes and challenges. These meetings can last anywhere from 10 minutes to many hours. It all depends on the size and scope of the project.

Key questions for debriefing:

• • What were we trying to accomplish?
    Every debriefing should start by restating the project objectives and goals. Before a project even begins it should have clear objectives. If you didn’t have clear goals, the rest of the debriefing won’t be valuable because you won’t have a way to measure how successful the project was.
  • Where did you hit or miss your objectives?
    This is pretty clear, you either did or didn’t complete your objectives.
  • What caused the results?
    This should go deeper than obvious answers. If you were trying to generate fifteen wins and only generated five, don’t be satisfied with answers like we didn’t try hard enough. Dig deeper and ask why you didn’t try hard enough. Were the incentives not enough and you weren’t motivated? Were you overwhelmed because your team didn’t prioritize the work? Was the task too complex so people gave up too easily? There can be a lot of reasons, but you need to figure that out, otherwise, you won’t know how to fix it in the future. One way to dig to an answer is by using the 5 Whys method. The video below is a little cheesy and very simplified, but helps explain how you can drill down to get to the real problem.
    
    https://www.youtube.com/embed/NBrFCHtoPRY

Be sure to document the lessons learned in an easy format for everyone on the team to understand and reference later. Like I mentioned above, you will be documenting everything in a process journal throughout the semester. Through that you will capture and reference all your successes and challenges to learn more about your own process, and how it can be improved.

---

Brainstorming – Attacking the Problem

Brainstorming can help designers (and non-designers!) define problems and come up with ideas at the beginning of a project. Through brainstorming, you can directly face a problem with very quick questions to come up with solutions. It allows people to open their minds to very different ideas they would have otherwise not been considered.

Brainstorming usually happens with a group, with one person moderating, writing down any and all ideas from the group (yes, even the “dumb ideas”). Sometimes, after the session is over, you can combine ideas so writing down everything is important. The group is often more productive when there is a time limit on the brainstorming session, and it gives the group a goal to reach. You can limit it to the number of solutions/ideas or actual time. Another way to ensure the session is productive is by having a specific topic for the group to focus on. Making the topic too broad or vague can be difficult to get the group to focus or think about solutions quickly. 

There are a lot of different techniques for brainstorming. Using a whiteboard, large pieces of paper, sticky notes… but they all allow a group to contribute to solving the problem.

---

Mind Mapping – Explore the Problem

Mind mapping is a form of research that will allow you to explore the scale of a problem, topic, or subject. It has also been called “radiant thinking” or “a cloud of ideas”.  You begin with a central idea or item and plot out all thoughts, images, or concepts associated with that idea or item. Mindmapping was developed by a popular psychology author, Tony Buzan. Here is a video of him explaining mindmaps himself!