Time and again in my technology consulting career I have found myself using or responding to the term "flexible" to describe a technology, a space, or even an entire facility. It’s one of those catch-all terms, like “collaborative” or “state of the art,” that seems inherently positive. Everyone wants to be flexible. But what do we mean, exactly, by flexibility in design?

‍

Ask the person using the term and you’ll get a hundred different answers. In architecture, I’ve heard “flexible” used to mean:

• Multipurpose, or a space that enables multiple kinds of activities to occur;
• Repurposable, or transformable to different use cases;
• Divisible / resizable, as in auditoriums with moveable walls;
• “Lightly zoned industrial or office space;”
• Office space with no assigned seating (aka an “agile workplace”).

In the tech world, flexible might mean:

• A device or program that can be used for multiple purposes (a tablet that also functions as a laptop);
• An IT infrastructure that is compatible with many different types of end-devices;
• A network infrastructure capable of handling changing data capacity;
• Design that incorporates “future-proofing” techniques such as redundancy or expansion space;
• Modular or scalable infrastructure.

Unpacking flexibility in design

Obviously, the definition of flexible is also going to differ by sector. The technology infrastructure for a healthcare client is going to have different measures of flexibility than a similarly described space in a museum.

At this point, it’s tempting to toss the term out altogether as uselessly vague. However, I have found that when a client uses the term, there’s an opportunity to be found. Clients usually have a specific vision of the activities they want the space to accommodate and the effect they want the space to have on their organizational operations and culture. What’s missing is the piece that connects these two elements: the process.

By unpacking the client's meaning of flexibility through multiple levels focused on these specific activities, it’s possible to develop the assignment’s unique definition. I use a tool that I call “People - Place - Process - Paradigm.”

People: Who are the users of the space and technology? What are the numbers and the patterns associated with that -- workflow, size of collaborative groups? What’s the “style” of the users? Are they first-adopter, high-tech types, or are they casual technology users?

Place: Where is the technology being used -- not just the in-room tech experience, but the out-of-room tech experience and linking the two. What physical design aspects does the space need to have to create the best technology user experience? What tools does the space need to supply?

Process: “What activities are happening in the space?” This is where I really try and unpack. Oftentimes an architect will respond for a client “Oh yeah, they’re doing videoconferencing.” Well, what data do they need to share? Are they writing on a white board? Are they mostly sharing spreadsheets? You will need a different piece of tech to collaborative if you’re, say, an oil and gas asset team than if you’re healthcare.

Paradigm: What frustrates you today? What makes it difficult to do your job? What would the ideal interaction be?

For example, the client says he wants “flexible meeting space.” Instead of simply asking, “how many people,” let’s talk about their organization’s meeting style, the size of their management group, their sales group… do they all meet together, or are some of them remote? What’s working and not working right now in terms of the organization’s internal culture of communication? What’s changing in the organization?  What tools are they missing?

I don’t follow an actual queue list; it’s a journey and I’m ticking those boxes as we go along. The goal is to develop a design that’s user-centric. Once the vision is clear, then design can be driven by it and success measured against it.

And it starts off with being told, “We need something flexible.” It’s the designer’s responsibility to unpack what these terms mean (scalable, state of the art) — they’re perfectly understood by the client.

Unpacking the meaning of “flexible” has to come before engineering. If we don’t inform the engineering we won’t deliver what the client really needs. I’m pretty inflexible about that.