What I wish I knew about design in college

Something that always frustrated me about my HCI courses in college and even in some of my design-related roles at larger companies is how the design techniques I learned were often not a fit for the kind of work needed to build great software. More broadly, it seemed like so little of what I was taught ended up being useful in my work.

So, I thought I’d write down what I wish I knew coming out of an HCI program into the workforce, as someone who cares about building useful software and not wasting people’s time.

• Understand the materials you are working with. Broadly speaking this is “code”, but it’s really about the constraints and abilities of the medium you are working in (web, game engine, etc). Concretely, this means it’s worth understanding things like specific CSS features and browser history.
• In school, you might be taught formal design processes like user story mapping and affinity diagramming. These are not the only paths to knowledge and they are rarely the best or the fastest paths. You can often learn what you need by talking to a handful of engaged customers or even an engineer who has worked in the space for a while.
• Good companies care about their users and customers, full stop. If you are at a company that doesn’t seem to care about its customers, introducing a new design process won’t solve your problem. You probably have to leave to do work you are proud of. A culture that cares about its customers will inherently care about design.
• The most important design problems to work on are the ones aligned with the customer and the business. The best designers understand this. The very best know that great design techniques have their place but might have to happen in the background or have to wait for the right time.
• Some design goals should be earned. For example, color system work and custom icon libraries have their place, but you need product market fit and enough customers to warrant spending time on this kind of work.
• The design industry was right to call out the poor usability of the (mostly Microsoft) software of the 2000s and lament how the engineers never spoke to customers, but do not fool yourself into thinking design is the sole savior - there are many PMs and engineers that love great design and care about the craft of software, and they are your allies. Find these people and work with them.
• Some design programs harbor some implicit antagonism for engineers and business people (hopefully this is less true today). If you also had this experience, promptly leave this antagonism behind. The best software I’ve built was with teams who all respected each others’ crafts and built the best possible thing given the constraints. Of course, it’s ok (even healthy) for there to be some amount of tension between roles. The product manager should want that one extra feature, the engineer should want the extra week to refactor code, and the designer should want more upfront time for iteration.
• Social science research methods have a very limited place in software design, as I’ve written about before. There are many confounding variables and good design is about judgment, deduction, and iteration. Undoubtedly I have a bias toward startups and B2B products, and some user research techniques make sense for B2C products with tons of users. However, for the most part, “user research” should simply involve talking to customers and users. Often it doesn’t even require that - you might be able to answer your question by watching user session replays or looking at user analytics data.