Design Meditations: Design Flow Weaknesses

Why a design can take months instead of weeks to be fully implemented. From my own experience.

1. Too much research & endless discussions

   Too much research confuses the designer and leaves them unable to make a decision.

   Worse if it's a big team and everyone keeps meeting to make a decision but ends up brining more inspo to consider. It never ends and no results are yielded, even 5 meetings.

   This is Hick’s Law for design process, not just UX design. To avoid that:

   • Limit the time for research.

   • Have one meeting to discuss, then make a decision. No more than 2 hours per decision. If wrong, so be it. At least you eliminated an assumption.

     
     

2. Reaction sessions instead of design reviews

   A busy reviewer reacts to a 3 minute presentation. Not fair to either them or the designer. And ultimately unfair to the product, which should be experienced and felt, not reacted to. Therefore:

   • Send designs to reviewers before an internal or stakeholder meeting.

   • When they still come unprepared: Ask the question that opens discussion rather than the question that defends the design. "Where did you get confused?" lands differently than "what do you think?"

   One invites a collaborator. The other invites a judge.

   
   

3. No delegation

   if a designer takes days to deliver 5 screens because they were stuck working on a video asset, get a graphic designer. same for microinteractions, design policing, etc...

   This one is my hamartia. Pack of one to the last breath 🙄.

4. Unwise time allocation

   Work smart, not hard:

   • Presenting yourself? a figma prototype is enough. You can control the scenario & stick to it.

   • Sharing a prototype for feedback? if heavy & complex use a claude html prototype. Much lighter than Figma, much closer to real UX, and much quicker to make than native.

   • Need a wow factor? go full on and do a native iOS or android build to present. Only go this way if you have the time and need to impress a tough client.

5. Too many design QA cycles

   if QA cycles are too many after implementation, the problem is the handoff or the developer’s skill level. To fix that:

   • create a hand-off checklist to ensure no back & forth with the developer.

   • be open with dev leadership without pointing fingers or calling names. Just showcase difference in quality. Let them handle it.

   
   

6. Accepting all ideas

You need to be able to defend a design path and only allow feedback that goes with the direction. Not everyone gets to change the design:

• Never make a design decision you cannot back up in a defense meeting.

• Learn to say no. Very hard this one. I still struggle with it.

Any other weaknesses you know of?

—-

Now I'm no Marcus Aurelius, but I believe that leading a design team requires strategy just like leading an army. And so why not can we make our own 'design meditations'? no one will read them hundreds of years later but we can help each other now, right?

🔥Tip🔥

If you haven't read Marcus Aurelius's Meditations, or could not get through the printed version I suggest the audio version read by Richard Armitage. A whole different experience.

——

Till next time, lots of love and #keepdesigning 🩷