Blog Engineering How I use analogy to design for highly technical spaces
Published on August 13, 2021
5 min read

How I use analogy to design for highly technical spaces

Just how much does a designer need to know about a technical space or product to design for it?


As a designer, you're lucky when you get to design an application you're familiar with, such as a supermarket app or a travel website – something we might have already used or even use every day. Most of the time, we are tasked with designing an application or technology that's unfamiliar or highly technical. Sometimes, we may not know what the application we're designing is used for, like creating an interface for an MRI machine controlled by a doctor, or a dashboard used by a professional musician – knowing what all the buttons do is already an achievement.

One of the trickiest questions for designers is understanding exactly how much you need to know how to use an application to design the best system for the user. This conundrum is typical for designers that work in a highly technical, enterprise space such as GitLab. The challenges can be exacerbated when working on Security products, but in my experience, we don't need to fully understand the technology or space we are designing for, but we do need to have some idea of how it all works.

The most difficult part is deciding: How much knowledge is enough? How much do you need to know about a product to hold a conversation with users? Or be able to explain it to others in your own words?

All if those questions are reasonable criteria for designers to focus on, but I've found a more exciting strategy to motivate me to translate complex technical spaces into smart designs: Analogy.

Create analogies to aid the design process

As a designer, I like to focus on both my creative and analytical sides but thinking of scenarios that do not exist yet. For instance, I like to do some thought experiments where I'll position myself as different types of users while performing tasks, or pretend I'm a user and critique my own work.

It may be easier to show how I do this through some examples. Below, I'll give security technologies some new clothes through easy-to-remember stories that match up to what the security technology does.

Let's start by looking at some of the standard security technology that we offer on GitLab:

Static application security testing (SAST): A testing methodology that analyses source code to find security vulnerabilities that make your organization's applications susceptible to attack.

Dynamic application security testing (DAST): A testing methodology that communicates with a web application through the web front-end to identify potential security vulnerabilities in the web application and architecture.

Fuzz testing: An automated software testing technique that involves sending invalid, unexpected, or random data as inputs to a computer program in an attempt to get it to fail in some way.

Now that we have an idea of the technologies in question, how might we understand them better through analogy?

Imagine a person is going to a hospital to check whether they're sick or not. Think of the SAST, DAST, and Fuzz testing technologies as different doctors with different specialties.

SAST is a modern doctor who loves scanning. SAST can use an X-ray-like machine to see through the application's "skin". It can see if any bones are broken – and everything else that makes the application work. This is SAST's key advantage – it can see every detail of the scanned app and analyze it. It also has maps with predefined problems so SAST can compare and find the problems. In some ways, the SAST maps is what Gray's Anatomy, the seminal medical school textbook, is to a doctor's clinical practice.

DAST, on the other hand, is more like your primary care physician. DAST doesn't need to know all of the details about how everything is doing inside your body (or the application). Instead, DAST talks with the app by asking questions and then observing and analyzing the responses. If the response is strange, wrong, or there is no response, DAST knows there are potential problems

Fuzz testing is the doctor that is a master of AI. Sometimes it also has a scanner like SAST, but it doesn't analyze in the same way. Fuzz testing has AI X-ray glasses that can mutate based on what it sees – potentially seeing even more. The analysis is the most personalized because of these mutated glasses: When the glasses see something suspicious at the shoulder area, it can change the lights and analyze it from the weirdest angle possible to match the individual shoulder. In other words, it adapts itself based on what was previously discovered and then digs deeper. Similarly, when Fuzz testing does not have a scanner, it has AI hearing, which allows it to change or mutate its questions based on the app's responses. It can possibly ask better questions as it scans to get more valuable answers to identify problems.

I like to use people in my analogies because technology is so complicated but few things are as complex as humans. Creating stories about things that I can relate to in my daily life makes them more accessible.

I hope you've found these examples to be a fun way to conceptualize challenging and highly technical topics. Next time you're designing in highly technical spaces, try building out relatable analogies and remove any fears of working in this space as a designer. One piece of advice: Always verify your analogies with professionals who have a deep understanding of the domain – no one will laugh at a passionate designer who tries to understand an unfamiliar world.

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum. Share your feedback

Ready to get started?

See what your team could do with a unified DevSecOps Platform.

Get free trial

New to GitLab and not sure where to start?

Get started guide

Learn about what GitLab can do for your team

Talk to an expert