Navigating Ambiguous Design Requirements: A Reflection on Clarification and Communication in Development Projects

Hello everyone,

Today, I’d like to share an experience that highlights the importance of clear communication and requirement clarification in development workflows, especially when instructions lack specificity.

Recently, I was assigned a task with an extremely vague description: “Create the brand’s look and feel.” There were no visual references, such as Figma designs or style guides, only the logo was provided. Naturally, I interpreted this as a mandate to establish the visual identity—colors, typography, and overall design consistency. With that in mind, I developed a theming system that allowed for easy updates across the application: changing a single configuration would automatically update colors and fonts globally. My goal was to implement a scalable and reusable solution that could adapt as the brand evolves.

However, after presenting this implementation, I was informed that the actual expectation was much more limited: simply making the login screen visually appealing using the brand’s colors. I suggested extending the existing theming logic to cover the login page as well, but I received no response. A few hours later, I was unexpectedly removed from the project.

Looking back, I had not received any negative feedback beforehand—only a somewhat awkward remark during a daily stand-up from the project manager, stating, “I’m busy because I actually work,” which felt unprofessional and unnecessary.

This experience raises an important question:
How would you approach a task titled “create the brand’s look and feel” when provided with minimal guidance? Was my focus on a comprehensive, scalable solution misplaced? And how do you recommend handling such ambiguous directives in your projects?

Thanks for taking the time to read and share your insights.