HOW WE CAN FACILITATE INTERACTIONS BETWEEN DESIGNERS AND NON-DESIGNERS?

“We are not designers but …”
Until a few years ago I would have reacted to this sentence by turning into Ogre from the Tekken saga. Today, after more than ten years designing digital experiences, I must admit that intros like this could spark interesting discussions.

Scenario

Imagine an ordinary day. Upon getting up, we try our best to get from the bedroom to restroom walking like “The Walking Dead saga” zombies. Once we get to the toilet sink our feet land on a lovely puddle, the result of a micro-sink loss.

We hysterically start to scroll the phone book looking for Mario Bros (the plumber). Our hero is unavailable, so we have to run the clock and find an effective solution to:

• find a solution so that we can leave the flat
• avoiding making things worse

Our solution is a bowl placed under the sink. This, with the right degree of inclination, will allow the water to slip peacefully down the toilet, hopefully without causing further damages. Without having any plumbing skills, we designed and implemented a solution that meets the requirements and the needs of that precise moment in time. Of course, as we get out of the flat we will stalk the plumber to organize the best-fitting solution to the problem. I use this trivial example because, in my day as a UX designer, I have to evaluate alternative design solutions. Whether it’s changes in style or changes on a larger scale, I get myself ready to face two scenarios:

• Scenario A – wearing the kimono of the despicable Pai Mei from Kill Bill, and as head of design, I immediately close the discussion specifying that to criticize a design approach, you have to have very specific skills and vision of the project. Returning to the example of the sink, it’s like if I said to my interlocutors that the proposed solution, albeit temporary, is not to be taken into account because they are not plumbers;
• Scenario B – always wearing a kimono, but this time the one of the immense Miyagi in Karate Kid, I try to understand and criticize constructively the alternatives. Based on my experience, I ask questions and share information that will be able to give a bit of a context (in terms of feasibility, cost, timing and scoring ability of course) to our alternative solution. I appreciate the effort of creativity and I stress how valuable the involvement of non-designers is in the design process. My goal is to find solutions that are consistent with the design strategy adopted. Back to the example of the leaking sink, it is as if I surprised myself about the client’s creativity in finding an alternative solution to the problem.

Obviously, I prefer the scenario B, for several reasons:

1. I always find it extremely rewarding to argue with people who have a different perspective from mine;
2. I evaluate the opinions that, after a critical evaluation, can take an unexpected turn in terms of meaning and interest;
3. I invite people involved in the project to develop solutions based on the design principles. I try to encourage the definition of a precise context where I can devise an implementation strategy which is consistent with the “how” and “when” objectives of the project;
4. I always encourage to list and analyse, based on accepted criteria, several alternatives to get a better view of the project;
5. I engage colleagues and customers to propose solutions consistent with the adopted design strategy;

Conclusions

To achieve these goals, as a designer, I think it is essential to develop “techniques for dialogue” to take onboard different views and criticisms from colleagues and customers. Whether it’s evaluating a wireframe or prototype pixel-perfect, our partners will be encouraged to produce comments/criticisms.  

Often the alternatives offered are dictated by:  

• Different information – for example, their solution might prove to be more feasible from a technical point of view because they have more information on the topic;
• Different goals – for example, our partners must stick to a timeline different from ours, so you need a pragmatic approach in terms of timing of implementation;
• Different priorities -for example, is not necessary – businesswise – to meet the criteria of accessibility within the first release of the product;

In contexts like these ones, the role of experts is key to optimize the iteration, making it functional to the design objectives.  

As designers, it is up to us to gear these discussions towards a cost-benefit evaluation grid. Through this exercise, we will be able to support the Working Group in its quest for accepted and shared design solutions on time. All with the goal of designing a product which meets business and customer needs.