Learning to code as a UX professional? It’s not a trap!
My job title has never officially been “Information Architect,” but that’s my area of specialty, no matter what flavor of user experience “insert metaphor here” methodology happens to be trendy this year. The thought process and problem-solving skills are what I enjoy most, and what I know best how to execute on. And although my job title when I joined Solaria Labs, Liberty Mutual’s innovation incubator, last year was officially Product Designer, my colleagues and I are all flexible generalists in the field; it’s a small, but mighty team. However, my IA strengths still came to the fore. As I was joining a project scrum team already delivering and iterating upon an existing product, I dove into high-fidelity UI work but also switched into IA mode, organizing our current assets into a design system using the lab’s agreed-upon toolset: Sketch and InVision, not my usual IA toolkit of Axure (or if we go back a few years, iRise).
So why do I see myself primarily as an information architect? I came to the conclusion that my strengths are in IA in a few ways. First of all, my masters’ degree from Rensselaer Polytechnic Institute in Technical Communication (focused in human-computer interaction) was writing, IA, and research heavy. Of course, there were some UI design classes in there, but I couldn’t illustrate my way into or out of a paper bag … let alone illustrate a paper bag. There were people in my program who were quite excellent at coding, but it wasn’t required as part of the degree; besides, we learned enough of the other skills essential to a UX practitioner that missing out on coding wasn’t a concern. After all, code is not in itself User Experience; code is just one way to create a user experience.
None of that sounds like ingredients for how someone who has been resisting learning any code beyond some basic “inspect element” commands in a browser changes their mind and gets started doing some development. What did change my mind, though, was Solaria’s encouragement (OK, maybe a bit of a push) that I take a front-end web development course. One of my colleagues had taken the class in the past year and had a lot of good things to say about how it had impacted her working methods. And given the Lab’s structure — UX in the lab lives under our Rapid Prototyping development team — it made sense for them to nudge me toward learning their language and way of life. So I signed up for a 12-week night class at General Assembly.
Why would I willingly give up two nights a week?
I wasn’t going into the course completely cold. I’d played around with some Hour of Code apps in the past, and if we’re really digging, once upon a time I created a GeoCities site. (Owning up to a GeoCities site should date me and my skills pretty well; Hamster Dance would have been aspirational!) Deep memories of tables, full-width text with difficult-to-configure padding, 90s-tastic 3D text effects, and <blink> tags perhaps helped me realize the need for a more modern approach. More recently, I’d managed a department wiki page too, so learning the actual skills didn’t feel like they’d be too much of a stretch.
As the course progressed, I realized that my three-part approach to design in general actually mapped well the three languages we were learning (albeit with some overlap and forever more options). Content was HTML. Style was CSS. Interaction was jQuery or another JavaScript library. Nothing was simple, and every choice had to be made with intentionality. Organization and specificity was key. Pixel perfection was a bottomless pit of unforgiving mathematics. I was never a pixel policeman, even when I was working as a design standards specialist, but in class, there I was, trying to figure out whether 4 rems of space looked better than 3.75. Over the months, the problems I grappled with evolved from “how can I put this picture on the right side of the page” (first method learned, CSS float) to “which method works best for putting this picture on the right side of the page given all the things around it”? (flexbox or CSS grid). Brevity gained new meaning as we learned to structure code in new ways to reduce either the number of lines or loops made. For the most part, it felt really good.
The real confusion set in when we began to learn how to use one language to override and change another. Everything could stop working with the wrong combination of selectors across documents. Content could be created or destroyed by the styles applied. Styles could be modified through interaction. This was where my IA-world experience in Axure came in handy. Creating the right group of elements and then understanding the order of operations to make things work was essential. Minimalism was helpful. Repeatability was a bonus. I found that jQuery and JavaScript were much more interesting, difficult, and ultimately rewarding for me than many of the other technologies and frameworks we learned in class. The syntax made an odd sort of sense once the jarring punctuation started to blend into the background. This isn’t to say that I could get everything to work well (or, sometimes, at all), but I at least could discern what I wanted to have happen and figure out what to Google to look for answers. Also, I had an arsenal of professional developers back at the office who were willing to help when I hit a wall.
This is a thing I do now
Twelve weeks and many twists and turns later, I hit “commit” on a simple, but rewarding, final project: a miles-calculator app to help frequent fliers (like me!) determine whether to spend award miles or cash for a flight. It isn’t perfect by a long stretch, but it is something that I can show off in my portfolio as evidence for learning some skills in, and an appreciation for, another line of work. I’m not running to become a full-time front-end developer — I’ll happily go back to my IA boxes and arrows — but now I have some understanding of how those boxes and arrows translate in code to what I am trying to deliver to customers. Through knowing better how our products are built, I can better appreciate that things that are simple in the tools I use can be exponentially more work to code into a finished product, and take that into consideration when making design decisions. (However, my development partners should watch out — I now know that in some cases where they say something is impossible or at least overly difficult, they may just need to slice the problem in a different way or change which language or framework they’re thinking in!)
Is learning to code right for you? (hint: probably)
Convinced yet? Well, if you’re a UX practitioner on the fence as to whether to put some time toward learning to code, I can now recommend the investment. As a longtime UX professional and a personal organization enthusiast (read: aspiring to the Marie Kondo standard), I find that the information architecture of an experience can truly make or break it. Now, armed with some front-end development skills, I can better see how this applies to every aspect of a product or project, from initial designs to the end-stage build. If concepts and controls aren’t organized in a logical way, they become nonfunctional. Designs (and code too!) should clearly reflect a defined mental model, whether it’s how a user might perceive how a product might work, or how the designer wants to communicate operation. Translating an idea into a visual layout with the right hierarchy is one of the most important skills for a UX professional — and as I learned, this extends into development practices, too. In the end, even though we’re perhaps speaking different dialects, to some degree we’re all speaking a common language.
