large_Crossover Series NFTs.png

medium_Crossover Series NFTs.png

small_Crossover Series NFTs.png

thumbnail_Crossover Series NFTs.png

From Photography to NFT Art: Twisted Digital Landscapes with Nate Hill

From Design System to ‘NFT Design System’: Creating TinyFaces

Neurodiversity and Inclusion: Choosing Kinder Design

medium_652ccf22c8853584bde5553986a4eed0.png

small_652ccf22c8853584bde5553986a4eed0.png

thumbnail_652ccf22c8853584bde5553986a4eed0.png

Web5 is here. Goodbye Web3? TBD.

<p>Published on <a href="http://ift.tt/2nFGaOn">| Prototyping: From UX to Front End &mdash; Medium</a> Charles Reynolds-Talbot <img alt="" src="http://ift.tt/2mTsTxi"></p>
<h3>Egoless design: Reviewing the right way</h3>
<h3>Diving too deep</h3>
<p>In government we have regular design meetings; which are great events for designers from different departments to get together in person, learn more about what else is going on and feel part of a growing community. Often on the agenda is an opportunity to get a deep dive into a service that another department is working on.</p>
<p>Deep dives benefit both sides; the audience gets a chance to see how another team has used design to solve a problem, the presenters get to have many fresh eyes review the thing they’ve made. It’s a space where everyone can learn, if it’s done the right way.</p>
<p><em>I was halfway through a deep dive at one of these events. I became uncomfortable. I was nervous. I was hot. I started breathing heavily. My heart started racing. But — I was not presenting. I was in the audience. An audience that was not doing it the right way. An audience that was criticising.</em></p>
<p>Nobody benefits from criticism.</p>
<h3>Crit(ique) vs Crit(icism)</h3>
<p>These two words are too similar in form to appreciate their difference in definition. The language we use is important as it forms our mental model and approach to a situation. This is why I’m going to use the softer word review, which works better.</p>
<h3>Design reviews</h3>
<p>When we review design we should not make statements or pass comments, we should ask questions to learn more:</p>
<ul>
<li>How might you…?</li>
<li>Why did you…?</li>
<li>What did the user…?</li>
</ul>
<p>As designers it’s easy to try to <strong>think</strong> like the user, but we are not, and we can never hope to fully grasp the context of something in a short review. We should have trust in the designer(s) presenting. They have lived and breathed the problem. They have attended and observed user research sessions. They are the professionals that have been hired and entrusted to do the job the right way.</p>
<p>By asking questions, we prompt answers that will force designers to communicate the context and process in more detail. This helps them discover new ideas or alternative approaches they’d previously missed because they were too focussed. Self–captured comments will always be better acted upon.</p>
<p>It’s important to talk about what works well too. Don’t forget that this is a chance for both sides to learn something new.</p>
<h3>Three’s company</h3>
<p>With the best intentions, design reviews can still be challenging. Designer(s) can be anxious about presenting; worried that it is them or their ability that is being reviewed, rather than their work. To help ease this feeling of audience vs presenter(s), it can work well to have someone take up a third role of facilitator. A facilitator can help reviews by:</p>
<ul>
<li>introducing the designer(s) presenting</li>
<li>clarifying what we’re reviewing and what we’re not — there’s no value in discussing things that can’t be changed right now, especially if there is a specific problem area the designer(s) want feedback on.</li>
<li>asking the audience for questions</li>
<li>taking notes to help prompt the designer(s) later</li>
<li>confirming next steps</li>
</ul>
<h3>No egos</h3>
<p>There are no bonus points for egos. We’re all working towards the same goal — we all want to solve the problem collaboratively. In the beginning; it doesn’t matter what it looks like, or how it <strong>feels</strong> — it matters how it works; how people understand it and how people interact with it.</p>
<p>Ask questions. Listen. Learn. Repeat.</p>
<p><em>Originally published at </em><a href="http://ift.tt/2n9VEaX"><em>charlesrt.co.uk</em></a><em>.</em></p>
<p><a href="http://charlesrt.co.uk">Hello &#8211; Charles RT &#8211; Interaction Designer</a></p>
<p><iframe src="http://ift.tt/2kZ4o5P" width="800" height="400" frameborder="0"><a href="http://ift.tt/2lIYHWK">http://ift.tt/2lIYHWK</a></iframe><img src="http://ift.tt/2mTszhS" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou"></p>
<hr>
<p><a href="http://ift.tt/2nFWrmq">Egoless design</a> was originally published in <a href="http://ift.tt/2cAqCpx">Prototyping: From UX to Front End</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>


Egoless design

Egoless design

Egoless design: Reviewing the right way

Diving too deep

Top Stories