A good designer…
Ultimately our job is to solve the problems of our users. You are not the user. Set your ego aside, listen, and try to help.
Every project has constraints. Deadlines. Technology. Data. Developers. Embrace the suck, and find a way to achieve results.
Digital design is almost always connected to a larger whole. Work within the system when appropriate. Conversely, step back and look at the system as a whole to drive real change.
You should always be looking at problems through your designer lens, bringing that perspective. But you have to work with developers and other stakeholders to build the thing. You will have to compromise, and that is life.
It’s not good if you have to explain it. Just like your UI.
Getting feedback on your design work from other designers is valuable. However, it’s at least as valuable to gather feedback from non-designers. That might be developers, stakeholders, end-users, product owners, or whoever might have valuable input. Us designers tend to think alike. Bringing in new and different perspectives will make you a more effective designer and team player. Just be prepared for some people to not get overly excited about the quality of your drop-shadows.
Designers design things with a purpose in mind. While it is perfectly fine to design something for fun or as a concept, our job is to solve real problems for real people.
Many times a designer’s deliverable is not the actual solution. It is just a plan, or strategy for that solution. If the actual solution requires additional resources, such as developers – recognize the fact that what they build is more valuable than your deliverable. Don’t “kick it over the fence” to them and then get mad when it doesn’t match your mockups. Collaborate, iterate, and build the best solution together.
To successfully design something, we need to form a deep understanding of the problem or what’s needed. You can learn a lot from listening actively to others. Don’t be in a rush or even feel the need to respond with answers to questions. It’s better to say “I don’t know” in the moment, than to make up something. Take a scientific approach of listening, observing, and ask probing questions when needed.
If you’re designing an app, the solution for the user is not your design – it is the actual app. If you’re designing a logo, the actual SVG or PNG file is not the solution for the user either – it is the value that logo brings by being displayed on a business card, shirt, or sign. Don’t get too focused on the tools you use to create your design. They are important, but they are just a means to an end.
Making a high quality product takes a village. Obviously you need to produce a high quality design, prototype, etc. But you also need to work with developers building your designs to ensure they follow your standards, performance is high, and it actually works. Quality is not something you can “do later.” You can improve it iteratively over time, but you need to set standards up front.
Often, part of our job is to act as a translator or liaison between stakeholders and developers, or other technical folks. We need to be able to “speak their language” in both cases. This isn’t always easy. If something is lost in translation to you, ask a question. Eventually this gets easier.
Sometimes design is messy, and that is for the best. During conceptual and ideation stages, don’t worry about “components” or “design systems.” You don’t have to systemize something from the very beginning. Once you have a direction and you need to gain efficiency, start cleaning up your mess.
So much of a product that is well designed, are the details and craft that are put into it. The effort this takes should not be minimized. At the same time, you need to be able to “zoom out” and see the product as a whole, through a holistic view. This helps to ensure that what you’re working on is the most important thing.
Well written documentation is valuable. However, if your solution to a problem is to provide instructions so someone knows how to use the thing, your design probably sucks.
The answer is not always Figma. Sometimes it’s faster, or even better to design something with different tools and materials. A pencil and paper. A whiteboard. A document. Excel. These can all be design tools. Know when it’s time to use the best tool for the job.
A well designed product is one that should last for a long time. This should include software as well, which I think sometimes we don’t emphasize enough. Will your software product last for years to come, or will it break on it’s own because of some future dependency or compatibility problem? Build things to last.