Universal design processes for social architecture.
Intro:
Designing a space or service for more than one person or a large group of people presents a challenge. Whilst most private residential design projects, or individualised commercial projects succeed in satisfying the needs of the clients, many public sector, public facing projects fail.
The more people that have an interest in a space, building or service, the more overlapping requirements the spaces will have to satisfy. Many projects become too complex for the delivery team to manage. The result in some of the most important factors are overlooked, unidentified or under appreciated.
In an attempt to manage diversity, aspects like oversimplification, misinterpretation or conflict of interest may lead the decision making and design process into difficult territory.
Without the right framework to give clarity to the users needs, tensions will arise within the organisation, or team responsible for delivery. Confusion may take hold, frustration may build, concerns that voices are not heard will spread.
There are simple methods and techniques to avoid this problem using the systematic and overarching processes developed in social architecture, and techniques like user stories developed in the computer sciences.
By following a step by step process, of collating needs as user stories, defining themes and objects of focus, preparing proposals , conceptualising design responses ,co-ordinating funding, policy and design teams, detailing proposals for implementation and finally making these reality. We can make a process which is universally useful for different teams working on the project.
As-well as this, we can use insights gathering techniques like user stories to make it easier to identify needs, reach some agreement and develop community space more co-operatively and transparently.
Allowing funding, policy, and design which can all be developed from the same repository of understanding without the time consuming arguments prevalent in traditional collective decision making.
The extended potential of programme design.
Good spaces, services, and design more generally starts with a clear programme.
A programme, put simply, is what happens on or within a building, service, site, or wider area. The activities and functions, and the guts of the proposal — from the everyday public activities to the periodic maintenance requirements. The more defined the programme, the better the overall service and experience.
In practice, programme often refers more specifically to how the elements, zones and spaces are organised. But they can include services that are social and mental, things to do with perception and understanding of the building.
A good programme comes from a genuine understanding of the end user base, normally from first hand research. A programme at minimum must accommodate obvious needs. But an excellent programme must acommodate the needs of communities that aren’t seen, are non-explicit and are likely not yet fully understood by the communities themselves.
We are also in a fast changing world, having foresight to accommodate unexpected change is also a necessary part a good programme. Something that allows designers to accommodate multiple possible futures and accept the high likelihood that the project, and its services will need to change and evolve to respond to a perpetually unclear world.
Developing a good programme is a very time consuming process, and one that is often skipped over by client, architect and community alike. But putting a greater emphasis on programme gives a universally useful foundation for multiple changes to the organisation beyond the physical. For example, the same building programme can form basis for an array of funding bids, proposals to orientate the organisations identity, change proposals for its future, but also form the practical brief for multiple design process and teams working on the project in an agile way.
Seen in this way, developing a programme is heart of the organisations future functions. Designing a programme is essentially designing a public service itself, and should not only be considered an architectural, but also an organisational endeavour — requiring extensive investment as a general purpose resource.
A programme battles assumptions, and remove things that aren’t needed, or will not be used. In this sense a very well researched programme lowers cost, lowers end user frustration as it ensures that real needs are catered for. But also brings the organisation to the next level of growth and development.
Advanced design programmes.
Most services that are beyond just being commercial have an advanced programmes, this is because their end users have multiple complex needs that cannot be satisfied by high street models of consumption. In these instances multiple people go to the same place for very different reasons.
A good programme allows the designer to weave multiple conflicting activities into a seamless whole that accommodates this complexity.
A clear problem can only be responded to with some clear solutions, so the challenge is to clearly outline observations. Designers can then use these observations as a base to make more intelligent spaces that fit the users needs.
Clarity of findings:
To add to the difficulty, many end-users needs are not always self evident or forthcoming.
A person undertaking the job of creating a new space or new service that responds to the general publics needs can easily become blind-sighted because of a public narrative.
For example, one group might be organised and educated enough to apply for funding for a project. But these same people tasked with leading design might have unspoken assumptions about the people that the services solve, these ultimately lead to a project with minimal or even negative impact to the end users.
Our situations create our actions. They either challenge or solidify assumptions about how people act and behave. And a design process based on assumptions can easily solidify class and social oppression.
Unless findings are carefully uncovered, and understood directly, and well categorised, the process of design can quickly become like Chinese whispers. Design problems being ‘lost in translation’ means that they are easily misinterpreted.
Why things go wrong:
To give an example of the typical failings of a design project: picture a public block of housing that hundreds of people live and use every day. This particular block has caused a lot of people issues with their mental health, it is overcrowded and neighbours are isolated.
The local council have realised this. As a bid to resolve the issues they begin a service design process. They know that these people need something… but what?
Some community consultations are carried out by the council, but only a single demographic and group attends. The users that attend meetings are relatively time rich and represent a fraction of the overall users.
The questions asked are limited by time constraints. People only have the chance to mention things that they feel comfortable talking about. Or the things that they particularly enjoy complaining about, for example noise complaints. Which begins to become the focus of the entire design process from this point onwards.
When findings are communicated to the team responsible for the strategy, the management team, some important factors are missed off because they are complex or difficult to articulate succinctly. There are other concerns that these might be seen as silly or unlikely to be provided by the management. And these will be missed off the list.
The proposal group then has several meetings. This is a political battleground of conflicting incentives, and has several circles of conversation. They finally create a brief for the project that seems to satisfy everyones needs. They have some kind of consent. But it’s only really a representation of the needs from all of the people in the board room.
When management relays these requirements to the funder, they have to boil this down to fit funders requirements. The project has another stage of transformation, and then this is translated to a designer or delivery team, there is a further potential for misunderstanding. The designer picks and chooses the elements that are most interesting to them and most cost effective to the client.
The design team now finally starts working on the project, the information is very difficult to prioritise. The designers may focus on a largely irrelevant part of design. Funding might be shaved off in areas it was really needed. Or their workplace means that they just want to appeal to their employers tastes, overlooking many factors that are most important to the end user.
This is a very common story, many public facing projects are a result of this process. This process means our possibilities for living are tightly restricted. It has the same systemic issue: misunderstanding.
New design methodologies can overcome by enabling a better clarity, and frameworks for direct knowledge exchange.
The root of all evil is…. the gathering, formatting and encapsulation of information:
Overcoming miscommunication is really about having the right formatting technique. It is the root cause of many problems.
Format should encapsulate a succinct expression or depiction of the essential features desired, lowering the potential for misinterpretation.
It is the understanding of objective truth around need that allows different teams to input.
And it is the simplification that allows the be re-composable to be manageable for proposal makers, and useful for designers and planners.
Information theorists such as Niklas Luhman invented the Zettelkasten system to store information in clearly as succinct and composable blocks, and in a way that can be rearranged according to specific need. Luhmans ‘card file consists of small items of information stored on paper slips or cards that may be linked to each other through subject headings or other metadata such as numbers and tags.’
Single responsibility principal:
One of the best ways to format information, and something that evolved from Niklas Luhmans experiments, is by encapsulating each key theme and findings as single ‘user story’.
Users Stories are a method emerging from computer science. They borrowrd their formay from the ZettlekastenI the 1960s. These are increasingly being used in other areas. By expanding on the approaches to developing software, it is possible to create new processes for service and city design.
Each requirement should be formatted to follow a ‘single responsibility principle’, that is, each story should ideally only do or explain one thing. If it ends up growing, it should be decomposed into smaller subpages.
By splitting findings into independent, reusable pieces and thinking about each piece in isolation we make collaborative research and design easier.
Separate researchers and designers, community groups, can contribute to the same format easily. Requirements can be responded to iteratively as they emerge. Making manageable tasks that can be ‘chipped away’ at by different members of the team.
Proposals can be made and agreed on. Voting, Consensus, Sign off, workshop, any other mechanism of descision-making that takes the groups fancy. What’s important is that a decision making process only works when a more fundamental process of gathering, articulating and planning users needs takes place first — which giving a rock solid foundation to the decisions being made.
User story example:
The stories of need.
Creating and formatting user stories enables the design requirement to be well understood, communicated clearly and designed for effectively.
By creating user stories, the team responsible for the delivery ensures they can ask designers to design things that their end users really want. It lowers the potential that the requirements will drift away from the users needs as different members of the management team become involved, and it makes the process more manageable for managers, and accountable for designers. This all helps avoid disappointment for the end users.
A suggested format is to consolidate a users need in the format below:
As a < type of user >,
I want < some goal >
so that < some reason >
This ensures that anybody who is given the user story can begin to understand what is needed, and starts to have a clear rationale behind the thing that needs to be designed, giving more context for a prospective designer, so they can focus on being experts at resolving these issues, rather the interpretation of these issues.
Diversity of information flows.
This method focusses on investigation over assumption. This is done by personal one-to-one interviews, or direct correspondance. It is designed to limit leading situations such as large group meetings.
This allows people to share more personal and even embarrassing needs that they may otherwise not feel comfortable sharing. Stops people from being influenced by a group or lying about their needs in order to seem normal or fit in.
It allows the interviewer to dig deeper and find a ‘root needs’ by asking questions that aren’t leading. See an example of an interview below.
When repeated, the simplicity and continuity of the process is what makes it useful. By collecting hundreds of these user stories, they act like Lego blocks, they can be composed and manageable.
Because of the simple formatting, the trends between different groups can be pinpointed as the data pool grows.
Simple probability techniques borrowed from data science and can be used to determine the likelihood of regular use in the future
This process results in ensuring a high use value to cost ratio. Meaning money is saved long term.
Because information is taken from multiple different data points too, by interviewing different people daily from different background, rather than just the manager, facilities are also less likely to defined by assumptions and misunderstandings of an individual client, which can be costly if this leads to errors.
It’s a technique that reveals the veracity of any particular users need. And allows them to be responded to with a realistic appraisal of importance.
Noise reduction in trend spotting.
Normally user stories would be compiled for hundreds of people. Once an array of user stories have been developed, they form a basis for some probability testing.
The needs can be arranged according for other metrics such as similarity of need and frequency of mention. This starts to give how likely others will want a similar facility or function. And therefore indicates priority.
Because of the format it allows them to be responded to as incremental pieces, and individual design challenges.
Piece by piece, the design team can be sure that they are making the right progress on the design.
It also allows end users to spot the areas that are missing.
The more user stories we gather, the more people input into our user story framework. The easier it becomes to cluster together data and reveal trends in end-user need.
Noise reduction means that the true scope of the project becomes clearer as more user research is compiled. Elements, zones and spaces are organised in relation to these needs.
Workshop and proposal making.
Once trends have been spotted these insights can be used to create proposals through workshops. The staff team, existing community, or management team can contribute to building proposals from these stories. Ether by arranging and discussing them according to room, or allowing them to input into the proposal for funding or policy making.
To conclude.
I outlined a new process for designing public facilities so that we can move beyond a single client. This involves performing interviews, formatting and using probability and data mapping techniques to evolve an advanced programme for public or civic facilities.
Creating user stories is a good format for a large pool of user needs. It is also a fundamental process to ensure an organisation is really responding to the needs of its community. This used effectively in any project that has multiple and diverse users, such as a the general public. Anybody who walks through the door to create spaces and places in cities.
When designing for the public this ensures that all of the needs can be identified, designed for. Legibility means that the community consultation work can be put to best use.
It also allows more people to input into the programme of the building. As the user base grows and becomes more complex, a process of creating a simple structure for user stories becomes quite important for the ongoing development of the space and service.
Another important feature is that it allows an ongoing methodology for positive change, and accountability for the design team. Helps develop buisiness plans, but also makes more incremental and agile funding plausible, so those people developing new services today and in the future might use this as a process.
It also allows what I call ‘headless’ city design. This means that rather than local facilities and services being determined a single client, single political or social class, single developer, a single managerial group, all who might have conflicting incentives.
It can be led by designers who can simply initiate this process to develop facilities for the local community that respond to real needs of that area, and respond to the challenge accordingly.
This process progresses and formalises some logic for the practicing social architect and begins to open a new horizon of value, who now have a universal process that can be provided as a service.
