Design is to communicate an idea. The strength is in teams. These thoughts are my own, these experiences were shared.
As a young designer, I used to believe a good designer was one who went off to a dark room and magically came back with inspiring, finished designs. The genius designer.
I used to try to achieve this process or lack thereof. Or if I found inspiration from other designs or processes I would hide them away, in fear of judgment for referencing others (rather than creating my work from scratch).
Now after several years and many projects completed, I have recognised the most successful designs have come from utilising everything and everyone at your disposal. This includes sharing your process and your inspiration.
As designers, we can get caught diving deeper and deeper into a problem and lose focus on the task at hand. This can lead to losing hours of work on minor details. Capturing feedback from those outside the problem on a regular basis can lead us away from these pitfalls. Allowing us to continue our progress towards the solution discovery. This has developed into a process/practice for me, sharing work often with colleagues, friends and my design community. I now put in place this feedback loop into every step of the design process for myself and for my teams.
Starting with the design problem.
It can be easy to jump straight into solution mode, wanting to move fast. Asking questions around the problem and situation will remove any biased or incorrect assumptions for you and the team. Thus providing a clearer focus on a unified goal. I have found this is best achieved in a social setting with open conversation, where the team focuses on clarifying points of ambiguity. I.e. clearly writing down the problem and making sure everyone agrees on it.
I then share this statement in a public forum so team members are able to refer to it easily. I have tried this via a wiki as well as physically written on a wall — the method used is influenced by the team composition.
Then onto solution building.
With the problem statement defined, we start to take notes. Scribble down concepts, and reference other ideas and solutions (NB: this may include other products). We don’t start designing on the computer, as it leads to the habitual solutions of the familiar. Rather than exploring what the problem is asking for. When surrounded by the same tools it can be hard to innovate.
Time to sketch.
Sharing your ideas from this previous step can then help you to build or rule out ideas to sketch, and we do this using pencil and paper. Sometimes printing out drawing templates at this stage. Still avoiding devices, we start drawing out our ideas, not getting caught up in the details. focus on creating flows to get a feel for the ideas.
Again, we share these with people.
The penciled out drawings help set the stage for the design process. People understand it to be a rough mock-up and can look past minor details. Enabling them to concentrate on the flow of the idea.
Prototyping.
Once we have the idea fleshed out on paper, we jump into the UI details. This can often be where we get lost in the design details. I’ve found creating mini-deadlines and sharing routinely helps avoid the pitfalls of photoshop and sketch. These screens can then go into tools like invision or flinto, to show a realistic experience.
By this stage of the process there may be many elements in and out of scope. I have identified how important it is at this point, to frame the request for feedback in such a way that explains the problem you are trying to solve (in context). This can include explaining the design decisions currently made and the process so far. Also explaining the type of feedback you are looking for. Trying to avoid criticism of design and instead focus on “questioning” and “adding” (no “butting”).
The finer interaction details can be mocked up in tools such as: framerjs, marvel, atomic, principal (flash or code) etc.
Building efficient and effective feedback relationships can be particularly fruitful.
Once the initial groundwork and understanding is built around the type of feedback you need, at different stages of the process. It can quickly pull you out of any design blocks and help you to grow your ideas.
These constant verbalisations of your process and solution can help you identify the problem you want to solve. Leading to your own discovery of ideas and improvements simply by reminding yourself of the problem at hand.
I’ve found this process valuable for all fellow designers, product owners, developers, and other stakeholders with differing goals. Design sits in the middle of these roles, and facilitates design-led thinking for product development. Capturing feedback towards the end of any design process increases the gaps in knowledge, or potential for products to steered off course. This can be costly for businesses.
Example. While development may not start on your design for months, not including development throughout the design process, leads to a lot of rework of completed the designs, or it may just not get built in the manner you designed it.
The same can go for the various stakeholders. Taking them on your journey ensures all goals align. This assists in prioritisation when the time comes to compromise.
The process of sharing work through the various steps of the design process improves the product and its delivery.
Learning from failure. Much of this process I now work to has been shaped by failure. When we fail, we reflect. And when we don’t seek feedback, we fail.
