A Peek Behind the Curtain: What our Software Design Engineers Do

Laura Eble has been a Revelry front-end design engineer / UI and UX designer since 2014. We sat down with her to understand what Revelry designers do and how our approach to design differs from other software consulting companies. 

Why Front-End Design?

All Revelry designers have the same job title: Front-end Designer. That means three things:

1. Revelry designers are multidisciplinary. We may work in different design disciplines as needed by a project.
2. Revelry designers prioritize flexibility. We are always planning ahead to create designs that will work across digital platforms.
3. Revelry designers code. We implement our designs. There is no hand-off to a front-end developer. We ensure our styles are organized and easy to understand.

“I really like that I get to do all of it,” Laura explains. “Not everybody feels that way. Many people I interview will say they think design work suffers the more disciplines you try to do. I think that’s probably true in some cases.

But when it comes to the kind of work that we do at Revelry, I disagree. In this case, more is more.”

Why Multi-Disciplinary Design?

Many product development agencies or design firms have teams of designers with various job titles: UX designer, graphic designer, motion designer, etc. But here, all of those different capabilities can be done by one person.

Why do we do this? A multi-disciplinary approach allows you to prioritize design requests according to the needs of the business. Each part of the design process isn’t just something you paste in without fully understanding. Once you know what goes into user research, you push for it, because you understand how much it helps the visual design and front-end.

The finished product can feel disjointed when the design work is split into too many separate pieces among multiple designers. A big-picture approach supports consistency…continuity.

What’s Thoughtful Design?

What happens when a designer unfamiliar with front-end development creates a visual asset for a software product? Often the design will be stunning, but not thought-out to the level needed for implementation in a successful software application. The two most common challenges we encounter when implementing visual designs created in a vacuum are inflexible assets and undefined interactions.

Flexible Visual Assets

A flexible design can be used on all platforms. To better understand what we mean by flexible, here are some common questions that come up when we are designing a logo for a digital product:

• Does it scale up? Will it work on billboards and signage?
• Does it scale down? Will it still be legible as a website logo without a tagline?
• What will the favicon or app icon be? Does the logo have different elements for a smaller version, like a symbol?
• Are there multiple versions? For example, is there an edge-to-edge version for designers to use and a version with padding for the marketing team to use? Are the files set up to the sizes that you need?
• Did you save your file as an SVG? You can also use it to do some animation further down the line. Different screens can make logos look fuzzy or pixelated, but if you have an SVG, then that won’t happen.
• Will the design meet accessibility standards for contrast, readability, etc?
• How will the fonts impact the website load time? Does the logo use all custom or system fonts?

When front-end development and visual design are siloed, teams can spend a lot of time sending assets back and forth, creating bottlenecks and inefficiency. A front-end designer can anticipate the technical needs as they design the assets, saving time and creating a more robust design from the beginning.

Design Patterns

After a designer has optimized a graphic asset for multiple platforms, a front-end developer still needs to know how to implement the interactions across platforms.

A simple mockup defining fonts, colors, and button styles is just a first step. When development begins in earnest, teams must make hundreds of small decisions when styling for different screen sizes, devices, and more. Deciding the font size, color, and animation for every button, block, carousel, and more can consume precious development time and meetings between designers and front-end developers.

At Revelry, we prefer to use design patterns to build rules for styling under multiple uses instead of creating dozens of mockups for every possible use case. With a defined pattern, we can implement designs quickly and consistently.

How to Avoid Design Debt

What happens when a front-end developer implements a design, but is unfamiliar with design principles? Sometimes the style might work great for the user, but the underlying code is unorganized and repetitive, making it hard to update in the future.

Organized Code

Messy code is technical debt. Front-end designers are laser-focused on writing dry code that makes it easy to update designs over time. Here are some things we look for in organized code:

• Are class names consistent and written out the same way for each component, element, etc.?
• Is the code organized in alphabetical order or another predictable pattern?
• Are there comments when needed to add explanations?

If someone requests that you change a font color, would you prefer to change it quickly or spend days untangling code to find all fifty places in twenty different files referencing that font color? The way you write your code matters.

Structured Styles

The way that the styles are structured is critical. Styles need to be dry, to be as simple as possible. Take the example of styling a button:

• You can style one button
• But if you have a lot of buttons and style each button separately, then there’s a lot of repeated code.
• Instead, first, style a base button.
• Then add a blue button that takes from the base and then adds blue.
• And then, the green button takes from the base and adds green.

This approach is universal for everything that you style. The more you repeat the code, the more chances there are for inconsistency.

What Are the Strengths of Front-End Design?

Sometimes the collaboration between separate front-end and design teams can be beneficial and necessary. We’ve built several great products in partnership with highly talented specialized designers and front-end developers.

But on most projects, our front-end designers create the thing they are designing. And Laura likes it that way. “When I do it myself,” she explains, “it pushes me to grow. If I design something, and then it makes my life really hard to get it to look good on mobile, I have to suffer the consequences. That’s the biggest way to learn.

So the next time I feel the dread that something’s not going to work, I can use that insight earlier in the process and create a better design. That’s what I love about design at Revelry. I’m always growing.“

---

Design design engineering design studio design thinking Front-End Development