A frontend designer (who may also go by UI developer, client-side developer, UI engineer, design engineer, frontend architect, designer/developer, prototyper, unicorn, or Bo Jackson) lives in a sort of purgatory between worlds:
- They understand UX principles and best practices, but may not spend their time conducting research, creating flows, and planning scenarios
- They have a keen eye for aesthetics, but may not spend their time pouring over font pairings, comparing color palettes, or creating illustrations and icons.
- They understand the importance of backend development, but may not spend their time writing backend logic, spinning up servers, load testing, etc.Of course this varies from person to person. Sometimes one person handles frontend design in addition to their other roles. They may primary be a developer (making them a “full-stack developer” as the kids say) or they may be a designer (making them a “full-stack designer” I guess?). Sometimes – especially as organizations get larger – frontend design is handled by people who often find themselves awkwardly siloed in one department or another. I talk about my own experience in my book:
Here’s the thing: I’ve never had a computer science class in my life, and I spent my high school career hanging out in the art room. Suffice it to say those requests made me extremely uncomfortable.
There’s a fundamental misunderstanding that all coding is ultra-geeky programming, which simply isn’t the case. HTML is not a programming language. CSS is not a programming language. But because HTML and CSS are still technically code, frontend development is often put in the same bucket as Python, Java, PHP, Ruby, C++, and other programming languages. This misunderstanding tends to give many frontend developers, myself included, a severe identity crisis.
This distinction between frontend UI code and “real programming” has real ramifications on organizational structure: