We had another guest speaker today, but I don’t remember his name. I do remember that he was a friend of my other instructor, Chuck, and he talked about clay tiling on roofs and walls. However, this has nothing to do with my blog post today besides providing background context for what happened after the guest left.
The guest spoke a lot about the variety of things his firm has done, so afterwards Chuck was talking about how his favorite part of being an architect is the part many architects dislike the most: the people. He loves the randomness of what different people will come up, because they bring ideas to the table that he never would come up with.
Some architects try to use costumers as a tool to showcase their art, so rather than working with a customer, they just tell the customer what they are going to build. However, the customers tend to not like this, so they don’t usually come back. It goes to show that you need to always keep the end user in mind during design thinking projects.
The customer plays a big part in the process by providing feedback. Chuck explained how if we had more time, when we did activities, after we presented to the group and got feedback, we would then go and use that feedback to re-look at our structure. What really made me curious was the way he worded one of his last sentences: “This would more accurately represent the architecture design process.”
For the last several months, this idea of creating a design thinking process manual or handbook kind of thing has been floating around. To create this manual, we have been looking at the similarities of design thinking process, and how to make a general book to describe what is typically needed.
From the little I’ve seen and helped with this massive idea, I can say that the process is difficult, but maybe we are going about this wrong.
Chuck specified the “architecture” design process, and this made me think about how everyone always says that there are thousands of different processes. Could it be hypocritical to try and make just one booklet?
Don’t get me wrong, I love looking at the similarities between different kinds of processes, but maybe this is just human nature trying to put design thinking into a box.
It’s like the Tomato Sauce Theory, as I call it. We watched this TED Talk in science class that had to with how the tomato sauce industry got bigger and also changed the way we eat food. In summary, this guy (who I also forget the name of) realized that Prego did not need to find the best type of tomato sauce, but instead Prego needed to find the bests tomato sauces (plural). This guy noticed how everyone does not like the same thing, but by creating every possible kind of tomato sauce, he was able to determine 5 major categorizes of what people liked. Then Prego sold all of them and their profit increases exponentially because now there was a sauce for everyone.
Maybe that’s how we should approach a design thinking challenge about design thinking. What if instead of creating one big, general formula, we figured out the major different types of design thinking challenges/projects/situations where a design thinking process is needed, then used this information to design more specific guides for each individual type?
Maybe our user is too general and we need to pay more time looking into the randomness of each customer.