Eiffel Over

Tag: DesignTeams

  • Juice the brief

    Juice the Brief is one of my favourite techniques for uncovering the possibilities hidden in a design brief. It’s a simple yet powerful way to stimulate creativity, generate new ideas, and explore questions that might not otherwise surface.

    How to Juice the Brief: Step-by-Step Guide

    To begin, you need a design brief—or at least a written description of the need or potential you’ve identified in a situation. It’s crucial that this is written down so it can be read aloud.

    Next, prepare your workspace by writing the following three headings on a large sheet of paper, a flip chart, or an online whiteboard: Information, Questions, and Ideas.

    Step 1: Write Down the Brief
    Ensure the brief is clearly documented. This is the foundation for the process and will guide your team’s exploration.

    Step 2: Read the Brief Slowly
    One person reads the brief out slowly—and I mean really slowly. The goal is to give everyone listening enough time to focus on their thoughts and notice:

    • Any information (e.g., design requirements, facts about the project).
    • Any questions that come to mind (e.g., about the end-user, the site, or the requirements).
    • Any ideas, no matter how unformed or rough, that the brief inspires.

    Step 3: Extract Information, Questions, and Ideas
    Listeners write down their thoughts under the corresponding headings:

    • Information: Captures specific details from the brief that are important to the project.
    • Questions: Identifies areas needing clarification, exploration, or further research.
    • Ideas: Encourages creative sparks—small or large—that can fuel the design process.

    In this divergent phase, every thought is valuable. Questions often lead to new information or ideas. Ideas inspire further questions, encouraging exploration and deeper understanding.

    Why Juice the Brief

    Juicing the Brief is like spinning the dense words of a brief apart in a centrifuge. It extracts the rich potential hidden within and reveals creative stimuli that might otherwise be overlooked.

    The name? It wasn’t mine. This technique originally had a more formal title, but one of my trainees—whose name, alas, I don’t recall—said, “Do you juice the brief?” Yes, that’s exactly what we’re doing.

    (Juicing the brief is just one of the many creative thinking tools in our conceptual design training for engineers (and other humans) at Constructivist.)

  • When WhatsApp is great for design team communication

    1. For high fives and mutual support
    2. For things that might interest someone in the team
    3. For thoughts of kindness and consideration (but don’t assume they’ve been seen)
    4. For anything that it doesn’t matter that you miss, so you can dip in and out without feeling the need to read the previous 200 unread messages.
    5. For genuinely urgent information (but remember point 4 still stands).

  • Lowest common denominator design team communication

    Imagine a system of design team communication that supplies the right level of information and enables the appropriate level of understanding within a suitable timeframe. A way of communicating with our work colleagues that is effective. A process that doesn’t overwhelm us.

    With the digital and analogue tools at our disposal, such a way of communicating is entirely possible. But it takes time to propose, implement, and improve.

    As Cal Newport argues in World Without Email, what usually happens is we don’t make time for this work, and so we revert to the lowest common denominator – in the case of his book, it’s email. However, I think that the lowest common denominator of communication, email has been surpassed by WhatsApp.

    Now, WhatsApp works so well because of its ubiquity – setting up a shared channel is quick, and communication can start almost immediately. But by my counts for successful design team communication, it falls short because:

    • The quality and quantity of information shared vary wildly.
    • There is no checking of understanding (the blue ticks just confirm receipt).
    • Information can arrive at any time (including in the middle of the night or at the weekend).
    • There is rarely any protocol agreed about how the information should be shared, organised, and responded to.
    • Messages come in a stream along with updates from a dozen other projects – not to mention the four other corners of your life. And as it is vastly easier to send group messages than to read them all, we have a recipe for information overwhelm.

    At the start of a project, the quick answer to the question of how to communicate is to set up a WhatsApp channel.

    However, probably the more effective answer is to spend time thinking about and testing a good process for communicating – in other words, designing your design team’s communication.

    If, as a result of that design process, you discover specific cases when a team WhatsApp is a good answer (see my post tomorrow), that answer should be the result of a design process, rather than the default.

  • Framing Design Decisions

    Shall we go to the Italian or the Mexican restaurant?

    Shall we go to the Mexican or the Italian restaurant?

    Shall we go to the Italian or the lovely Mexican restaurant?

    Shall we go our usual Italian or try out the Mexican place?

    Shall we go to the Mexican for main course and then go to the Italian for ice cream? 

    Shall we go to the Italian or the Mexican, or shall we look for somewhere else along the way?

    Shall we go to the expensive Italian place or the cheaper Mexican and spend the money we save on drinks beforehand?

    Shall we try one this time, the other the next, and use the experience to inform future decision-making.

    The last one may be unrealistic, but you get the picture. How we frame the question influences the decision we make. How is the design decision you are making being framed? 

  • Playing poker by the rules of noughts and crosses

    This week I am writing about how we make decisions in design. I’ve written before about David Snowden’s way of describing systems using a games analogy (see reference below). To recap:

    • A simple system is akin to a game of noughts and crosses. You know the rules and you can quickly work out the answer. 
    • A complicated system is like a game of chess. There are lots of rules, but given enough time you can work out all the options and choose the best one. 
    • A complex system is like a game of poker. The rules are one factor, but the game is made much more difficult by the interaction between the players. This is the domain of unknown unknowns. It is not possible to determine the best course of action from the start – the best approach emerges. 
    • A chaotic system is like a game with children in which they are constantly changing the rules. Here it is very difficult to make sense of what is going on as the ground keeps shifting. 

    Let’s look at decision making through these lenses. 

    A decision might appear to be a simple question of A versus B. But many factors might begin to complicate the process. For example, opportunity cost of one option over another. Or competing priorities that don’t make one option clearly better than another.

    When we start to include human factors, the picture becomes much more complex. First, there are the vast array of factors that push and pull our own decision-making – not all of them conscious; not all of them we want to admit to. And then there is how the groups of people around the poker table of design (whose interests might not necessarily be aligned) show up and play the game.

    The complexity grows when we we start to consider the interconnection between lots of the factors that we might consider in design: the long-term versus short-term business model, community wellbeing, ecosystem wellbeing, etc.

    Finally, we have a chaotic decision-making environment when the rules of the game start changing. This could be the case when, say, in a major project one part of the team starts shifting the goals of the project without informing the rest. No one is clear anymore about the conditions in which they are trying to make a decision.

    All of this is to say that decision-making is often much more complex than a simple A versus B. So we need to prepare ourselves for decision-making in complex environments. 

    As ever, our guiding principles can be: to work iteratively, and to look for the emergent patterns. 

    Playing poker by the rules of noughts and crosses is a losing strategy.

    References

    Snowden, D. J., & Boone, M. E. (2007). A Leader’s Framework for Decision Making. Harvard Business Review, November 2007 Issue.

  • Building a wooden rocket (on the advantages of scale)

    There are advantages to scale in design teams. NASA estimates that 400,000 people were involved in the Apollo space programme. This scale of operation allows a degree of super-specialisation, which enabled the development of brand new technologies — like the creation of software, a new technology at the time. Scale can be a great advantage when it is focused on one single task – in this case putting a human on the moon. 

    When you have scale, you can have small teams hyper-focused on single tasks without having to spend time doing any of the other tasks that support the work. This kind of focus unlocks potential for innovation and efficiency.

    In my previous post, I described a new game I have invented, called ForEdge. It explores how the size of a design team impacts the way they interact with their environment. In ForEdge, teams of different sizes compete to build wooden shelters in a forest. One of the dynamics I expect to see emerge is the role of scale in allowing specialisation.

    One of the effects I expect to play out is of scale on the degree of specialisation the teams are able to deploy. In ForEdge, each team organises itself into a tightly arranged cluster. But only the players on the outside edge can forage for materials. For a small team, that means everyone can search for construction materials in their environment, but larger teams, the inner team members must stay behind. 

    The opportunity for specialisation thus opens up the larger teams. They can have specialist foragers and specialist designers. Both can spend longer on their jobs and so both can learn to do them better. The foragers will learn where to get better timber. The designers will learn how to design better with the materials at hand, learning for instance the best way to design a connection with roundwood timber.

    I envisaged the game working with competing groups of between 3 and 18 people. Just imagine what kind of structure a team of 50 could do with their potential for specialisation – maybe not just a shelter but an auditorium. Maybe with 100 people in their team, they could have enough specialisation to also make instruments to perform in their auditorium. Maybe a team of 10,000 could build a wooden space rocket and fly it to the moon. But what would be the impact of this specialisation on the woodland that surrounds them? Material for tomorrow’s post.