It set me thinking about a formative moment in my career. In 1997 I arrived in Arup’s Los Angeles office after seven years working on many exciting and ground-breaking scheme designs, mainly with Foster and Partners. My conceptual engineering was top-notch, but perhaps the ‘detail muscles’ I initially built up as a graduate had become a little flabby.

That office had the best drafting team I think I have ever worked with. Multidisciplinary design of hospitals was the daily bread and butter and seven draughters, choreographed by their intimidating (at first) leader, cranked-out drawings with a drilled rigour.

One of my first projects was to sort out the suspended roof bowl of Ben Gurion airport where the original layouts were not great; refining weird steelwork has always been a speciality of mine. I spent a happy morning marking-up the drawing, with various ideas coming and then being rejected, each leaving their mark in red ink spattered all over the sheet alongside the final changes. At lunchtime I dropped it onto the corner of the draughter’s desk.

About 30 minutes later the draughting leader put the mark-up back on my desk and told me “we’re not doing that”. I think the last time I’d been told my work wasn’t good enough I had been 15, and the 20-year gap made the surprise all the greater. But it brought me to the realisation that one reason why they were such a high-performance team was they were being fed with good quality information from the rest of the office. If there was enough time, they quite enjoyed working things out from scant details, but most days they had a pile of mark-ups ahead of them and everything needed to be crystal clear.

My next three years in Los Angeles were dominated by the Miller Park baseball stadium roof – 13000 tons of curving, complex steel, setting-out and weld symbols. I lived and learned the language of the effective mark-up. Compared to UK practice I became impressed by how American engineers followed graphical conventions. Standard notes and symbols were universally maintained and understood. Invention of new versions that added nothing to the finished product was eliminated, allowing effort to focus on the things that mattered – the actual engineering content.

When I left the US for the UK after three years, I was told I’d become the clearest marker-upper (is that a word?) in the office, moving from the ridiculous towards the sublime. Coming from that intimidating man that statement was a badge of honour, and I took those standardised methods and evangelised them through two teams in the UK and another in India.

So, one reason that standardised 2D-output is important is the increased productivity it enables in the teams that follow and rely on the information. However, I think it is also an effective indicator of wider engineering quality, by being a part of ‘the sniff test’ for reviewers. A badly presented set of drawings will often indicate a problem with the culture of the team that produced it, and as a result the likelihood of finding technical problems increases. Things ‘smell wrong’. Additionally, it means the job of finding a technical issue is going to be a longer chore as you spend time trying to understand what the drawings actually mean and how they link up. It’s not great fun and not effective use of time.

Conversely, reviewing a great looking, well-coordinated set of drawings can be a pleasure. It allows quicker and clearer understanding and the conversations with the team rapidly move to higher value discussions of underlying decisions made in getting to that solution. You can’t rely on good looking drawings always being correct – but there definitely is an intangible link. And that hasn’t changed just because our drawings are now cut from a 3D model. 2D-output remains a key part of the way we conceive, coordinate and construct buildings. Poorly chosen and annotated sections and views can indicate a design team lost in their own modelling processes and not paying enough attention to wider technical and communication issues.

Whilst the future of 2D information is perhaps uncertain, its much-predicted demise is yet to happen - and for very good reasons. A drawing is an abstraction of a 3D object chosen by the author and annotated to represent exactly what they mean to convey. It should be crystal clear on its message. A set of drawings is often the best record of a design stage and are an instruction to the next people in the information chain.

Strangely a drawing is often more tangible than a 3D model – even if not actually printed. If you have every had to do a deep technical review and mark up on a model you will know the difficulty of tracking elusive millimetres of tolerance. When you sign your name on the corner of a drawing you really know what you just signed. It is akin to lawyers still needing ‘wet signatures’ on some contracts. How can we develop the ability to ‘smell’ technical problems in a model?

Whilst these may only be short-term issues, re-establishing lost rigour in the way our information outputs adhere to standards will not be wasted effort. Increasingly it is inherent in our role as designer or contractor that we are data handlers. It is our job to provide the right data in the right format, as the next person in the data chain relies on that to be effective. It improves efficiency. It improves assurance.