Designing for Design Patterns

My first introduction to design patterns: The Gang of Four

Some of the most incredible years of my career were at EuroRSCG, which at the time was one of the world’s top five global advertising agencies. We had just won a global pitch to develop the collaboration platform the agency network would use to communicate with its multinational clients like Intel. I was the Technical Director at the time, and my job was to assemble a team of world-class engineering talent that could take on this immense project and deliver something that worked well.

The domain of computer science progresses so quickly: Just as I was finishing my degree in computer science, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides released a seminal book called Design Patterns: Elements of Reusable Object-Oriented Software. This book fundamentally changed the view of software engineering into something which had architectural patterns which could be applied in specific scenarios to solve common engineering challenges rather than just ‘writing code’. The authors are referred to as the Gang of Four.

It was not until I was at EuroRSCG and had this great team working for me that I learned about these design patterns for software engineering. I found working with a stellar group like this pushed me to my intellectual limit and vastly improved the quality of my code and architecture design skills. As I wrote more and more code and collaborated on more and more architecture design, I grew to understand the benefits and shortcomings of design patterns and deeply embedded the work of the Gang of Four. There have been libraries of hundreds of design patterns developed since this work was published nearly 25 years ago.

A New Set of Design Patterns

I have always been interested in the human connection to technology – not just through interface design, but also language design and developer tools. Over the years working at Thinking.Studio I have had to design a heap of user experiences, but also scripting languages, developer environments and designer workflows for all sorts of industries. My interaction with computer security started 15 years ago when, working with my first startup in tech support, I had to write software that would help technicians remotely secure consumer’s PCs from malware like Sasser.

Over these fifteen years, I felt Thinking.Studio was somewhat removed from the cyber-security industry as our focus was heavily on experience design and software engineering. Cyber was more about knowing what we needed to do for the sake of compliance: Passing penetration tests with flying colours.

The more designers I worked with, the more I saw there was very little understanding of cyber-security. Certainly not regarding how user journeys or interface design could influence the outcomes.

Gelin Luo, Technical Director of Thinking.Studio has been working on an open source Java development framework for the last three years called Act.Framework. In writing a platform for developers, he was facing a similar security challenge with the software developers he came into contact with that I had with designers; they mostly considered security an afterthought, and they frequently did not have broad exposure to OWASP or understand security principles.

As we worked with financial services and insurance companies over the last five years, we saw that these knowledge-gaps at the convergence of design, development and security were something that we could solve with Design Patterns. So we started doing the research.

Designing for Design Patterns

At the moment we are working on two research papers:

  • Design Patterns for Secure User Experience Design
  • Design Patterns for Secure Frameworks

Both of these pieces of research force an exciting view of the world. As opposed to just looking for ‘best practice’ or ‘precedent’, we want to find instead the most elegant abstractions that then determine the appropriate precedent. Finding these abstractions is essential because design patterns are designed for facilitating behaviour change: designers or developers are now looking for patterns with known solution strategies, rather than jumping directly to the space of solving problems.

Looking for an abstraction allowing you to identify a set of typical circumstances in which you can use a design pattern is the first part of designing robust design patterns. The second is the solution pattern itself. My view of a useful design pattern solution is that the efficacy should be quantified. Implementers of a design pattern should understand the effectiveness of the pattern they are implementing. Otherwise, design patterns are merely professional folklore.

Traps with design patterns

There are two fundamental issues with design patterns: overfitting and edge-casing.

Overfitting a design pattern is the situation where someone tries to apply design patterns to situations where they are not applicable. Often this is the case when someone is first discovering a design pattern, and they suffer availability heuristic where ultimately the balance of pattern-matching to problem-solving is biased to pattern matching.

Edge-casing is the situation of creating design patterns for uncommon abstractions. The problem with edge-casing is that it generates many design patterns that have low value, in turn putting an unrealistic cognitive load on the person intended to use them all. Hundreds of design patterns ultimately make all design patterns pointless without some hierarchy of importance. Understanding the relevance of design patterns is possibly more important than understanding the design patterns themselves.

Research We’re Working on Right Now

We are currently developing our research papers and subsequent research right now. Let us know if you would be interested in participating in the research with us.

Secure Framework Design Abstract

In 2015 Gelin Luo started building an open source project called Act.Framework which is an enterprise-grade Java development framework.

While we started with the intention of simplifying the development experience for Java developers wanting to build internet connected applications, what we found was that, for most developers, building secure applications was a huge gap in their skill set.

This paper looks at the challenge the security community faces in getting developers to shift their mindset to think about secure coding principles, and how thinking about the tooling as a contributor to security capability can change the risk profile of organisations.

We illustrate our examples of secure coding practices by showing how we approached the challenges of developing secure applications as ‘easy or implied’ when we designed Act.Framework.

The presentation is also an invitation for other developers and security researchers to collaborate on Act.Framework with us.

Secure UX Design Abstract

Research indicates up to 98% of cyber attacks rely on social engineering. Essentially, this means 98% of attacks rely on humans to misunderstand the impact of their actions or create an illusion such that a human’s ‘regular behaviour’ is used to extract personal data for nefarious ends.

This paper looks at how we leveraged the psychological tools of advertising to drive positive behaviour change in users. We identified a set of everyday situations where users are vulnerable, and then distilled a set of ‘user experience and interface design patterns’ that have been found through observation, experimentation, and research.

These ‘design patterns’ can easily be adapted by interface designers to mitigate some of the human vulnerability exploited in social engineering attacks.


Availability Heuristic (Wikipedia),
Design Patterns (Wikipedia),
Gamma, E. (Ed.), 1995. Design patterns: elements of reusable object-oriented software, Addison-Wesley professional computing series. Addison-Wesley, Reading, Mass.
Kahneman, D., 2012. Thinking, fast and slow. Penguin Books, London.

Level 25, 88 Phillip Street
NSW 2000

+61 2 8024 5975
[email protected]

©2003-2020 Pixolut Pty Ltd trading as Thinking.Studio
All Rights Reserved