I used to use my gut feeling and intuition to tell what’s good and what’s not, even for critiquing my own designs and work.

Not because I was careless. I genuinely believed I had been thorough. I had spent hours on it. I believed I had looked at it from every angle. It felt right and that ‘feeling’ was the problem.

Being close to your work is not the same as understanding it. And for a long time, I confused the two.

Skipping self-critique has real consequences. They just tend to show up at the worst possible moment. Work gets submitted with decisions that were never challenged. When a reviewer asks why something was done a certain way, the designer either can’t answer or scrambles to reconstruct a rationale they’ve already forgotten, or hasn’t ever considered.

Inconsistencies slip through. A spacing rule applied on one screen but ignored on the next. A hierarchy that made sense in isolation but breaks down across the flow. Trust erodes quietly. Not because the designer lacks skill, but because the work still carries the fingerprints of someone who was too close to it when they called it done.

Over time, the absence of self-critique doesn’t just affect the output. It limits how fast you grow. Without the habit of interrogating your own decisions, you stop building the vocabulary to explain your craft to yourself, your team, and the people you are designing for.

The real design self-critique failure mode isn’t laziness

Usually, designers do look at their work before submitting. That’s not where the gap is.

The gap is that they critique against nothing.

No ground. No principles. No framing. The review becomes: does this look right? Does this feel good? And because you made it, it almost always does. Your eye is already calibrated to what you built, not to what was actually needed.

This is especially common for middleweight designers. Not because we are less capable, but because nobody explicitly teaches this in our culture, especially if you’re self thaught. You learn to execute. You learn to iterate. But the practice of interrogating your own decisions before anyone else does is rarely discussed, rarely modelled, and in many design teams here in Malaysia, rarely even practised.

The word ‘critique’, already carries weight in Malaysian context. It sounds like conflict. It sounds like something that happens to your work, not something you do for it. That mindset has to change.

Design self-critique needs a ground

Here is what I have learned: self-critique is not a final step. It is only possible if you have set the foundation upfront.

Before you open Figma, before you write the first word, before you decide on a layout, ask yourself: what user outcome am I solving for? What principles am I carrying through this work? What does good actually look like here?

That is your ground. Everything you build gets measured against it, not against whether it looks polished.

When I started doing this, the critique became less subjective and more structured. I could ask real questions. Why did I use rows of three in this card list? Why this colour here? Why this hierarchy? If I had a reason and a grounded reason tied to the framing, the decision holds. If I could not answer, that was the critique finding me first.

Not intuitive. Intentional.

Write your rationale down as you go

The second shift was documentation, not for handoff, not for the client, but for myself.

Every design is a sequence of decisions. And most designers make those decisions well in the moment, then let them disappear. The rationale lives in their head, and by the time a reviewer asks why, they have either forgotten or can only reconstruct it verbally on the spot.

Writing decisions down as you go changes this completely. Not everything. Just the ones that matter. Why you chose this approach over the alternative. What you were optimising for. What you deliberately left out.

When you include your thinking alongside the work and not just the visual, but the reasoning behind it, two things happen. First, you are forced to articulate what you actually believe, which sharpens the thinking. Second, when you come back to critique, you have something real to interrogate. Not just a screenshot, but a position, grounded against your foundational framing.

A reviewer asking why you made a decision should never catch you off guard. If it does, that is a signal that the critique was incomplete.”

And now with AI where you can augment the design assembly process, it is more and more critical to be conscious about the goal, principles and how to execute at every step along the way. This is what design work look like at Stampede, less executing and assembly, more strategic thinking and tactical planning.

Create distance before you do self-critique

The third thing, and the one most junior designers skip entirely: walking away before you review.

After a session of deep work, you are still the author. Your eye will fill in the gaps, smooth over the rough edges, and read what you intended, not what is actually there. You are too close to see clearly.

The fix is temporal distance. Close the laptop. Do something else. Come back in half an hour, or better, the next morning.

I have finished work in the evening and told myself I would do the self-critique first thing the following day and come back to find things I simply could not have seen the evening before. Not because I was tired. Because I had forgotten what I was trying to do, and that forgetting is exactly the point. Fresh eyes read the work the way a user would, not the way its creator would.

Seasoned designers can do this in real-time. They have developed the ability to zoom out mid-flow, switch modes, and critique in live. That is the goal. But for most of us especially Malaysian middleweights, the shortcut is physical and temporal separation. And it works.

The other thing worth naming: do not be married to what you built. Don’t be afraid to murder your darlings. This sounds obvious, but it is harder than it sounds. When you have spent hours on something, it’s only natural to defend it. You will subconsciously frame your review to protect the decisions you have already made. The only way past this is to approach the review with genuine openness. Treating your own work the way you would treat someone else’s.

Sharpen the eye by dissecting other people’s work

Self-critique gets easier the more you study good work.

Not to copy it. To understand it.

When you open an app, a website, a data visualisation, pause and ask why things are the way they are. What is the grid? Why this spacing? Why does this interaction feel smooth when a similar one elsewhere feels clunky? What is the overarching principles and the intent of the design? What is it trying to solve ultimately?

Most of us consume design passively. We notice when something looks nice. Few of us stop to deconstruct why it works and fewer still ask why it doesn’t, even when it looks fine on the surface.

The more you practise this on other people’s work, the more naturally you do it on your own. You start to notice the questions before a reviewer does. You start to ask, before anyone else: if someone looked at this with fresh eyes, what would they challenge?

That shift from creator to first critic, is what the practice is building toward. It’s building that muscle so it comes natural to you the more you mature as a designer.

Where this ends up

Eventually, none of this should feel like extra work. The framing, the documentation, the distance, the dissection. These should become so embedded in how you work that finishing and critiquing are the same act.

For designers who have been self-critiquing for over twenty years, that is already true. The critique is happening constantly, live, almost invisibly. It is in the DNA.

For the rest of us, we build toward it. We make the scaffold visible until it becomes instinct.

The measure, for now, is simple: before you ship, can you answer for every decision? Not defend it. Just answer for it.

If you can’t, you are not there yet.

The post Building the Eye: A Guide to Designer Self-Critique appeared first on Stampede: the strategic design & technology company.

Two things came to mind: one, is that you will not get good overnight — and knowing the fast-paced tech industry, even if you have mastered one skill, you should be able to learn new things as it progresses.

Which brings to the second point: I wish I had known that while technical skills are important, I felt I should invest more on adaptable skills such as critical thinking, strategic thinking and writing.

Why writing?

When I started writing for corporate, I was told that writing is easy. So I pretty much walked in for the job with that same mindset in mind. I thought personal blogging would prepare me tremendously for the job, and boy I was so wrong. 

When you write for your personal blog, you give less attention to your audience because you pretty much write for and about yourself. However, when you write for someone else in mind, you need to be mindful of who they are, what roles they have, what nuances are better suited for them — the list goes on. 

Furthermore, I learned how to structure my writing and vary my pace accordingly so the audience will be engaged and not get bored in the process.

Something, like below.

Now that I have ventured into tech and UX, writing gets much more challenging.

What does writing have got to do with UX?

If you notice, a large chunk of user experience is delivered through written messages. Think about the time when you are tickled pink by a funny copy on a 404 page, or being overwhelmed trying to contact several houses on Airbnb, or maybe something as routine as trying to find the most appropriate emoji to reply to Tony’s Slack message (OK, maybe just us for this one!)

No emoji? When Slack can’t find an emoji that matches your search, it shows a crying emoji in response.

Like traditional writing, all of the above mentioned are written with an audience in mind. The modus operandi is the same — find out who you will be designing and writing for, do user research, strategise, design, develop, test and launch! 

Traditional writing is often accompanied by content planning. The same goes to UX writing. It is often accompanied and informed by content strategy. UX design and writing will also consider users’ mental states at every phase of the interaction.

This is something traditional writing lacks of, and where the challenge actually lies.

Addressing the current mental state“I just sent my newsletter to 500 subscribers! What if they don’t like it? What if I have typos? Oh Freddy high-fives me!” Mailchimp took into account a user’s mental state upon scheduling a newsletter, and crafted a witty success message to alleviate it.

It seems hard, but is it worth it?

UX writing is one of the most sought after skills these days, especially with the rise of conversational interfaces and chatbots. Not only that, John Maeda, in his annual Design in Tech report, suggests that besides coding, the other “unicorn” skill a designer should have would be writing.

The need for UX writers definitely will increase. Hence it is good to start building the experience needed for the role.

So, ready to level up?

Getting started with UX writing

Start writing!

Take 15 minutes every day to write freely. It does not have to be about work — it can be about thoughts on things or whatever comes to your mind.

One good example that I came across on taking notes of your observation is in this article about engaging in the moment and putting words to things. I especially love how David describes the word ‘petrichor’, the earthy scent of rain having just fallen on soil after a dry spell, “you definitely knew petrichor before you knew it had a name.” His observation on how wine-tasting professionals let their senses take in the scene so they could describe how every wine tastes like, is also worth noting.

You can start by writing something as simple as how your day goes, or what you are thankful about. If you are having problems to write, some websites offer writing prompts to get you started:

• 365 Days of Writing Prompts
• Creative Writing Prompts
• Writing Prompts subreddit

Pay attention to UX writing in the wild

One of the best ways to learn writing for UX is to observe and learn. Medium is good place to start, as it is filled with tech articles of case studies, redesign stories, tips and tricks and many more. Case studies and redesign stories will be helpful to write design justifications — it will help you to articulate your design reasoning better. 

You can also start observing on how some microcopy on the apps you have been using influence your emotions and actions. Calling for Uber? Take note of the copy they use to book a ride. Searching for a product on Lazada? How good is the search copy on the website? Good Microcopy is also one the best places to start to learn.

Ahead of the way A recent delightful microcopy I found out was how Quora provides similar questions in line with yours. If there is no similar questions posted yet, then you may proceed to submit the question.

Get feedback

Learning is a two-way process. Once you have put down a substantial amount of practice, time to get some opinions! Getting feedback helps you to see your writing from a different viewpoint, and so you can start writing more inclusively.

If there is no access to any UX professionals around you, you can seek out feedback online. Slacklist is the good place to find a UX channel start to share your work. Alternatively, there is a number of UX Facebook groups ready to help you learn.

Build portfolio

There is also something important I learned last week from author Jocelyn K. Glei on progress, “Most of us make advances small and large every single day, but we fail to notice them because we lack a method for acknowledging our progress. So, acknowledge them.”

Tracking progress Knowing she’d be overwhelmed, Glei constructed an analog ‘progress tracker’ for all the key pieces of her upcoming podcast. The minute she created this roadmap, she felt more grounded, motivated, and in control.

You wouldn’t know how good you are at writing for UX without building your portfolio. Dropbox has a good guideline on how to start building your UX writing portfolio, taking consideration of how to present your work in the context of the user’s intent & navigations.

Process, not progress

Going back to my initial thought on Smashing Magazine tweet about not being good overnight: you will not be good overnight and that is OK. If you think about it, UX writing is a marriage of two very highly skilled disciplines — user centered design and traditional persuasive copywriting. It is understandable that it will take time to be really good at these two crafts.

So start writing, observing, getting feedback and building those portfolio. If you decide to break into UX writing, or have been doing UX writing already, I’d love to hear more of your insights about this post and your experience.

In the meantime, write on!

The post Getting Started with UX Writing appeared first on Stampede: the strategic design & technology company.

We ran through a number of websites we liked and as we cooed over every single detail that makes the user experience even more delightful, we decided to create our own Slack channel called #ui-inventory. There, we shall post our favourite interface elements, be it icon, copy, buttons, forms etc. This shall serve as references for both of us as we work on our strategies for projects as well as for our UI/UX designer, Shaza. Who knows what shall we do with the repository later?

What are microinteractions?

Microinteractions can be defined as ‘contained product moments that revolve around a single use case—they have one main task’. They can impact things such as:

• Turning things off or on
• Commenting in any digital medium
• Changing a setting or process
• Viewing a notification or message
• Sliding down the “screen” on a mobile device to refresh content (maybe with sound)
• Interacting with a data element, such as checking the weather
• Accomplishing any single task
• Connecting devices, such as those for multi-player games, or printing from your laptop
• Sharing or liking a photo or video on a website

Dan Saffer, Director of Interaction Design at Smart Design and the author of the book Microinteractions, says “Every time you change a setting, sync your data or devices, set an alarm, pick a password, log in, set a status message, or favourite or “like” something, you are engaging with a microinteraction. They are everywhere: in the devices we carry, the appliances in our house, the apps on our phones and desktops, even embedded in the environments we live and work in. Most appliances and some apps are built entirely around one microinteraction.”

The book Microinteractions is inspired by Charles Eames’ maxim, “The details are not the details. They make the design.”

Examples of microinteractions in UI

We have seen microinteractions. They are nothing new and we encounter them every day, often adding joy to our experience when they are done well.

Mailchimp’s series of monkey hands are my favourite microinteraction so far

We see them when we see new friend requests in Facebook, the iPhone 6s’ new 3D Touch feature, the Uber rides waiting for requests around our block, that the new cute iPhone cases we added to the cart while shopping are already highlighted so that we don’t forget which ones, the new Psy videos in Youtube, that we have successfully sent that email campaign in Mailchimp, the simple case of figuring the strength of our chosen password and even in our favourite Slack, when our password which consists of mixed cases and numbers got too dreadful for us to type in mobile.

How do you know you need a microinteraction?

Simon Proudfoot from Demac Media has given a great analogy on how to know whether you need a microinteraction — ask yourself two simple questions:

• Does adding this microinteraction potentially take away from the user interacting with some other part of the site? (if no, proceed)
• Does this add experience to the user? (if yes, proceed)

Otherwise, they are not necessary. In other words, think of microinteractions as some final personal touches to your product on top of the already amazing existing product.

The future of microinteractions in UI

The Next Web outlines some great guidelines on making sure microinteractions work well:

• Micro-interactions must live on through repeated use. What’s fun and quirky on first use might become annoying after 100 uses. Be cautious of gimmicks or odd design cues.
• Simplicity rules. Simple type, simple language, simple colors, and simple design. Don’t make the design any more complicated than the action.
• Give each micro-interaction a human voice. Text should read like people talk, not like a machine.
• Add a fun divot with animation, but don’t go crazy. Consider the bouncing icon in the dock of your MacBook as a program loads. It lets you know the program is responding with a simple animation but does not get in the way of what you are doing.
• Create a visual harmony with other elements. If your app has a blue color scheme, micro-interactions should use the same hues so that the visual connection to the parent design or app is there for users.
• Don’t overthink it. Overdesigning a micro-interaction can be lethal. Let’s go back to the simplicity of the text message notification. Just a simple, singular display on the screen with enough information to be effective – who the message is from, what the message contains and a way to respond.
• Consider each detail with care. Because micro-interactions are so small, every element of the design matters. Ensure that every detail, down to the last pixel, is perfected before launch.
• Think about further adaptations or how subsequent micro-interactions will work. Does the exact same thing happen every time for every user? Or are there changes to the micro-interaction over time? (Consider the alarm that gets louder each time after the snooze button is hit.) These smart details will set the best micro-interactions apart from everything else.

If done well, the tiny humanising details in microinteractions have the power to add delight to the websites or apps. They could not be done half-baked, yet they could not be overdone.

They are the details that could make or break the website or the app.

This article was originally posted on Curated@Stampede.

The post Microinteractions: Details that Are Not the Details appeared first on Stampede: the strategic design & technology company.