In smaller teams, we often find ourselves without dedicated UI/UX designers or product roles. The focus is on shipping, finding customers, and securing funding. Feature descriptions are often short and lack context. Instead of detailed specifications, we’re given a few lines of text and asked to “just build it.” As a result, often the wrong thing is build, wasting time and resources.

As a front-end engineer, however, you can provide significant value in these situations. Here’s how:

Understand what you’re building

The most important context that often gets missed is understanding why this feature is being built and for whom. You can’t provide this as a software engineer, but you can facilitate the process. Setting up a simple template can help capture this information. This can range from a basic four W’s framework (Who, What, Why, When) to a more detailed feature passport. Encourage conversations with potential customers, domain experts, or stakeholders to fill these out. Keep the focus on the problem and the user context—avoid too much technical jargon at this stage. At this point, you want to resist jumping into technical solutions and instead concentrate on defining the problem clearly.

Collaborative refinement

Set up regular syncs with the team to review and refine these feature documents. During these sessions, you can suggest technical solutions, break down complex features into manageable phases, and scope features realistically. Your role as the technical expert includes highlighting potential technical pitfalls, platform limitations, or other challenges the team may not be aware of.

Choosing the right tools

When it comes to implementation, choose tools that allow flexibility without sacrificing speed. For example, a neutral, pre-styled, headless component library like Shadcn/UI can be a great starting point. These libraries typically look polished enough out of the box while allowing for customisation later on. Avoid building custom visual elements that aren’t part of the core feature unless absolutely necessary—this can lead to wasted time on details that don’t add immediate value.

Look for inspiration from existing solutions

Before diving into development, take the time to research how similar problems have been solved by others. Look at existing products, open-source solutions, or design patterns that have worked in similar scenarios. Drawing inspiration from these can help avoid reinventing the wheel and may offer insights into potential UX improvements or feature adjustments. 

Low-fidelity prototyping

If leadership has specific ideas about the user experience, create (very) low-fidelity wireframes. Their purpose is to get quick feedback and ensure alignment on the vision. After you’ve gathered this input, you should be capable of filling in the blanks.