Designers are still doing a terrible job working with the developers

View the original post

What are designers doing, and why are they getting no-where?

This might be worldwide truth that the collaboration bit between engineering and design isn’t a straightforward business. Often product managers become the glue between both the teams and pass messages between them. Although team leads are keen to organize workshops between design and engineering, practical workshop actualization is challenging. When all efforts fail, companies try to break down teams into squads and force different disciplines to sit next to each other in “pods” and talk more while sharing the same desk. Unfortunately, none of these team-building tricks work. They can end up creating more silos and less empathy.

Luckily the real magic happens when individual contributors (ICs) start putting more thought into their actions. Here are the four steps you can take to resolve engineering and design team differences and drive empathy for both ends.

Understand Mental Models

The black hole between design and engineering is usually because both teams are ignorant about the differences between each other’s mental models. This leads to a struggle to communicate with each other. It is not easy to break free of one’s mental model and adopt someone else’s mental model. Engineers try to fit creative design methodologies into their logical mental models. And that’s where things start to break apart. The only way the two mental models can fit into each other is by slowly instilling the Lego blocks of design in the engineering team and vice versa. Only when the foundation Lego layer is strong can both the team start building more nuanced concepts on top. The Foundation layer promotes more learning. And learning promotes more involvement and collaboration.

Work with the people you have. Scaling to a bigger, more functional team will only happen when teams work together harmoniously.

To enable a smooth flow of knowledge between engineering and design mental models, you have to,

  1. Create systems that support both domains. Create design systems that include style guides, a component library and support each component with some front-end/back-end logic. Like for example, when creating customer animation, support your animations with bezier curves and timing markups.
  2. Create processes that involve a bit of both engineering and design. Every team will need a champion designer and developer to lead other team members. Building mental models take time. But they can only be built bit by bit.
  3. Interchange and collaborate using different tools. Learn a bit of HTML, CSS, JS, and ‘try’ coding some of the components you designed. This will cultivate empathy towards developers.

Success Metric: Overtime, you will see both teams speaking a common language. The language will be a mix of concepts from both domains.

Problems Spec Sheet

If you are riddled with collaboration-related problems frequently, then it is time you start journaling some of the common reasons why you are in a spot where you shouldn’t be. Journal these,

  1. How can you make your team members valued by appreciating their contributions?
  2. How many times has there been story points spillover? Is it happening frequently? Why is it happening?
  3. How much is the tech debt? How long will it take to get the debt prioritized on the roadmap?
  4. Can the code and design be made more reusable?
  5. Pain points — Where are the teams struggling?
  6. Identify the process and people-related bottlenecks.
  7. Identify the silent signs of struggle.
  8. Does every meeting have an agenda? How many ad-hoc meetings does the team get pulled into? How can only contributing members be a part of meetings?
  9. How can you promote ownership, accountability of code and design?
  10. What is the process of code reviews? How frequently is it done? Is there a HiPPO effect during code review?
  11. Is my team Agile from the outside and Waterfall from the inside?
  12. How soon do design and engineering collaborate? Do designers feel comfortable letting engineers roam around design files in the WIP stage? Is there any design QA happening before every release?
  13. Are the designs getting built on vague requirements? Are the design decisions supported by data or user insights?
  14. What is the current level of UX maturity, and how can you improve it?

What NOT to do

  • Don’t work late nights to cover for the increase in scope. People will expect it is your job to spoon-feed everything and keep scoping tidy.
  • Don’t work weekends creating and deleting redundant tickets. You will only make a facade of a perfect sprint on JIRA, and extra work will keep falling to you every time there is an issue.
  • Don’t document your working methods because no one in their right mind will read them. Every time I dropped a document bomb onto my teams, it led to me feeling proud of myself and only one-two people giving it a read.
  • Don’t speak loud and assume everyone will hear you. Repeating the same message, again and again, will create deafness for your ideas.

Don’t do work in a silo that fixes broken communication lines in your teams. They will continue to be in the dark if you let them be. Become vocal about the problems, discuss possible solutions and enable teams to help you fix broken items.

Don’t burn the midnight oil for the wrong reasons.

End Notes

Building a collaborative and tight-knit culture takes time. Taking a more in-depth look at your team's inner dynamics will uncover patterns that we might have ignored before. To untangle these patterns, we don’t have to twist hard and solve them in a straight-jacketed way. Instead, try to treat unique problems with unique solutions. Flexibility, collaboration, and frequent knowledge transfer will follow.

Give me a shout!

Thank you for reading this far! 😁 Let me know if you have any questions or comments on my design — or — If you’d like to have a chat about anything design-related, I’d love to hear from you!

Before you go…

👨🏻‍💻 Connect with me on LinkedIn, Twitter, and YouTube (Subscribe).
💭 Comment
your thoughts, feedback, anything!

Designers are still doing a terrible job working with the developers was originally published in Prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.


The Case for Job Titles in Design

View the original post


How to Tell a Senior from a Junior Designer

View the original post

From design directors at Dropbox, Shopify, Clio, and more

It’s a fantastic time to be a designer. We’re finally starting to receive the kind of attention and value we’ve been clamoring for for years, decades even. With this, there’s a lot of nascent talent trying to find their own way. A lot of designers fly solo on teams without much mentorship, for others they have managers that are product managers and not really focused on human outcomes.

In my time as a product design lead, I was mentored by design directors from some of the world’s most design-forward companies. I wanted to know what they felt separated the seniors from the juniors, the cream from the crop.

From my own experience combined with theirs, here were my findings — note, none of them had to do with experience, but what experience for some could teach them. There are also many who have much experience but learned little, but that’s a topic for another day.

1. Intentionality

Seniors know what to focus on and when. They know how and when to break the rules and when not to. They know when to skip wireframes and go straight to mocks, and when to never deliver mocks and deliver a prototype instead. They know what they’re good at, what they’re not good at and how to fill the gaps in their skillset.

This sounds easy, but in practice it’s incredibly difficult. Here are some examples for both the technical side and the operational side (working with teams):

Technical intentionality

I hinted at this one already, but this has to do almost entirely with how and when you choose certain design steps and tools to fulfill end goals.

Juniors will start with a fixed process, every project. It’ll go something like:

  1. Talk to users
  2. Talk to stakeholders
  3. Create a brief (or be handed one)
  4. Create sketches
  5. Create wireframes
  6. Create prototypes
  7. Create mocks
  8. Ship
  9. Look at analytics

Seniors will look at each step, understand the goals behind each, and change processes & tools based on the project at hand.

For example:

  1. A senior may know that a project has a very clearly defined problem, thus he/she can skip research and go straight to solutions, thereby saving time. Something to note here is that a junior may believe a problem is clearly defined when it’s in fact not — leading to a rushed solution that solves the wrong problem.

Here’s a real example of this happening that I observed one day:

Jr: “I talked to a bunch of users who said the dropdown was confusing, so we’re going to switch to a tab UI pattern instead.”

Sr: “Hold up. Why was it confusing?”

Jr: “They just didn’t understand how to use it.”

Sr: “Shoot them a quick message asking them what about the dropdown was confusing.”

Turns out, users thought the dropdown was confusing because the default value was nothing, but once they selected an option they could no longer return to the default value (nothing). The senior just saved the team from going down the wrong path.

Operational intentionality

The same principles apply when working within teams. Operational skills include things like communication, leadership, risk assessment, and so forth — things not directly tied to the hard skills of designing.

For example, seniors know when to communicate and how, based on the stakeholder and the problem at hand.

If the senior is pitching an idea to product management, he/she may use a slide deck showing how a proposed design could affect the metrics that are important to that department.

If the senior is pitching an idea to development, he/she may break the design down to the parts on a whiteboard that can be shipped incrementally as that’s what the engineering team has been focused on this particular quarter.

This also applies to the senior’s own strengths and weaknesses. A senior should know that he/she is stronger at visual design, and therefore when put on a project with a heavy problem discovery component should seek assistance from someone who’s strength is in that area.

Most designers either fall into the left diamond or the right in terms of strength.

2. Influence & Impact

As I mentioned in an example in the previous section, you can see a senior’s effect when he/she is in a room. Was the senior able to add value to a discussion that would not have occurred without him/her there? Why this is important comes down to some simple math.

If a designer’s output makes the company, let’s say, $150/hr (I would love to think that all designers make a lot more for the company than they cost!). If you increase your output to $200/hr, you’re doing fantastic! You just increased your output by 33%.

But if you’re influential? Your potential is so much more. If you as a senior were able to influence a product team to increase their output by $20/hr, and/or even the design team as well, you’d be looking at an aggregate added output of 100%+! That’s because you leveled everyone else up and added to their own outputs by simply being in the room.

As a side note, that’s why people managers are so darned valuable. Their sole purpose is to level up everyone so their total output is significantly greater than they could achieve themselves.

3. Big Picture Thinking

The third biggest difference that I wanted to mention was to do with how seniors think. Juniors tend to be heads down, thinking in terms of tasks and focused on executing them to the best of their ability.

Seniors think cross-functionally, understand the business goals of what the team is trying to accomplish, and make decisions accordingly. Ultimately, everything anyone on the team does needs to be traceable back to the higher level goals of either making the company more money or saving cost. Juniors rarely can explain how what they do ties into one of those goals, seniors always can.

A senior engineer I used to work with put this so well it’s worth a quote:

As you become more and more senior, you try harder and harder to stop coding.

The same can be said about design. A senior designer recognizes that design is a cost the business is bearing to achieve a specific goal (make the product more desirable). If there is any way he/she can achieve that goal with as little design as possible, then the team should do that!

How this actually influences day to day tasks can be illustrated by a few examples:

  1. Understanding that shipping sooner is actually the biggest business value at the moment, and cutting parts out of the design process (including pixel-perfection) to achieve speed.
  2. Understanding that a part of the proposed design will be incredibly costly from engineering but provide little value to the user, swapping the pattern as a result.
  3. Knowing that a project is insanely risky but has huge upside potential to the business and therefore proposing to the product manager that the team spend an inordinate amount of time on research first.

You’ll notice a lot of overlap between these three distinctions, and I’m sure many design managers can weigh in on more traits like risk assessment, leadership, and more. These were the ones which I felt were the most important, so consider this a primer :).

I’m doing a 30m Freeform Q&A Session on March 2nd at 6pm Pacific, join us!

How to Tell a Senior from a Junior Designer was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.


Grow your design career as an individual contributor, part 3

View the original post

Career growth might not be linear. If it isn’t, what other shape can it take?

When we think about growth, we usually think of it as a linear process, like Silicon Valley’s favorite hockey stick curve — upwards and to the right, exponentially increasing. We get better and better at what we do, accumulate more and more skills and experience, and then level up.

Thinking in this way focuses on “getting ahead” and “leveling up,” and we end up feeling dissatisfied if we’re not tracking on this upward trajectory. It’s also a fundamentally competitive mindset: grow faster than others or get left behind. But, it’s not


Year 0 vs Year 3 as a Product Designer — A Retrospective

View the original post

Year 0 vs Year 3 as a Product Designer — A Retrospective

Ok, a little backstory: Nearly 3 years after its creation, I made a conscious decision to revisit one my first projects in the product design industry.

Well, to put it shortly, it was……horrendous. It resembled the aftermath of an inexperienced, wannabe chef attempting to make a gourmet five-course meal. My face while viewing it was much like that of a disappointed guest that ordered a Soufflé and got a mud cake. 😦🥴😬

I couldn’t believe how terrible it was, but rather than trash it and move on I thought this presented the perfect opportunity for some good ole self-reflection and possibly some redemption.

So painful as it may be, here we go, my 3 years of experience worth of pointers on the recipe, past vs present, a rebake if you will.

📌Summary for context: It’s a pet adoption app merged with the ideals of a dating app (swipe right, swipe left), created in collab with my college town humane society.

📌The main goal: Provide a solution to expand reach, encourage, and simplify the journey of adopting a furry friend. Secondarily, to automate some of the tedious tasks of setting a pet up for adoption.

Alright lets get into it:

#1 — Really get to know your party guests

When it came to research, I had bulk (School was great for teaching how to do that) but much of it was quantitative and surface level.

I had the number of guests…that’s about it….no names, no dietary preferences…not good.

Age ranges, statistics, Competitive analysis are all important pieces of the research phase but in my years working on the job I’ve learned to build a successful and more importantly a useful product you must go beyond the statistical data.

People are more than numbers.

#2 — Pick a Manageable Menu

Filet Mignon, Spaghetti, Sushi, Chicken…oh my.

Rookie mistake alert 🚨. I bloated my concept. As I’ve come to learn of even some more mature products, it’s easy to stretch too thin in an attempt to be “feature-rich”. Sometimes as a result, as it was in my case, you end up with lackluster and frankly confusing results.

Pawtner-Roadmap Image

I like to relate this to this master of none theory, and it had a few side effects:

My case study fell flat

  • I put the cart before the horse. I had the intent defined but didn’t follow through. There was a major lack of proper research to guide the development of each feature. Not knowing my audience well, as listed in pointer #1, set up the stage for guessing (which to a degree I would expect a sprinkle of that in a new concept, but not as the basis of an entire product🙈) The features were a mess.

Gaps in the user experience

  • Because my features were half baked, the user journey was lost. (Why would someone download this, what problem are you solving, why would they come back?)

3 — Refine my palette, better ingredients:
Reign in /Redesign the Design

Beyond some of the obvious design errors and the dated style choices (my eyes….they burn🙈) there were several things I didn’t even think to consider, do, or check back then like:

  • Checking Color Contrast Requirements
  • Considering Typography Patterns & Reusable Components (Design System was not in my vocabulary)
  • Accounting for touch target sizes
  • Understanding the impacts of scale on larger and smaller devices
  • Enhancing with interactions or transitions

(This list could go on)

It’s obvious to me now, I focused too much on the aesthetics (and I use that word lightly) and not enough on the experience.

#4 — Setting the Table with the Right Tools

This one has become one of my biggest pet peeves. Imagine, you’ve planned this well thought out, appetizing dinner but for some reason, you’ve chosen to set the table with foreign or improper utensils. It seems like a minor detail but you’d be surprised the impact it can have on the experience for your guests. (I mean who wants to eat soup with a fork)

Sidebar vs Tab Bar — Dialog Vs Modal Component Swap
Sidebar vs Tab Bar — Dialog Vs Modal

Let me clarify, I didn’t consider the platform differences. I didn’t make any considerations to the devices, OS quirks, or navigation differences between platforms🤦‍♀️. I can’t say that I even took a peek at the Human Interface or Material Guidelines.

Now I reference them almost daily and actively anticipate keynotes and announcements. It was naive of me not to realize the importance of accommodating the application’s host to provide a sense of familiarity and seamlessness to the user. It was also a mistake not to take advantage of the native power. Haptics, shortcuts, native components, the tools to better the experience are endless. (Though I have also since learned one does need to use these utensils with purpose, we don’t want to lean on the side of fancy for fancy’s sake.)

#5 — Second Date Material — There’s No Such Thing As Done

You cant expect a one & done dinner party to result in a batch of new BFFs. Much like relationships, products must be nurtured to reach & push beyond their potential.

At first, I found it frustrating to have to cut back. I had a wishlist a mile long and all of the features were important. MVP was like a curse word 🙊. I since have learned the error in my ways

Test early, ship often, seek user feedback & iterate. This is the circle of (a products) life.

And that’s it 👍 (for now). The purpose of this was not to rag on myself but rather a self-reflection of how far I’ve come. My recipe today is still far from perfect but it’s a progression. It’s crazy to think 3 years ago I was a major newbie to product design. 5 years ago I didn’t even know it was a thing, and to this day, I have yet to even scratch the surface of what it has to offer.

I feel extremely blessed to have a job that I’m passionate about. I’ve always had a hunger for learning and an inclination to creative problem-solving. This is part of why I love the tech industry so much. It’s always changing, growing, advancing. There’s always something new to learn and new ways to solution!

So, to my fellow newbs, I leave a message I wish I could leave my past self: Hang in there, you probably don’t know as much as you think you do, and… what you do know will probably change but it’s all good. That’s the beauty of the ride with design and technology, enjoy it.

To those further along the journey than I, I welcome you to share your knowledge. And to all, your feedback is appreciated!

View the new and improved case study here.

Have questions, comments, or just want to chat? Feel free to reach out on Twitter, Instagram or send me an email. For more of my work checkout my portfolio

Year 0 vs Year 3 as a Product Designer — A Retrospective was originally published in Muzli – Design Inspiration on Medium, where people are continuing the conversation by highlighting and responding to this story.


Figure out what to do; Specialist vs Managerial track

View the original post

When I was stating as a User Experience Designer, I came across an ocean of UX Job Titles. I was confused. There were –

UX Designer, Product Designer, Visual Designer, Digital Designer, Interaction Designer, UX researcher, Content strategist, UX Unicorn (Yep, I’m not kidding about this job title!)

And how do I level up if the demands of the role keep changing constantly?? 🤯

But here’s the thing…

The titles are often just a vanity thing and they’re not what you should be focusing on

What you should be focusing on and what helped me out was “Career Tracks”

This method of going through career “tracks” isn’t only for UX Designers


7 Best Interaction Design Courses That You Can Complete Online

View the original post

Be sure to choose the right one that fits your preferences.


The #1 industry to join as an innovation-obsessed designer

View the original post

It seems like most of the innovation in design craft and culture comes from the teams working in the most design mature industries—the top 5 percent of visionary companies that empower design for the greatest benefit. We often forget that almost half of companies are still operating under the assumption that design is the way apps and products look on the screen. And as these companies make their way up the Design Maturity Scale, they’re not merely following in the footsteps of those who came before. Many times, they’re blazing entirely new ground that even the most mature and innovative


UX Writing Salary Survey 2021 Results

View the original post

The post UX Writing Salary Survey 2021 Results appeared first on UX WRITING HUB.


8 Skills not related to UX that will make You a better UX designer

View the original post

Photo by Quino Al on Unsplash

In this article, I will speak about additional skills that will help you a lot in your career.

1. Photoshop and Illustrator

I know this is an obvious one, but many great UI/UX designers don’t have skills at the Great Photoshop and Mighty Illustrator. You can make it as a UI / UX designer without knowing these tools at all.

But If you know Adobe Ps and Ai well, UI tools like Sketch and Figma become easy like playing with toys.

If you don’t have the skills I advise you to learn them. There will be many times when you’ll need them. Without