Back-End Thinking Getting in the Way
Over the last 3 years, I’ve worked on becoming more comfortable with modern tech stacks, starting on the front-end and moving to the back-end.
Last week, I noticed a problem when I was doing some collaborative design: I was letting the data model influence my design thinking.
i.e. my brain was taking the components of the application and dwelling on the back-end implementation structure. I was horrified, because it could lead to bad UX decisions. I needed to be entirely divorced from those constraints. I needed to focus on how the customer needed to parse and manage the application’s information.
In theory, I could get so fluent with both coding and design that this problem goes away, but that is unlikely to happen.
The lesson is not to avoid learning to code. On the contrary, becoming fluent in CSS and semi-passable in Rails has been extremely useful to me as a product person. But I have realized that I need to very clearly and explicitly switch certain parts of my brain ON and OFF depending on what I am doing.
Why I Never Sketch in Code
A lot of people talk about sketching in code these days. For me, this is a terrible idea for the same reasons as the above. If I am writing CSS, my brain is split between the design issues and the syntax. I want to start by focusing exclusively on what and why.
I would rather sketch in pencil and quickly explore different paths (including responsive permutations), choose a direction, and then implement it. Sometimes there are even more intermediate steps, depending on context. Sometimes wireframes or high-fidelity mockups do actually make sense for internal communication and external testing (i.e. process needs to flex to the needs at hand). Of course, even when I do shift to implementation, I still need to keep the design-side of my brain active because problems and improvements will inevitably pop up.
…
I’m a huge believer in people expanding their skillsets. It is very healthy for digital designers to learn to code. After all, it is the medium with which we work. My personal lesson: be self-aware of your mental state as you work on different kinds of problems, because it can get in the way.