What does it mean to be an agile designer?
Design as part of a process
The standard definition of the design process consists of consecutive stages: discovery/understanding, definition, design, development, deployment. The logic behind that is unquestionable, but actually, as long as we organize the first two stages well, what happens next could easily be called magic — we try to name it but no one can really explain how it works…
When we start with the visual design part, we have a bunch of untested hypotheses and have to give them a try. Only after the trial and error process can we verify those concepts. You could say that the problem behind the product is supposed to be well-recognized before the design part, and (according to the linear process mentioned at the beginning) the design itself is just an implementation of test results, but by saying that you’re confirming that you’ve probably forgotten how important the visual aspect is and how much the design affects the final product…
We’re at the point where you can’t — or at least shouldn’t — separate product (with its purpose and usability) from design. And design itself is as challenging as defining the job to be done.
Design is a learning process that goes through trials and errors. When closed in a linear scheme, it becomes only an execution of not necessarily right concepts.
The creative process is rather messy and relies on constant back and forth that ultimately brings the designer to the goal. Designers find it quite easy to keep up with their tangled workflow, but it’s very time-consuming and hard to keep track of. It’s also almost impossible to include this workflow in a broader scope, when a quick and precise exchange of information within the team is required.
I’m not a great fan of forcing design into a scheme of methodology, but I agree that some order is needed to neatly organize our work process.
Learn by doing
“Lean”, “agile”, “design thinking” — there are plenty of different methods to choose from. But all of those methods are basically about getting measurable results in the most effective way. One thing that I would like to mention is being flexible when stepping into the world of work process methodology: don’t be afraid to change your workflow, stay open-minded, test new solutions — but don’t get too attached to them and be ready to let go of what doesn’t work for you. Still, it’s all about the project and your creativity.
When a designer starts a project, he usually has an overall vision — a hypothesis that he’s going to try. It’s obvious that he doesn’t know all the answers and questions will appear along the way, but the project is a journey of finding those answers in a back and forth game. There’s a rising idea, initial sketches, project drafts and… then we find that this wasn’t it.
The worst thing at this point is to go back to the drawing board without any feedback that could give us a foothold.
Lean methodology gives us some advice on how to work smart, and how to avoid being left with nothing after days of hard work:
- Define a goal. It’s important to know what you want to achieve — regardless of all possible pivots, you always need to know the main direction.
- Change is a natural (and healthy) part of the design process — and it’s not only about designers looking for better solutions, but also the changing needs of clients and expectations that mature over time with the project. Revisions always sound bad for designers but when used wisely, they help to achieve better results.
- Don’t become attached to your designs. If one doesn’t work, don’t try to polish it up — throw it away and try another approach. And do it before you’ve invested too much time. Discarding an option after days of work is difficult, but with a five-minute sketch this is hardly the case.
- “Good” is a matter of opinion, but “useful” is quite objective. Try to ask specific questions about your project: visibility, readability or the emotions it engages. Only then will you get reliable answers that can help you better understand your task.
- Cooperation is the foundation — frequent updates, clear communication and setting expectations are a must. Frequent communication with developers lets you determine what’s technically possible to implement before heading down an exciting but tricky design route (and saves a ton of unnecessary work). Clear communication with a client will help to build a better relationship and achieve satisfying results.
Problem solving
Regardless of the methodology, it’s most important to define the goal and to gear our work to this specific problem that we have to solve. The right solution is the one that works for the client’s actual situation, not the one that the designer loves the most…
At the end of the day, it’s all about solving problems.
Don’t make it a quest for perfection, but rather try to understand what the real needs behind the project are. It’s been a long time since designers worked just for a design itself. Nowadays we’re here to build solutions that have a defined purpose.
Agile Manifesto
Even though it’s created by — and for — product developers, it’s still a valuable thing for designer to know. The principles behind the Agile Manifesto are quite universal and can be easily used by creatives. Or just treated as an oddity ;) Nevertheless, it’s worth spending two minutes reading it, and an additional two thinking it over. We have a plenty of methodologies right now, but it’s good to remember the roots.
http://agilemanifesto.org/principles.html
____
*Designer: one that creates and manufactures a new product style or design; one who creates and often executes plans for a project or structure;
**Agile: having a quick resourceful and adaptable character
(Merriam-Webster dictionary)
Thanks for taking the time to read this article, if you have any comments about it I would love to hear what you think.
You can also check out my other lean-related article here:
