#7: UX Career: Weekly Digest
The purpose of this newsletter is to help you grow as a designer and human and increase your chances to get hired in UX. While I am trying to form my voice for this newsletter, I will be experimenting with the content strategy, so bear with me 🙏
Disclaimer: all opinions are my own, just sharing my thoughts.
✍️ Need your help
I am looking for a few people who would be open to jumping on a quick call with me and answer a few questions. Mostly, around the content, format, and structure of this newsletter. If you would like to share your feedback, so I can make it better, leave your contact details here:
💬 Quote of the week
Success doesn’t come from what you do occasionally, it comes from what you do consistently.
— Marie Forleo
🙋♂️ Question of the week
How do I present projects for developers?
Short answer: discuss it with them and align on the right way together.
Years ago, before I went into UX, I was designing websites, and the hand-off process was rather unreliable (as I am analyzing it now). I would create png mockups for each page and give them to the developer. It was creating lots of back and forth and unnecessary questions. This was the time when PSD -> HTML conversion was a very trendy service for freelancers =) Then there also were exported assets folders, detailed UI specifications with annotations, different apps and plugins designed for dev hand-off (e.g. Zeplin, Invision, etc.), and so much more varied options. And with every next team I worked on (and with) the toolkit for the designer-developer hand-off was different.
Taking all my experiences into consideration (and my user-centred mindset, the developer is your user in this scenario), the way I prefer doing the hand-off is by having a conversation with the dev team at the beginning of the project to understand what is the most efficient and effective way for me to hand-off my designs to them. I am trying to be as open as I can to the varied processes and tools that developers have and I try to tailor my hand-off process to my design artifacts “users”.
I decided for myself, that my ultimate goal as a designer is to increase the chances of having the resulting working product be as close as possible to the way I designed it. With this goal in mind, the hand-off question becomes more about finding a way that prevents miscommunication between design and development and allows us all (the project/product team) to deliver the best possible experience for our users. One of my biggest (sometimes, frustrating) learnings was that what you design barely ever gets coded in the same way, so there is always something that looks/behaves not the way you intended to. And I am not talking about technical constraints and trade-offs. To me, this is an indication that there is a disconnect in the communication between design and development. And, frankly, even with the most detailed hand-off, somehow it is impossible for the developers to make it the way it is designed =) I am still trying to understand why this is happening.
So, with every development team, I am trying to minimize this miscommunication by aligning with them on how they expect me to hand-off assets to them, and what is the most effective way for them. To my delight, I haven’t seen any unreasonable expectations =)
To summarize, my recommendation is to decide on the hand-off process together, as a team. And don’t forget, that your goal is to reduce the back-and-forth, and the risk of them coding something too far from what you crafted. So, if your developer doesn’t care about spacing (or other details) while you do, make sure to include these kinds of details in your assets. There is no perfect hand-off, it’s a spectrum between fast with minimal details and slow with full details. Also, it could happen that you include all the tiny (and important details) and the developer will miss them, as it is not important from their point of view (happened to me too many times). So, the value of ongoing communication and reviews can’t be overstated. No hand-off can replace the collaboration with your developer.
While writing this, I realized that this topic is much more complex than I have many more thoughts to share than I initially anticipated. This should provide a rough summary of my thoughts and I will pin this topic to look into later for a more in-depth explanation.
PS You can now submit your questions for the newsletter (anonymously): Submit questions.
A person shares career strategy advice to his younger self in a 19-tweets thread. This strongly resonated with my thoughts. Highly encourage you to read this. One of the interesting nuggets is the advice to optimize for fast learning at the beginning of your career, and not choose your employer just for their fun culture. View thread.
Jared’s recent rant on dashboards as a solution to user problems. Every time, I see this kind of hyperbolic statement, they sound like something that an inexperienced person would say, but it’s Jared, he has plenty of experience and should know better. My gut feeling is he does this occasionally to stir up the debate and fish for engagement. Read the comments, too. View tweet.
4 common job search mistakes. Common sense, but sometimes another reminder can bring the focus back. View post.
💭 A thought
With each next issue of this newsletter, I have been carefully listening to my thoughts and feelings, and I had a few interesting observations. First, I enjoy writing and I miss the blogging times. Second, I need to improve my writing =) And third, I want to write on a broader set of topics than a UX career. Some of my other interests are entrepreneurship and startups, side projects and passions, psychology, philosophy, and a bunch of other topics that regularly pop onto my interest radar. Also, I am constantly researching and learning a lot of new things, and I want to start capturing my takeaways across all those topics (on a weekly basis?). Sort of a logbook. So, I am pondering launching a separate newsletter to include non-UX thoughts that get on my mind. =) Just need to figure out the format, but seriously interested in this idea.