I&rsquo;ve talked about my history before, but I haven&rsquo;t provided explicit advice about how to make a career switch effectively.Over the past few months, I&rsquo;ve been mentoring on <a href="https://www.adplist.org">ADPList</a> which has been a really great experience so far. I&rsquo;ve managed to learn a lot about my teaching style and also about what value I can bring to people beyond the typical portfolio review or interview advice.One thing I&rsquo;ve been mentoring on and am explicitly asked about is how I was able to successfully switch careers&mdash;from account management to design&mdash;without spending a single penny on a course from one of the big bootcamp providers. Granted, a few things had to fall in place to allow that, and there&rsquo;s a high element of luck, privilege and persistence that enabled the stars to align, but, I think it&rsquo;s possible for anyone if you look for the right opportunities in front of you.So below is some of my key advice based on what I did, how I did it and why I think it&rsquo;s important. Try to look for any of these things if you&rsquo;re in a position to switch, and use them to your advantage to get there.<h3>1. Spot the signs</h3>The first thing is deciding when you think it&rsquo;s the right time to transition your career. Maybe you&rsquo;re getting bored in your current role, maybe you&rsquo;ve spent your spare time exploring things that you&rsquo;d like to do more permanently, maybe you find yourself not delivering on what&rsquo;s expected of you.I noticed the latter one and that was my key trigger. I was an account manager at a startup digital agency in healthcare. I enjoyed the industry (to some extent) because the majority of projects we worked on were outcomes focused, in areas where people were often underserved/undertreated and where we could witness real results.But I sucked at my job.I was always forgetting the priority of tasks, I couldn&rsquo;t remember deadlines or manage my time effectively, I was good at client relationships, but fell short on ensuring all the team delivery aligned. Truthfully, I just wasn&rsquo;t cut out to be managing projects full time at that point in my career and I was also just not that into it. After being pulled aside a few times on this (sorry Lee!), I ended up being afforded the opportunity to explore managing just the digital projects, with a key focus on being the face for it in the company.But why?The partners saw in me some skills that I&rsquo;d not really noticed. I&rsquo;d been coding for many years behind the scenes but fell away from it a few years before I joined, I also had a fine art degree where I&rsquo;d studied technology-based art, and I&rsquo;d worked at Apple and developed a love of hardware engineering too. So there was a clear set of skills around technology and creativity that were being underutilised and there was a gap in the business for it. Success!So rather than floundering around in a role I couldn&rsquo;t do well, causing the business to suffer as a result&mdash;and my career too. I was supported and encouraged to flip and start exploring a completely new avenue.Thanks to Lee and the team, I got to learn on the job. I started coding again (in PHP for the first time, thanks Nick!) and began to learn Javascript again. I started to map out solutions to problems by creating information architecture maps and user journeys more seriously (I&rsquo;d been doing these before, but had no idea what they all were, it just felt natural) and I had the chance to attend some industry events and learn more about the world of UX. And this was the beginning of my flip. The whole shift took around three and a half years, so it wasn&rsquo;t fast (and don&rsquo;t expect it to be), but that slow burn taught me a lot.<blockquote>Pithy takeaway: Look for signs in your current role that you&rsquo;re underperforming or unhappy. This doesn&rsquo;t necessarily mean you suck at your job, it means you could be in the wrong job for you!</blockquote><h3>2. Find a sponsor internally or externally</h3>Looking for someone to help you transition your role from within could be a great way to make the switch. It won&rsquo;t always make sense, and you won&rsquo;t always find it but it can have a major impact on helping you get to where you want to be.In reality, there&rsquo;s two paths you can likely look to take:<ol><li>Find a sponsor within and make your move internally</li><li>Work behind the scenes and make the switch by switching companies and starting fresh</li></ol><h4>A sponsor within</h4>When utilising the sponsor within your organisation, you&rsquo;ll need to share your reasons for wanting to shift and likely in some ways interview for the switch (and possibly have to actually interview if it&rsquo;s an internal job advert).Importantly, internal sponsors can open doors and unlock opportunity. In my case, one of the business partners gave me the chance to explore the things I appeared to be both better at, and more interested in, as a way to get out of the cycle of underperforming but also as a way to fill a hole that existed in the business but wasn&rsquo;t actively thought about.Sometimes though, that internal sponsor isn&rsquo;t available, so your next option is to look outside.<h4>A sponsor outside</h4>If you need to look outside, scout your available network first before relying on applying for jobs. Remember that at this stage you&rsquo;ve got zero track record of actually doing the job you want to, so you&rsquo;ll need to be conscious of how that&rsquo;d appear to a recruiter.No-one wants to be in the Nope Pile&trade; so do everything you can to not end up in it.Although I found my sponsor within, once I started those new roles I had some very weird titles from our collective lack of understanding what I now did. I was a Digital Innovation Manager (what!?) and then a Digital Lead (🤷🏻&zwj;♂️) and then finally a Lead UX Architect (better!).Sometimes, when applying for roles later I massaged my titles into what they were in common parlance to make it easier for the interviewer or recruiter to figure me out. So I was a UX Designer and then a Lead UX Architect.After that I moved to a new job and I ended up as a Senior Solutions Designer (what!?) so I called that a Senior Product Designer initially but have since swapped it to Senior Design Engineer because again, it more accurately reflects what I did.None of this is lying, it&rsquo;s about making it easier for a recruiter to make sense of what you did if you&rsquo;ve worked at companies that have non-traditional job titles.When considering an external sponsor, look for someone who might be willing to take a punt on you. Search networks such as <a href="https://www.adplist.org">ADPList</a> where you can find mentors, and if you impress someone enough, who knows what might happen! Equally, don&rsquo;t be afraid to scout Twitter for people you respect and send them a DM if you can, you&rsquo;d be surprised how often they&rsquo;d reply.<blockquote>Pithy takeaway: Look for opportunities in your current role to start exploring things that interest you, narrow in on them and start exploring them. Aim to find a sponsor internally or externally that&rsquo;ll afford you the space to do it, and take that leap.</blockquote><h3>3. Find a mentor outside of your workplace</h3>So on the subject of ADPList and mentorship, there&rsquo;s a lot of options out there. The reality with most mentoring is that it&rsquo;s normally a free service where industry experts dedicate some spare time to helping you, so set your expectations at that level.You&rsquo;ll potentially gain a lot of useful advice but try to have more than a single mentor. One mentor will be biased on their experience (see above everything I&rsquo;ve said about my very specific story) so having a couple can help alleviate some of that. Equally, because most mentoring is free and delivered in a mentor&rsquo;s spare hours, be conscious of wasting a mentor&rsquo;s time by not showing up or by being unprepared.A mentor will be able to give you some generic guidance or offer feedback on work you&rsquo;re producing such as a portfolio review or CV assessment, but I&rsquo;d urge you to utilise them more as a sort of a shoulder to lean on.Talk to them about your frustrations, your challenges, your successes, your questions. Get their advice and soak it up. Keep notes, always keep notes. And follow up from previous sessions to keep a thread going.Importantly, remember that they&rsquo;re to help you but it&rsquo;s you who wants their help. You need to drive the conversations and come ready with questions and requirements otherwise you won&rsquo;t utilise your sessions well.I&rsquo;d recommend structuring your sessions like this:<ul><li>Pleasantries (&ldquo;hello, how are you?&rdquo; etc)</li><li>What happened this/last week?</li><li>What&rsquo;s the biggest thing on your mind right now?</li><li>What&rsquo;s frustrated you the most this past week?</li><li>Next steps</li></ul>I know it feels really formal, but structure helps with consistency and progress. You don&rsquo;t want to waste yours or their time.<blockquote>Pithy takeaway: Looking for support outside of your workplace is key. Internal colleagues will often see you for who you are in the workplace (i.e. your current role/title), external mentors will be free of most bias and focus on helping you get to your next step.</blockquote><h3>4. Start free, then maybe spend money</h3>This is an easy one. There&rsquo;s a tonne of Bootcamp courses out there that charge extortionate amounts of money. I won&rsquo;t name and shame, but the sums are ridiculous, especially because I&rsquo;ve spoken with many mentees that didn&rsquo;t even get roles or any further success after spending $9k on a course from a well known provider.Lots of people are out there to make side income, and lots of people will charge for the services they offer. That&rsquo;s okay, but be wary. There is so much free content available that can get you to where you want to be, especially in design or development, so always start there first.Free resources may not always have a certificate, but that&rsquo;s okay, having a certificate isn&rsquo;t everything. The reality is that showing the work you&rsquo;ve made is what&rsquo;s most valuable, not having a certificate with a Bootcamp&rsquo;s name on it.As a hiring manager, I don&rsquo;t really mind what your background is if the work speaks for itself. I&rsquo;m biased here because I had a non-traditional background, but, I think most hiring managers would be the same.<blockquote>Pithy takeaway: There&rsquo;s a wealth of free resources out there for any career, particularly design and development. Take advantage of all of that great thinking and sharing, and build your knowledge from there first. Then, maybe, hit a bootcamp if you absolutely feel you want or have to.</blockquote><h3>5. Create example work from your own briefs</h3>Something that&rsquo;s always been difficult for me to swallow is portfolios where someone is new to the industry (either junior or switching careers) and it&rsquo;s filled with redesigns of Spotify or Gmail etc.These projects can be really interesting from a thinking and execution perspective. I can get a clear idea of how you think about a problem you see and how you execute on that. But, your solution has to ignore all of the internal constraints those teams face. So whilst it may look amazing, there are likely many reasons they&rsquo;ve not shipped something similar.Queue the incoming stream of unsolicited redesigns based on <a href="https://twitter.com/desandro/status/1562435848389332993">this.</a>What I&rsquo;d prefer to see is a set of self-initiated briefs. What if you could design/build an app or website from scratch to solve a specific problem you face? How would you tackle that?There&rsquo;s also great brief generating platforms out there that you can use as thought starters. I&rsquo;d always prefer a personal problem personally, from both my own perspective and as a hiring manager, because you&rsquo;ll be more personally bought in to the idea. But briefs will feel more like working at an organisation and allow you to test working in an area you might not be as passionate about.Check out <a href="https://goodbrief.io/">Good Brief</a> as a great starter. You can use this for development too but focus more on the logic and tech stack than on the actual design itself (use <a href="https://tailwindui.com/">TailwindUI</a> or other similar things to simplify the UI part for you).<blockquote>Pithy takeaway: There&rsquo;s a tonne of free brief generating sites out there, or you can think about a problem you face and create a solution for it. I&rsquo;d always urge you to avoid popular product redesigns because there&rsquo;s often a tonne of constraints you&rsquo;re unaware of so it doesn&rsquo;t feel realistic to a recruiting manager.</blockquote>Hopefully some of those insights and tips help you on your switch if you planning to make one.Remember, most importantly, that all of your experience is relevant and valuable. It doesn&rsquo;t matter where you&rsquo;ve switched from and what you&rsquo;re switching to, there will always be valuable skills you can pull over.When you go to interview, consider these things and really highlight them during the process. If you do what I did, you can emphasise that as an Account Manager you learnt the value and importance of stakeholder management and relationship building. As a designer or developer this is an extremely valuable skill you might otherwise not learn until you hit a more senior level.So try not to see your past as a crutch but instead as a jet pack for your burgeoning new career.Send me an <a href="mailto:karl@kejk.tech?subject=Switching%20article">email</a> if you&rsquo;re interested to chat more about this, or if you want mentoring support you can find me on <a href="https://adplist.org/mentors/karl-koch">ADPList</a>.

Shift gears and switch careers

<h2>The hunt for better RegEx</h2>Since I&rsquo;ve been working with frontend code, RegEx (short for Regular Expression) has been a constant and confusing minefield. RegEx has been around since the early 50&rsquo;s, and with it comes a tonne of power but also a tonne of complexity.The trouble with RegEx is that it&rsquo;s wholly unreadable. So a bunch of different places have cropped up with ways to input expressions and have them <a class="inline-link" href="https://regex101.com/">decoded/validated quickly</a> and simply. This makes thing a lot easier if you know what you&rsquo;re doing, but it&rsquo;s still hard to make sense of it by default.Dan Eden wrote a great post on <a class="inline-link" href="https://www.daneden.me/2019/11/23/regex-for-designers-and-writers/">understanding RegEx</a> from a designer/UX writer perspective, which offers a great way to make better sense of the complexity, but it still requires a tonne of work to construct a good pattern that works.<h3>Clipping URLs</h3>I was working on a personal SwiftUI app project to pull all of my <a class="inline-link" href="https://www.kejk.tech/bookmarks">Cosmic bookmarks</a> into a native app so I could browse and enjoy them there, whilst also posting them publicly to my website.Originally I just had the title and snippet text for each, which was fine (you can see this mirrored on my <a class="inline-link" href="https://kejk.tech/">homepage</a>) but I wanted to enhance this for easy scanning and for searching (using iOS&#39;
native search bar) by including the source URL.The problem I had was clipping that URL. A lot of them came with a tonne of junk after the domain, which was mostly unnecessary, and all of them came with a prefix of <code>https://www.</code> or <code>https://</code> which was added noise. What I wanted to find was a RegEx pattern that would allow me to clip out that prefix and suffix info, so I&rsquo;d be left with a simple <code>kejk.tech</code> or <code>docs.cosmicjs.com</code> for example.Hunting StackExchange and the web in general gave me loads of expressions but nothing ever quite hit the mark for me. So I decided to try and craft my own expression and provide it below so you can borrow it for your project too.The great thing about RegEx is that it&rsquo;s platform agnostic. I use the same expression in SwiftUI as I do in JavaScript.I&rsquo;m pretty confident that this is more verbose than it needs to be, but, it works every time and cleans things up a treat. So, I present to you, the URL trimmer.<pre class=" language-regex"><code class=" language-javascript">const regex =</code><code class=" language-regex">/.*https:\/\/www\.|http:\/\/www\.|https:\/\/|http:\/\/|\/.*$/gm</code>;</pre>Here we look for any character in the URL string using&nbsp;<code>.</code> and then match that with unlimited searches through the URL string with <code>*</code>. After that, we basically have a bunch of OR matches using pipes:<code>https://www.</code> OR <code>http://www.</code> OR <code>https://</code> OR <code>http://</code>Then at the end we ask it to look for anything that appears after the first solo <code>/</code> by using a <code>.</code> to match any character, then <code>*</code> to perform this an unlimited number of times (again) and then terminate the search of the string with <code>$</code>.To close it all up, we use <code>g</code> to ensure this is a global search and doesn&rsquo;t stop once it makes its first match (just in case), and then use <code>m</code> to allow for multi-line searching and matching.And that&rsquo;s it. It&rsquo;s pretty verbose, but it works across all URLs I&rsquo;ve encountered and trims them up real nice. Below is how this appears when set up inside a React map. Here we create a new constant to fetch the URL from Cosmic and replace
any occurrence of the regular expression with an empty value.<pre class="language-jsx" tabindex="0"><code class="language-jsx"> &lt;div className=&quot;mt-4 grid grid-cols-1 gap-8 md:grid-cols-3&quot;&gt;
 {bookmarks.map((bookmark) =&gt; {
 const trimmedURL = bookmark.metadata.url.replace(regex, &quot;&quot;);
 return (
 &lt;a
 key={bookmark.id}
 href={`${bookmark.metadata.url}`}
 target=&quot;_blank&quot;
 rel=&quot;noreferrer&quot;
 &gt;
 &lt;BookmarkCard
 title={bookmark.title}
 subtitle={bookmark.metadata.snippet}
 date={bookmark.metadata.published}
 url={trimmedURL}
 /&gt;
             &lt;/a&gt;
 );
 })}
 &lt;/div&gt;;</code></pre>Hopefully for any of you who do frontend work and might need something like this, you&rsquo;ll be able to take advantage. For everyone else, sorry!

Strip your URLs to super simple domains

All good design processes start by understanding a business or customer problem and then working out the details until you get to a point of confidence through research to actually build the thing.The truth is, all good development processes start in the same way. You can&rsquo;t define and design an API without understanding the problem it aims to solve. &ldquo;Do we already have an API that can provide this if we extend it?&rdquo;, &ldquo;Should
we build a lightweight, and new, API to send these data?&rdquo;, &ldquo;Is this is even the right problem to solve?&rdquo; and so on.Whilst I don&rsquo;t work on constructing or crafting the APIs that I design customer solutions with, I do keep a tight eye on how we&rsquo;re designing the API so I can best understand how we might go about designing a frontend solution that takes advantage
of these data.<h3>Building a strong foundation</h3>When I first started working alongside development teams, I found that in most places I worked they operated in a bit of a silo. Design was seen as the paint on top of the technical solution, and whilst we might work closely with mobile engineers to ensure
what we designed got built correctly, we didn&rsquo;t really stay close to the backend engineers crafting the APIs.Over time I got super curious. We send data to our frontends via this mysterious thing call an API, what is that and how can I better understand it to know the impact it might have on my work?An API, or Application Programming Interface, is a mechanism by which you can send or receive information over a network to update or interact with an interface. There&rsquo;s lots of different methods you can utilise such as POSTing something (sending
it), GETting something (receiving it), DELETEing something (deleting it&hellip;) or PUT/PATCHing it (modifying it).As designers, we should care about what data is being sent around because it inherently defines what we might show to a customer or what controls they might be able to interact with.<h3>Making APIs tangible</h3>Let&rsquo;s say you have a form that you want to allow a customer to enter their name and email into. Understanding that this is an input that allows the customer to send data to a server to store this information is super handy. This means that submitting this form would send a <code>POST</code> request via the API to your server to append these data to the database.<pre class=" language-json"><code class=" language-json">[ </code>
<code class=" language-json"> { </code>
<code class=" language-json"> &quot;name&quot;: &quot;Will Smith&quot;,</code>
<code class=" language-json"> &quot;email&quot;: &quot;will@freshprince.com&quot;,</code>
<code class=" language-json">  &quot;weapon&quot;: &quot;slap&quot;</code>
<code class=" language-json"> }</code>
<code class=" language-json">]</code></pre>But lets say you decide after the API is built and the success criteria are defined, that you now want a customer to be able to add their phone number. In this case, firstly the API isn&rsquo;t built to handle a number or to send that particular request,
so now the backend team will have to modify the API (and also importantly, the database) to understand that a number can also be sent.Sounds easy right? But imagine if you&rsquo;re making lots of these tiny changes, things like splitting name into <code>firstName</code> and <code>lastName</code>. In most companies, the backend work will start before the build phase begins. This means
that any change has a risk of derailing the approach that was originally conceived by the backend team.You hopefully already had some thoughts, sketched some ideas and started to ideate, but not finished with your design yet by the point you raise these changes. This is good, you&rsquo;re working in an agile team, but you&rsquo;re also at a point of increasing
project scope and increasing the project risk.<h3>De-risking design and APIs</h3>One exercise I like to do to prevent as much of this risk as possible is to design API-first. By designing the API in tandem with the backend engineers, you de-risk future problems. You can eek out the edge cases and plan for possible future adaptability together.<blockquote>&ldquo;If I decided to add in the need for a mobile number to be sent too, would that be a lot of extra risk? This idea is still being considered but isn&rsquo;t final&rdquo;</blockquote>A great way to do this is to build out your foundation together via early stage workshops. Recently I&rsquo;ve introduced the practice of including a representative across each of our respective teams at the very start of the design process, when we&rsquo;re
discovering the problem to solve. This means we have Design, Product, Mobile, CloudApps (backend) and QA in the room (sometimes also customer support or ops depending on the project).Including these teams early means we define edge cases from the outside and design a flexible API and design solution that works for all teams across build, testing and production.We&rsquo;ve started workshopping all of this work inside of <a href="https://www.figma.com/figjam/">FigJam</a> and it&rsquo;s been game-changing.Last year, FigJam introduced the ability to include code blocks in your diagramming experience. This opened FigJam up to being super useful for engineering teams who are writing particular code and want to connect the dots. I noticed a few team members
were using it to connect their APIs to mobile code which helped them to better visualise how the data would pass down and be rendered.<figure><img src="https://imgix.cosmicjs.com/59bfb450-0a84-11ed-b7be-d956591ad437-CleanShot-2022-07-23-at-13.36.432x.png" alt="An image of a FigJam canvas with API documentation pointing to different Wireframes to show where the data is passed to in each case" class="fr-fic fr-dii"><figcaption>An image of a FigJam canvas with API documentation pointing to different Wireframes to show where the data is passed to in each case</figcaption></figure> I decided that it made sense to me, as a designer, to include this type of thinking into my flows too. So I started to get the teams to share their API docs with me so that I could include them as flow starting points for certain wireframe screens. Now,
the connection between what data we expect, when we expect to receive it, and how it changes the view was all in one place.When QA then came to test the edge cases, they knew when we&rsquo;d expect to have received (or sent) data to or from the API, and in turn how that would impact the user interface. All teams would be on the same page, from the start to the end.<h3>How this is impacting our shipping process</h3>Since taking this approach, we&rsquo;ve seen several cases where the time to delivery has been significantly reduced, that the edge cases we find aren&rsquo;t show stoppers because we knew what to expect from the start, and that our teams could all be
aligned from the outset.Our end-to-end QA process is significantly improved because the data they test with in Postman is aligned to the docs and flows we have in FigJam, and there&rsquo;s very little left to ambiguity.This is still the exception and not the rule, we&rsquo;ve been trialling it in our team because my knowledge of code allows me to suggest and test these approaches whilst understating what the APIs mean and why it&rsquo;s useful. Onboarding other designers
and teams to this idea will likely be challenging because the value isn&rsquo;t immediately obvious, and the lack of technical understanding will be a limitation.But, this is something I see as a great opportunity for teaching. I&rsquo;ve been putting more and more energy into teaching my team how to understand the raw basics of coding, focusing initially on basic JavaScript as part of Figma plugin development,
but slowly moving into understanding how data passes between platforms and why this matters to their day-to-day.

Designing API-first

In my career, I&rsquo;ve been used to being one of one or one of two designers on the team. It was always a pretty lonely experience but also empowering because I was the sole design decision maker, or, I only had to convince one other designer of why
we should take a certain direction.On the flip side, I ended up missing out on a large chunk of design education. I never had the benefit of learning from my peers or gaining lots of great feedback through structured critiques.Somewhat arrogantly in the beginning, I told myself that I didn&rsquo;t need that. Not that I knew enough about designing but that I could figure it out on my own. That being part of a bigger team would dilute my influence and I&rsquo;d be worse off in
my career.The truth is, being part of a larger design team that offers a structured critique process is actually one of the best things you can experience. But only if your team defines a process.<h3>Never forget Context</h3>When I first joined <a href="https://www.moneyboxapp.com">Moneybox</a>, we were already actively doing design crits on a Friday afternoon. They were a relatively informal affair and we&rsquo;d show up, say if we wanted to show some work, then jump into
an Overflow file or Sketch file and just zoom around the canvas sharing some relatively unfiltered and unstructured thoughts about our design and open it up to the room to comment.The problem was, there was little to no context. As a growing company, we&rsquo;re split into separate workstreams which we call missions. This allows us to separate our individual strengths and deliver across the different areas of the business. As a
design team, we&rsquo;re no different. We split against these missions too and whilst this makes it a lot easier to focus our individual energy on a specific and consistent area of the business (such as Payments or Retirement), it also means our knowledge
of the wider design changes is fragmented.As such, context is really important when we share our work with each other. Without proper context, we lose any hope of offering great feedback. However, it&rsquo;s very possible to over or under contextualise, and finding the balance can be extremely
tough.<h4>So how do you create good context?</h4>Firstly, utilising slides is a powerful approach. Much like presenting your portfolio to get a job or sharing a monthly update with the wider business, slides offer a set of constraints that ensure you don&rsquo;t share too much at a time. They act as
a container for your explanation and ensure that you must only show the highest clarity visual explanation of your solution.It also offers a way to create a proper sense of storytelling and setting yourself up for success comes from setting up a great story.<h4>Using a design process to build your story</h4><ol><li>Start with what you&rsquo;re going to share</li><li>Set the business context / business problem</li><li>Define your customer problem statement (if applicable)</li><li>Share any hypotheses you have</li><li>Show a couple of experiments but never more than three</li><li>Showcase the solution you&rsquo;re most convinced solves these problems</li><li>Ask for specific feedback on your designs</li></ol>There&rsquo;s plenty of other approaches to storytelling and lots of great articles on what you can do, but this is the approach I always aim to take.You may ask &ldquo;what if my work is still really early stage?&rdquo; Or &ldquo;I don&rsquo;t have a problem statement&rdquo;. Well, you&rsquo;re in luck, this process still works.If you&rsquo;re in the early stages, the only difference should be the fidelity of the work. You can also show three experiments and ask for your team&rsquo;s thoughts on which direction to dig deeper into.If you&rsquo;re more focused on the earlier stages and don&rsquo;t have a problem statement. Front load a bit more heavily on the context and ask for support in getting to a great problem statement. But, remember that a crit session is aimed at providing
feedback, not solving problems. So be careful of converting it into a workshop. Always ensure you have a starting point which you&rsquo;re asking for feedback on, rather than asking your team to help craft it.<h3>A critique is not a workshop or ideation session</h3>I&rsquo;ve seen crits turn into sessions where a designer is essentially trying to solve their problem by getting lots of design heads together. This is important, but it&rsquo;s not the goal of a crit. A crit is intended to receive feedback&nbsp;on an approach, idea, solution, not to get the answers to your problem.As a designer, it&rsquo;s your responsibility to bring your ideas to the table and create enough context to get meaningful feedback. Going into a crit expecting your team to solve your problems is like going to a bar and expecting the barman to drink
your drink for you.After a few failed sessions, it became clear to me that slides were necessary. But rather than enforcing that approach on the team we chose to take a &ldquo;learn by observing&rdquo; approach.I went into my next critique armed with a well considered deck that followed the earlier process.I shared my work, got excellent and actionable feedback, went away and updated my designs and presented them back the following week to high fives all around. The process worked, and worked well. But what I also noticed was that most other designs on
the team came to the next session armed with excellent presentations and the process continued.<h3>A critique is not criticism</h3>Something I struggled with earlier in my career was receiving feedback. Feedback often felt like a criticism of my work, of me.It&rsquo;s very common in the earlier stages of your career to feel emotionally attached to your work. To think of the design as a little piece of you. But the truth is, it&rsquo;s just an artefact. A fragment of an idea that you&rsquo;ve been the one
to extract.It took me several years to learn to detach &ldquo;me&rdquo; from the work. Whether that&rsquo;s my <a href="https://www.verywellmind.com/what-is-the-id-2795275">id</a> complex expecting instant gratification for the work I&rsquo;ve put in to everything or just because of the time it took to create, it&rsquo;s been hard.But detachment is key to getting great results. A critique shouldn&rsquo;t feel like it&rsquo;s harmful or personal. It shouldn&rsquo;t feel like an attack. If it does, there&rsquo;s two things wrong:<ol><li>Your critique isn&rsquo;t structured well for feedback and the context isn&rsquo;t clear enough</li><li>You&rsquo;ve not been able to disconnect yourself from the work</li></ol>Number 2 is harder to solve, that&rsquo;s something you&rsquo;ll need to take time to work through. But number 1 is the point of this article.Through a great design process and through structured communication, you can ensure that crits don&rsquo;t fall to criticism. If you feel personally attacked, it is likely unintentional but it&rsquo;s worth discussing with the other designer(s) afterwards
to resolve the personal conflict.The other approach is to be very clear about what you&rsquo;re not looking for feedback on. That&rsquo;ll help structure your feedback and help the rest of the team narrow in on what you need.&ldquo;I&rsquo;m looking for feedback on the execution of this new call to action style. What I&rsquo;m not looking for is feedback on the illustration or customer journey as I&rsquo;m not able to change this within the project scope&rdquo;.Being upfront and clear avoids any confusion or misinterpretation. And if someone feeds back on one of those things, politely explain that it wasn&rsquo;t in scope for this session and move the conversation on.<h3>Continuing a great process</h3>As we onboard new designers to the team, again, we don&rsquo;t explicitly mention that we should follow this process anymore. It&rsquo;s not that we can&rsquo;t, but we just don&rsquo;t need to. By default our team shares in this way and new designers
learn by observing when they join.One of my team mates built a fantastic presentation library in Figma that we leverage for crafting our crit presentations. These have become so admired that our wider business want them for their use too&hellip;Every week now, I look forward to our crit sessions and see them as a valuable opportunity to offer my recommendations or to ask lots of questions. It&rsquo;s a safe place for designers to push each other out of our comfort zones or challenge and approach
without it having to feel critical or unreasonable.Our crits are completely invaluable to our process and our <a href="https://twitter.com/_kejk/status/1492098919530172425?s=21">success</a>.<h3>Squaring the circle</h3>Ultimately to bring it back to my origins. I thought that joining a bigger team would lead me to have less influence but it goes to show that no matter how small of a change you encourage, it can have a wildly large impact.Hopefully you&rsquo;ve learnt a bit about &ldquo;how to make friends and influence designers.&rdquo; <a href="mailto:karl@kejk.tech?subject=Crit%20process">Shoot me a message</a> if you&rsquo;ve experienced anything similar and let me know if you disagree with anything I&rsquo;ve shared.

How to make friends and influence designers

<h3>A free minimal wallpaper of Ram&#39;s ten principles.&nbsp;</h3>I&#39;ve long been a huge fan of Dieter Rams and his extensive portfolio of work at Braun and Vits&oelig;.When I heard that Gary Hustwit was looking for funding to film a movie about Rams&#39; career, I couldn&#39;t resist backing it on <a href="https://www.kickstarter.com/projects/1019019367/rams-the-first-feature-documentary-about-dieter-ra" target="_blank">Kickstarter.</a>One of the perks was to get a letterpress of the ten principles on card. This was set in a beautiful font close to <a href="http://atipofoundry.com/fonts/archia" rel="noreferrer" target="_blank">Archia</a> by Atipo (I believe it might be <a href="https://fonts.google.com/specimen/Space+Mono?query=space+m" rel="noreferrer" target="_blank">Space Mono</a> by Colophon) that I wanted to reimagine for the digital screen as a reminder of the principles. This allowed me to have a constant reminder to ensure my designs are always refined and focus on delivering maximum value in a minimal form.&nbsp;I&#39;ve made this wallpaper available to download in three sizes for mobile, tablet and desktop. You can grab them below. In my version, I&#39;ve set this in Archia.<a href="https://res.cloudinary.com/kejk/image/upload/v1590345853/Desktop_bwwsio.png" target="_blank"><img src="https://res.cloudinary.com/kejk/image/upload/v1590345853/Desktop_bwwsio.png" class="rounded-xl fr-fic fr-dii" style="max-width: 900px; width: 100%;"></a><div class="flex flex-row justify-center"><a href="https://res.cloudinary.com/kejk/raw/upload/v1590345921/Rams_Ten_Principles_Wallpapers_god3jk.zip">Download all</a></div>

Ten Principles for Good Design

A free minimal wallpaper of Ram's ten principles.