Skills I Have (and Don’t Have)
I’ve been designing and building web stuff in San Francisco for the last ten years. And during this time there have been some dramatic shifts in technologies, and along with it, job titles. Front-end Designer, Prouct Designer, Web Designer, UX Engineer — they can mean lots of different things and I often find myself struggling to explain what it is I actually do.
While reading Design Systems Ops I found myself nodding frequently to Kaelig Deloumeau-Prigent’s examination of the sometimes ambiguously defined roles of those who, like me, operate between design and engineering. It’s a great overview of the systems and documentation best practices that are emerging, especially at larger companies, and the problems that can arise from not recognizing their value.
But it’s Brad Frost’s Frontend Design that best captures my experience as a frontend designer when he describes it as a “purgatory” between the worlds of design and development. Though I come from a design background I’ve done a lot of both and at previous companies it wasn’t always clear which team I should be on. To their credit, Optimizely did an admirable job describing how the different roles fit into the organization. But even within those titles there’s a range of experience and skills, so here goes…
What I Do
- Scalable Sass & HTML Building the OUI Sass library for use in Optimizely projects has been my primary responsibility. It’s evolved from a small collection of UI patterns compiled with Ruby Compass into a large, flexible, versioned framework powered by node-sass that’s continually updated and improved. I did similar work building and refactoring at Inkling.
- Documentation The range here is wide, from pattern libraries to code samples to living style guides. Among the many challenges are identifying your audience, making it accessible and easily searchable, and then balancing the complexity of the documentation with the ability to keep it up to date. Not easy!
- Design & Design Guidance This includes everything from designing new patterns and interactions from scratch to helping Product Designers with UI and IA suggestions. In reviewing a design, prior to building the production code, I will look for how well it aligns to existing standards, if it can withstand different content lengths and other stress tests, and if its patterns are reusable and scalable.
- Production HTML At Optimizely the decision was made that the Design Team would own the CSS and HTML. Because it’s authored primarily by a smaller group, this tighter control allows us to maintain consistency and reusability. And in my experience most engineers are perfectly happy not writing CSS. This approach has resulted in less code and a big reduction in bugs and tech debt.
- Internal Tools I really enjoy finding small productivity issues on different teams and building tools to help. For example, at Inkling, I built a number of Chrome extensions, a resource tracker, and a Python script that output the numerous files required for submission to the iTunes Store.
- Version Control Git and Github.
What I Don’t Do
- Full Stack Development I’m acquainted with an array technology stacks and understand their general strengths and limitations, but if you need someone versed in data modeling, multi-threading and race conditions, I will be in the kitchen making a bagel.
- Server-side Programming At one point I wrote a fair amount of PHP but that’s about it.
- Database Management Pretty sure this one involves SQL queries and data dumps.
- White-space Arguments Tabs or spaces? 2 or 4? Who ate my bagel?