4 ms·
As a UX designer, what should I learn in order to talk to developers?
Hello all. I am a newly graduated UX designer (Cog Sci major) that is basically leading the design team at a startup. We've recently hired a new development team, and I'd like to learn more technical skills in order to really understand the development side of the product, as well as to communicate ideas better and to understand our design constraints. I have a little bit of coding experience from school and am using some online tools to learn CSS/HTML/Javascript. I'm also using some online resources to learn about software architecture. Is this the best way to go about this? What would be some good resources for me to learn this skills? Appreciate it.
- Waterluvian 4y agoHopefully this helps, but I’m going to just mind dump because I have a real love-hate relationship with designers and this is my therapy. Yes, learn a bit. Design yourself some stuff and write it. Don’t worry about how bad the code is. In fact, I hope you make mistakes in architecture so you grok how architecture decisions matter, because they will also affect what UI/UX changes are easy and what’s shockingly hard. Save the fancy design pitches for the stakeholders. My favourite talks with designers is not when they’re selling me on a design but just casually chatting about how they got to the final plan. I learn a lot by learning your process. It demystifies things that can too easily be dismissed as silly or pointless. Don’t make change for the sake of change. Be that brave soul who is comfortable saying “after a bunch of studies and tests (using company resources), I would make these tiny changes but honestly, it’s all pretty much fine.” Don’t feed us design or throw it over the wall. Work with us. Understand what’s easy and what’s hard to implement. Understand why that is. Don’t always accept our reasoning (because sometimes we make arch. mistakes that really corner us on design changes being hard), but generally we have scars to explain how we know why certain things are a bad idea or whatnot. Teach us. Talk through your thought process. Don’t fear that we might think, “wow these people are impostors, there’s no science there!” Bruh, that’s programming too. Seat of our pants half the time. Sometimes we throw out jargon to feel legit. I love hearing “I did X because in the past I’ve found that works well for that kind of data view. I did Y because the AB years suggested as such. I did Z because I just think it works.” Uhh I think that’s it for now. Good luck on your career. It’s gonna be a lot of fun!
- theeohsees 4y agoThis is really inspiring, I really appreciate your response. Thanks for taking the time to write all this out, getting the dev perspective is really great.
- dtagames 4y agoAwesome advice here. As a dev and also design person who works with non-dev art folks all day, I'd say the more you can get down to specific exact asset files and names, the easier things will be for your devs. On the design side people work with multiple protypes and sketches in different states. But none of that ever makes it to the cold bare metal of programming. Design folks are often surprised that no visual tools are involved in actual website or software creation. Software requires exact numbers (margins, image sizes, color codes) and exact assets in specific places (on screen and on disk) to work. This means it will be as much effort for your dev to implement a "wrong" or temporary design as it will be to implement your final. Whenever you can carve out individual components or design aspects that don't change and canonize them in writing, this will help your devs. Think of their job as translating ideas and pictures into code which produces something like your pictures and you'll be easy to work with. And, have fun and keep adding the joy of your art skills to the (sometimes dreary) programming side.
- tacostakohashi 4y agoKeep learning some coding basics like some js, shell scripting, git, etc. Think about corner cases and extreme/uncommon situations and build that into your work. I've often encountered mockups/UIs where, say, they have a dropdown to choose from a list of usernames. That's a great UI for a startup with 10 people where they all fit on the screen, but how does that work at some big company with 50,000 employees? Think about how a UI is supposed to look and work if the underlying data becomes massive, more than can fit in memory for example. Think about error conditions and notifications, how to get these in front of people who can action them, instead of buried in logs, or a popup that is distant from where the underlying cause happened.
- solardev 4y agoFor existing projects, if your team is using a third party UI framework like MUI or Bootstrap or similar, something that provides widgets and primitives to compose, learn that system and deviate from it only with intention. That doesn't mean that you are stuck to it and have no creativity. It just means you have a good reason every time you want to (say) roll your own Autocomplete or date picker implementation. If the built-ins are good enough, even if they're not pixel perfect by your standards, often times it's good enough and there's no reason to overload it or write a custom one just to tweak minor whitespace or round a corner or whatever. A lot of that can be done with simple CSS tweaks anyway. But learning how much work something ought to take when you deviate from the current system will help you prioritize changes. If it takes two weeks to make a bunch of small tweaks, is that still worth it? Or would you rather use that time to do some surveys, clean up the IA, and really clean up the user journeys at a higher level? Up to you. But if you can explain your changes and why they are valuable, it makes development far more palatable than tweaking cosmetic things willy nilly just because your UI designer has a certain look they are really attached to. --------------- On the other hand, if you're starting a new greenfield projects along with your devs, now would be a great time to discuss and design the UX together, both so they know the user needs and so your designers know the dev hurdles involved. It's a lot easier to plan UI architecture alongside a design system than to try to shoehorn one or the other in later. With the right framework you can make a custom theme that will get you 90% of the way to your vision, without requiring your devs to create a bunch of UI elements from scratch. That's something they are probably not good at and probably don't want to be doing anyway, when there are already so many great third party options infused with years of design and research. TLDR minimize reinventions of the wheel as much as you can, and you'll save a lot of dev and designer time and focus on what really matters to your users.