The radio station in question has an app and is available on smart speakers but the kitchen is a sacred space for my mother. The only technology allowed is a 10 year old Denon Hi-Fi system and a landline telephone.

What I find amazing is they actively want to give this service their money and technology is making things harder. The irony wasn't lost on me.

I'm a designer. I work in tech. I should be able to build a device that can do this, right?

Vision

Plug in the device → Radio starts playing

It really needs to be that simple. That level of simplicity is, in fact, incredibly difficult to achieve.

Thinking like a designer

Who's the audience, what are they familiar with, what feedback do they need when there's no interface? What happens when wifi drops, or the stream fails, or their subscription expires? These are types of experiential risks I consider all the time at work.

My approach

There will be no visual interface so everything needs to happen automatically, invisibly, and only make a sound when it’s really important.

Boot sound —Acknowledge that the device is on (there are also some LEDs as visual indicators). Unfortunately there is no way to create a true boot sound and nor is there an onboard speaker so playing this after 20 seconds will have to do.

Status messages — Spoken messages (rather than sounds) that loop every 30 seconds that include instructions on how to 'fix' the issue "Turn it off and on again". I used ElevenLabs to generate messages in an approachable British accent.

Auto-connect — I know their Wi-Fi name and password so I created a dummy Wi-FI network to test. This should allow the device to connect automatically when it arrives.

This can't be a unique problem

What about actually streaming the radio? I can't be the only one to face this issue, or a version of it. I subscribed to the station and ordered a Raspberry Pi, then searched for ways to stream radio on it.

I found a few music servers but only Lyrion Music Server was mature enough and had plugins that support the station I needed. Install it, add the plugin, log-in, click play and DONE. Almost. It was unstable, and difficult to automate.

I spent hours working through the documentation, building watchdog services to monitor and restart the audio. And every morning it was dead. Checking the logs gave no specific errors.

Troubleshooting for my parents needs to be no more complicated than "unplug it and plug it back in". This was not going to work. Back to the drawing board.

The solution

I was overthinking things. If a third-party plugin could stream this app-only radio station then surely I could as well. I instructed Claude Code to inspect the plugin and the stream URL (from the first-party app) and reverse engineer a way for me to get direct access. We discovered the URL does not contain API keys or be obfuscated in any way; it simply contains the user ID of the paying user (so it does some internal check before playing).

This means if I could get the user ID, I could use the stream directly and drop Lyrion entirely. This solved 95% of my problems and the stream ran for days while I was working through other parts of the experience.

With the hardware issues sorted I needed to work on how I would explain, even to my father, how to put it all together.

A quick-start guide

I designed and printed a card to sit just inside the lid of an Apple TV box that I'm shipping everything in. My dad will set it up and he's more tech-savvy. This was just a bit of fun.

Great! Now they know to plug in the antenna first, where to plug in the cables, and what to do before turning on the device (so they can hear the personal message I've recorded for when the device is warming up).

Packaging

Why stop at a quick-start guide? Let's cover up the fact that it's an Apple TV box. After all I don't want them to think I've bought them an actual Apple TV; that's the last thing they want.

I had some fun copying the technical details from the side of the Apple TV. I don't know if they'll read it but it was fun and tongue-in-cheek.

The finished product

The always-on, zero-setup, plug-and-play Premium Radio Streaming Box.

The reveal

Christmas morning, I watched the video call as my dad unwrapped the box. "Oh, that's great," he said, genuinely pleased. "Where did you find that?"

Find it. Not make it.

For a moment I considered explaining the week I'd spent debugging Lyrion, the hours on the self-healing uptime monitoring, CLI tooling, the ElevenLabs voice generation, the tongue-in-cheek packaging I'd laboured over (maybe one day I will) but right then I simply replied: "I made it".

We hung up. He went to set it up.

A few minutes later my phone buzzed with an Uptime Kuma alert: Device online. I opened my laptop, SSH'd in through Tailscale and ran a status check:

System uptime: 7 minutes  
Stream status: Playing
Playback duration: 6:30

It worked.

My parents experienced it as magic. Plug it in, radio plays. I experienced it as a well-designed system. Monitoring dashboards, remote SSH access, automated logging.

Two completely different experiences of the same product.

The CLI I'd carefully designed? The watchdog service? The backup documentation? None of that exists in my parents' mental model. For them, it's just a box that plays radio that they'll never think about. To them, "AUX" on the Denon Hi-Fi now means 'ad free radio'.

I did my job so well that they assumed someone else made it.

Designing my experience

I knew I was going to be administrating this and fixing anything that I couldn't account for; but how can I do that from 2500km away? And how can I make my experience less painful and maybe even enjoyable?

The UX of a command line utility

As I used the terminal more I realised that it, too, requires the same care and attention as any other interface. How can I make this intuitive, predictable, and usable. I found a great resource https://clig.dev/ which has a wealth of HCI guidance for terminal output.

Access — I can use Tailscale to ssh into the Pi as if it were at my desk.

Monitoring — I already use Uptime Kuma on my homelab so I can add a monitor for the Tailscale IP of the device and detect basic connectivity issues and when it's powered on for the first time.

Logging — I added detailed logging to track down issues and get a radio 'uptime' percentage. I want over 95% because this is a set and forget, always-on device.

Watchdog — I need something that actively monitors internet connectivity, audio output, memory usage etc. and can restart services or the whole device automatically if necessary.

Backup — I want to be able to back up all relevant files that I change. I also want to include included a restore document for file locations and commands to run after.

Readme — I don't know when the next time I will need to do any work on this machine. I will forget what I've done, why, and where. Keeping a README.md file on disk means I'll be able to get up to speed quickly. It should also be backed up.

In many early-stage startups, performance reviews can feel like box‑ticking exercises. The process is often high‑level, managed through generic Google forms, and leaves designers with vague comments or bland affirmations. Without actionable feedback or a clear path to promotion, both manager and direct report end up frustrated.

Over the last few years, I’ve been refining a system that brings clarity and continuity to designer performance reviews. The secret: take good notes and treat your feedback as a living document and tie everything back to real, specific work.

The Ratings System: More Than Just "Successful"

Most organisations use a simple status rubric. Ours includes five choices:

• Role Model
• Exceeds Expectations
• Successful
• Developing
• Not Delivering

"Successful" is the baseline. Nothing to complain about. You're rock solid.

For designers aiming to grow though, you need to be hitting Exceeds Expectations. It helps signals readiness for the next level. Promotions tend to reward work you're already doing.

For feedback we also write some bullets for what people should keep, start, and stop doing. This is useful but is often biased to the last few weeks.

How I Track Reviews: A Living Google Doc

Rather than juggling multiple forms, I keep one shared Google Doc per direct report. Each review date gets its own page, so past discussions never vanish into inboxes.

1. Status (pick one of the five above)
2. Keep Doing, Start Doing, Stop Doing
3. From Last Time
4. For Next Time

This setup means every conversation builds on the last. Copy, paste, and edit. There’s no reinventing the wheel for each review (though I am always open to feedback).

Every bullet needs to tie directly to real work, both successes and failures, and maps back to one of our feedback buckets.

Goal Tracking That Actually Works

Review time isn’t just a status update, it’s a checkpoint on past commitments and future direction; all in one place.

• Unchecked: We didn’t hit this goal. Let’s either re-commit or swap in a new, higher-priority objective.
• Intermediate: We made progress. Keep it rolling or pivot scope.
• Checked: Goal achieved! Time to celebrate and pick a fresh challenge.

Because goals live alongside feedback in the same document, revisiting them is as simple as ticking boxes and editing a line or two. The best thing is that you can scroll back through time and see your progress.

Anonymised Example:

AREAS OF OPPORTUNITY:
From last time:
[-] Embed user research findings directly into sprint planning
[ ] Adjust fidelity of prototypes based on project phase
[x] Lead design reviews for at least one major feature launch

Designing for Promotion

Promotion isn’t about higher fidelity mockups or pixel perfection; it’s about your problem solving, visibility, credibility, and—most importantly—your impact. That's how a business views your value.

Here’s how I map next-role behaviours onto today’s work:

Keep doing
Ensure you choose something that they're already doing that maps to behaviours needed for their next role; even if they're only doing them loosely or not deliberately. Call them out as positives to reinforce the behaviour.

Start doing
Pick one or two things that can easily augment their existing behaviour. Make sure they're not a huge leap from where they are now. Remember that they have to do their job as well as these new things aimed at promotion.

Stop doing
Identify behaviours that are having the opposite effect and highlight ways to channel this behaviour. This could be related to communication, professionalism, proactivity. If it's related to work quality (which is important to remember) then this person is probably not ready for promotion.

Areas of opportunity (aka goals)
Take the high level keep, start, and stop, and translate them into 3 specific, actionable, and achievable goal.

For next time:
- Mentor a junior designer through an entire feature cycle, from discovery to delivery
- Demonstrate a quantifiable uplift in user activation metrics (e.g., +10% sign-up completion rate)
- Initiate bi-weekly design critique sessions with product managers to foster continual learning

This clarity helps designers practice the behaviours that define a lead role, long before the promotion conversation.

Put it all together

15 June 2025

Rating: Exceeds Expectations

KEEP DOING:
- Conducting rapid user journey sketches before high-fidelity mocks
- Collaborating with the data team early to ground designs in real user insights
- Sharing clickable prototypes in #design-review to gather cross-functional feedback

START DOING:
- Incorporating accessibility checks into initial wireframes to catch issues sooner
- Running small-scale A/B tests on key interface changes before full release

STOP DOING:
- Keeping design rationale hidden in private notes; move context and decisions into our team wiki for transparency

AREAS OF OPPORTUNITY:
From last time:
[-] Embed user research findings directly into sprint planning
[x] Adjust fidelity of prototypes based on project phase
[x] Lead design reviews for at least one major feature launch

For next time:
- Mentor a junior designer through an entire feature cycle, from discovery to delivery
- Demonstrate a quantifiable uplift in user activation metrics (e.g., +10% sign-up completion rate)
- Initiate bi-weekly design critique sessions with product managers to foster continual learning

Notes > Memory

Relying on memory is a recipe for recency bias. Notes, captured in the moment, give you a reliable reference. I use Obsidian for a permanent, linked record:

1. People: One note per direct report in a folder.
2. Date-stamped one-on-ones: Quick bullet notes with links to project docs.
3. Graph links: Cross-reference mentions of people, projects, and feedback so nothing falls through the cracks.

When it’s review time, I have a searchable history of meetings, project outcomes, and side conversations.

Supercharging Reviews with AI

To speed up drafting, I leverage an Obsidian → MCP → Claude plugin that turns my notes into a knowledge-base. This only works if you take good notes of course. The benefit is surfacing my own thoughts and content without having to manually sift through hundreds of files.

Workflow:

1. Prompt Claude:

Based on my Obsidian notes for [Name], identify one behaviour Keep doing, one to Start doing, and one to Stop doing for a mid-level to Senior transition. 

Tie each to real examples from our past six months of projects.

Provide links to the source files for me to review and the reasoning behind your suggestions.

2. Claude returns draft bullets and sources for me to review
3. I review, reword, and add to my living document before sharing.

This hybrid approach saves hours and keeps feedback grounded in my own observations.

Preparation and Reflection

Great reviews take prep. I block:

• Weekly note sprint (30 min): Update one-on-one notes and link new projects. Reflect on team and individual progress. I find the Tuckman model a useful at the team level.
• Review prep (60 min): Skim your feedback doc, adjust bullets, and draft status updates.
• Review 1:1 (60 mins): Discuss with your direct report. Explain your rationale. Solicit feedback and their thoughts. Do they agree/disagree with your assessment? Do they agree with your goals? Work with them to set new ones and Note it.

A scheduled deep-dive trumps scrambling the day before. Your future self (and your team) will thank you.

Conclusion

When I first used this format not long after becoming a manager myself, my manager at the time said they almost screenshot it and posted it on LinkedIn as an example of how reviews should be done.

When reviews are authentic, designers grow. A living document, anchored in outcomes, plus a dash of AI, makes feedback fast, fair, and forward-looking.

Everyone screws up. Progress starts the moment you give voice to the problem and bring it into the light.

Why Giving Feedback Feels Hard

You are probably a new manager. You have never had to tell someone that something about their work is not meeting expectations. Worse, you still carry a few scars from badly delivered feedback in your own career, so you project that pain and pull your punches.

Ask yourself how you would want to hear it if these mistakes were yours. You would want to be told, and told straight; with clarity and a plan to fix it. Feedback feels hard for the giver, yet it is a gift for the receiver.

Why Direct Feedback Matters

Design work is subjective but business outcomes are not. When someone drifts from established patterns, processes, or quality bars; the product suffers, timelines slip, and engineering slows. What you tolerate becomes the culture.

Clear, directional, actionable feedback protects standards, accelerates iteration, and signals that you care about growth more than comfort.

Prime the Conversation

Open with a straight signal:

I need to give you some direct feedback.

One sentence sets expectations and switches the receiver into listening mode. No coffee-chat preamble. Capable people usually sense when they are missing the mark; you are just making the implicit explicit.

Feedback Is Meant to Help

Feedback that is specific, unemotional, and tied to impact is not a personal attack, (though it can still feel that way). Skip vague phrases like "people have noticed." State the impact and probe for the thinking that produced it. Never assume you know the reason. You can never truly improve without understanding the 'why'.

Impact → Behaviour → Curiosity

"Engineering are having to rework more designs recently because they stray from our patterns. Can you walk me through your choices on the latest release? I'd like to understand this from your perspective."

Tailor Feedback to the Behaviour

Pinpoint the category before you respond.

Attitude – how someone shows up in meetings
Effort – pace and volume of output
Quality – whether deliverables meet the bar
Process – alignment with systems and timelines

Whatever the category, run Observation → Impact → Action and finish with a concrete next step.

Make It Part of the Review Cycle

Capture each item and an agreed action in a shared doc. Revisit progress in every one-on-one. Quarterly or biannual reviews then become confirmation, not a surprise.

Focus each one-on-one on one theme until momentum is clear, then move on. You're not looking for perfection, just progress.

Turning Feedback Into Weekly Habits

Feedback sticks when it turns into routine.

Anchor the action step to your weekly one-on-one. "We'll check in next week so keep a note of ways you think you've addressed this and I will as well."

Define what better looks like: a behaviour you can see or a deliverable you can inspect. Remember to make it clear and definitive. "Post an in-progress design in Slack every day this week"

Add a small side quest that lets them practice the new behavior in a low-stakes context or lean in. This is normally something that might be difficult to observe directly.

Normalizing this cadence de-stigmatises feedback. It is just how we work.

Handling Pushback with Safety and Curiosity

Prepare for an emotional response. Reinforce that one-on-ones are a safe space.

Acknowledge – "It seems that this has caught you off guard."
Probe – "Why do you think people have raised this?"
Guide reflection – "How prepared did you feel for last week's meetings?"
Challenge your own assumptions – "Is there something happening that I should be aware of?"

If insight does not emerge, agree on a visible experiment: "We will debrief for five minutes after each meeting for two weeks." A persistent lack of self-awareness—unfortunately—should trigger a formal performance review path.

Translating Feedback From Others

If a stakeholder gives feedback in public, address it right after the meeting: "What do you think they meant by that?" If the feedback comes to you privately, translate it through Observation → Impact → Action before passing it on. Emphasise the business consequence, not the personal critique.

Measuring and Closing the Loop

Most signals are qualitative but you can rate them 1 to 5 to track trend. Check with the original observers: "Have you noticed a change?" Look for new blind spots that surface as the old one shrinks.

Direct feedback is not criticism; it is evidence that you believe improvement is possible and worth your time.

Mistakes are inevitable. Teams will make them, leaders will make them, and the work will move forward anyway. The question isn’t whether something will go wrong - it’s how you show up when it does.

Mistakes are part of the job

Worrying about making a mistake can be more paralyzing than the mistake itself. It’s better to assume that mistakes will happen and focus on how to respond when they do. The ability to recover is what builds resilience.

The principle

Here’s the guidance I often give:

• Take action rather than trying to avoid failure.
• You will make mistakes. And that’s okay.
• Never try and cover up your mistake. Instead, take accountability.
• Lead the effort to recover from it - even if you can’t fix it yourself.
• What people will remember is how you responded.

Mistakes should never be hidden, minimized, or redirected. The best course is to take ownership: “That was me. I got it wrong.” Then shift into action: gather the right people, ask the right questions, and help coordinate a path forward. You don’t need to know the fix yourself, but you do need to lead the effort to get it fixed.

In the long run, it won’t be the misstep that’s remembered. It’ll be the way it was handled - with honesty, ownership, and a willingness to learn.

Lessons from experience

When stepping into a more visible role, the pressure increases. There may be hesitation in making a call, or second-guessing after one is made. That tension is part of growth.

Mistakes aren’t always about the decision itself - sometimes it’s about how that decision is delivered. Acting with clarity and conviction is important, but so is leaving room for others to process.

The balance is difficult. That’s what makes it valuable.

In the world of RPGs, side quests are optional missions that challenge characters to develop new skills, strengthen relationships, and prepare for the main story arc. In the workplace, side quests can serve the same purpose—particularly when they focus on building soft skills like boundary setting, conflict resolution, and communication.

As a leader, you can use side quests to help team members grow beyond their core technical skills and learn how to manage themselves and others more effectively. These aren’t just helpful tasks—they’re transformational.

What Is a Side Quest?

A side quest is a deliberate developmental challenge. It’s something you assign instead of solving. When a team member brings you a tough interpersonal or emotional issue, instead of taking the lead, you hand them a side quest: a specific, stretch-level task that confronts the problem directly.

This doesn’t mean abandoning them. You guide, model, and support—but they own the action.

The Goal:

Not just resolution, but growth. Not just comfort, but capability.

Examples of Side Quests

Let’s break down some real side quests:

1. Conflict Resolution

Scenario: “Someone on the team said something that really upset me.”

Side Quest Breakdown:

• Ask: What specifically upset you? Help unpack meaning vs. intention.
• Reframe: Could there be another interpretation?
• Equip: Provide a conversation framework—like “When you said X, I felt Y.”
• Assign: Have them speak directly with the other person.

You’re not mediating. You’re mentoring.

2. Boundary Setting

Scenario: “I keep getting pulled into work late at night.”

Side Quest Breakdown:

• Clarify expectations and acceptable boundaries.
• Draft language together for a boundary-setting message.
• Have them send it—and reflect afterward.

The quest builds assertiveness, not just solves the time problem.

3. Feedback Loops

Scenario: “I feel like my ideas don’t get taken seriously.”

Side Quest Breakdown:

• Explore examples together.
• Identify whether it’s delivery, timing, or perception.
• Task them with trying a revised approach and reporting back.

They grow through pattern recognition and adaptation.

What Happens Over Time

When you consistently use side quests, something powerful emerges:

Predictive Self-Coaching

You’ll notice a shift in how team members talk to you:

• Before: “Here’s my issue. What should I do?”
• Later: “Here’s my issue. I think I know what you’re going to say…”
• Eventually: “Here’s what happened. Here’s how I handled it. What’s your take?”

They start anticipating growth-oriented action. They internalize your frameworks. They begin to think like a lead.

From Side Quests to Leadership

That’s your signal.

When someone:

• Recognizes tough interpersonal challenges,
• Applies structure to navigate them,
• Takes ownership of outcomes,
• Reflects and iterates—

They’ve moved from being senior to being a lead. Not because of title or tenure, but because they now elevate others.

Tracking the Journey

Side quests lose their power if they’re forgotten. Growth is incremental, and without a way to reflect, measure, and revisit progress, the opportunity to reinforce learning fades.

That’s why tracking matters—not in a bureaucratic, performance-review sense, but as an intentional act of leadership.

When you assign a side quest, treat it as a meaningful developmental step. Note it. Capture the context, the challenge, and the timeframe. Then, create a thread—something you can revisit in future one-on-ones.

It could be as simple as:

• “Gave feedback to teammate directly after coaching session.”
• “Set boundaries with client on after-hours availability.”
• “Initiated conversation to clarify team expectations.”

By linking conversations over time, patterns emerge: where someone avoids discomfort, where they grow more confident, where they still need nudges.

This doesn’t require a complex system—but it does require consistency. Whether you track in a graph-based tool, a shared doc, or a leadership journal, the key is to make development visible. Not just to you, but eventually to the team member as well.

And during your one-on-ones, revisit those threads. Ask:

• What happened after you took action?
• How did that feel?
• What would you do differently next time?

That’s how you turn moments into momentum. Side quests don’t end when the task is done—they end when the learning sticks.

The Conclusion: Leadership Is Earned in the Side Quests

Technical skill may earn someone seniority. But soft skill—the ability to handle hard conversations, set boundaries, and model emotional resilience—is what earns leadership.

Side quests are how you build that. Not by solving every problem for your team, but by challenging them to solve problems with your guidance.

When they start coming to you less for answers and more to share solutions, you’ll know: they leveled up.

AI tools like Roo Code and Cursor, combined with Figma’s new MCP server, are making that journey shorter and clearer. These integrations are small but meaningful steps toward tighter collaboration and higher fidelity execution.

Figma's MCP Server: A Quietly Powerful Feature

Figma’s Model Context Protocol (MCP) server exposes structured design data—like component trees, tokens, and properties—through a simple endpoint. This allows external tools to read what’s on the canvas in real time. More than that it allows conversations with the canvas and code generation based on its attributes.

Why More Products Should Offer an MCP

MCP servers represent a strategic opportunity for SaaS platforms to expose their internal state and data in a structured way. Rather than requiring users to engage through rigid UIs or product-specific chatbots, open protocols like MCP enable flexible, AI-native interactions.

Imagine asking a bank: "How could I have saved more money this month?" Or querying a project tool: "Which tasks blocked progress last quarter?". They take the common API and integration mechanic to a whole new level with the conversational and contextual abilities of LLMs.

They can also expose Tool calls so actions can be performed by the AI Agents so your AI of choice can make suggestions and implement changes as a result.

Products that offer an MCP interface make themselves not just tools, but intelligent platforms that adapt to user questions and workflows. 

Enabling Figma's MCP Server in Coding Tools

To connect this to Roo Code or Cursor, add the following configuration:

{
  "mcpServers": {
    "Figma": {
      "url": "http://127.0.0.1:3845/sse"
    }
  }
}

This snippet can be added to ~/.roo/mcp.json or ~/.cursor/config.json, depending on the tool in use. Once active, these environments can surface context-aware information pulled directly from the Figma file.

Why It Matters for Designers and Engineers

With conversational, agentic access to structured data from the MCP server, it becomes feasible to simply ask tools to implement components and know that they will match design specifications—including naming conventions, layout rules, and token usage. This kind of automation reduces manual review time improving both accuracy and speed in implementation.

Small Steps, Tangible Gains

Adopting tools like MCP, Roo Code, and Cursor isn’t about chasing trends. It’s about making good work easier to ship. As the boundary between design and development continues to shrink, lightweight integrations like this help ensure the integrity of both craft and execution.

Better outcomes start with better connections. And now, those connections are only a config file away.

If you’re searching for your next senior product design role, you already know the competition is steep. As someone who’s hired designers at fast-growing B2B startups, I want to share what I look for in candidates—not as universal truths, but as practical advice based on my experience.

Resume Tips

Be ATS-friendly, not buzzword-heavy. Use clear, scannable formatting, but skip the jargon. Focus on substance over fluff.

Highlight outcomes, not just outputs. Instead of saying “Designed a new onboarding flow,” try: “Redesigned onboarding to reduce drop-off, resulting in a 20% increase in conversion.”

Avoid progress bars. They don’t help. If you’re rating yourself 5/5 on ‘Figma’, what does that really mean?

Make it look good. Your resume is a design artefact. A well-structured, readable resume shows that you understand visual hierarchy and communication.

Portfolio Best Practices

Clarity > polish. I’m not looking for motion graphics. I’m looking for how you think and what you shipped.

Frame your work with a business lens. Start with the problem, not the UI. For example: “Users were abandoning the signup flow, costing the business potential revenue.”

Own your contribution. Specify your role. “I led user research and prototyped solutions” is more useful than “We designed…”

Context matters. What constraints were you under? What trade-offs did you make? Who did you work with?

Show impact. Use metrics if you can. If not, qualitative feedback or process wins still count.

Structure matters. A great format:

• Problem
• Role
• Process, constraints, and decisions
• Outcome/Impact
• Timeframe & collaborators

Interview Advice

Tie your answers to stories. Don’t just answer “Have you done X?” with a yes. Share a relevant example: what you did, why, what happened, and what you learned.

Tailor to their business. If you’re interviewing at a SaaS company, mention how you improved retention, trust, or onboarding.

Speak to your impact. Think of STAR format (Situation, Task, Action, Result) with a design twist.

Design Walkthroughs

It can be intimidating to present your work, especially if you're unsure whether it's visually impressive. But remember—what matters most is relevance. Focus on showing how your design choices solved similar problems to those the company is facing.

Bring real files. I’m not judging your presentation skills—I want to see your decision-making.

Talk through constraints. What made the problem hard? What trade-offs were required?

Reflect. What would you do differently now? This shows maturity and a growth mindset.

A scrappy solution that drives real business results is more compelling than a pixel-perfect interface that fails to deliver value.

For example, imagine showing a quick internal dashboard that reduced customer support tickets by simplifying a confusing process. It might not be visually impressive, but if you can walk through the problem, your rationale, and the result—that’s what stands out.

Take-Home Exercises

Know what they’re really testing. A good take-home should reflect how the company works and avoid feeling like free work. If it doesn’t seem fair, that’s worth considering.

Just do them—if you want the job. Completing the exercise is part of showing your interest. If you’re serious about the role, commit to it whether you agree with it or not.

Record a timelapse. Regardless of time limits, screen record your process. A timelapse demonstrates your workflow and thought process beyond the final deliverable.

Explain your thinking. Add a short video or written summary. Share your assumptions, highlight design decisions, and relate your work to business goals. If goals aren’t specified, create plausible ones.

Consider the broader system. Don’t design in a vacuum. Ensure your solution integrates well within the larger user journey or product ecosystem.

Tailor your focus. Align your solution with the role:

• UX-focused? Emphasize research, flow, and clarity.
• Visual-focused? Spend time on layout, interaction, and polish.
• Product-focused? Demonstrate end-to-end thinking, from problem framing to outcome.

Final Thoughts

Hiring isn’t just about talent; it’s about fit. Show how you think, how you work with others, and how you solve real problems. That goes further than a flashy mockup ever could.

Have questions or want help reviewing your portfolio or resume? Reach out!

Designing For The Empty States | Codrops

Empty states are places in apps that have no content or data. They are empty. A blank page. Traditionally empty states a

CodropsCraig Dennis

Traditionally empty states were overlooked as most designers focus on how best to display lots of content or data and not the lack of it.

It’s common for empty states to be dealt with by developers because the causes are often exceptions (such as no internet connection, no permissions for location, a failure to connect with a database). Developers often write the copy or it is provided by a backend service to help debug a problem. As a result it can be a little stiff and literal. While this is better than nothing (and functional), empty states should be deliberately considered.

There are three main empty state types:

First use (e.g. creating new data)
User cleared (e.g. deleted data)
Errors (e.g. unable to load data)

First use

From meeting new people, visiting a new place, or learning a new app, first impressions help us predict what will happen by comparing what we see now to something we have seen previously; an existing mental model.

Sometimes there is no basis for comparison (users are presented with a blank canvas). This can often lead to people believing the app is broken because nothing of meaning is loading. A bad first impression is very difficult to overcome.

When someone signs up for an app, the chances are high that they know what it does. It may not be clear to them how. When you sign up or log in for the first time, there is no data. It is the perfect opportunity to provide some careful hand holding to help users get the best possible experience. If the lack of data is out of their control then tell them; put them at ease and show that your app has some personality. Have a look at the way Buffer,  Timehop and Dropbox do this. Buffer uses the same technique on their desktop site showing that it doesn’t matter what platform or screen size you’re on.

User cleared

Consider the inbox. Love it or hate it, most of the time it’s full. Some people have hundreds of unread emails. Some people have only a handful. Either way everyone is on the quest for ‘Inbox Zero’ whether they know it or not. This can be a monumental task and as such should be rewarded with more than just relief.

Errors

Sometimes the people will experience an empty state as part of an error. Most commonly due to lack of an internet connection or declining permissions to location.

This is another opportunity to make people aware that you know this can happen by having something more than ugly error text. It puts people at ease knowing that it’s probably not something they’ve done because there is something designed something for that specific case.

Democratising Design

One way to ensure that empty states are always covered is by creating a design system with guidance, examples, and all states of a particular component.

A design system allows designers to create a set of templates and instructions for when, where, and how empty states should be included. This aids developers who then have a clearer idea of the purpose of an empty state and can use existing designs to implement a better experience.

Just knowing empty state guidance exists ensures that when something doesn't quite fit the use-case, it's called out and gets addressed.

What next?

Pay attention to when users will see nothing, and give them something. An explanation, context, and an action to perform. Create, retry, or wait.

The important thing to remember is to make sure you add a layer of delight to your apps. Even the boring ones.

1. Guide people on how to add data when there is none. A good idea is to break out of the conventional layout.
2. Think about the goals people have when using your app. Will they clear data a lot or will it be a rarity? Design a nice surprise accordingly. If the state will appear frequently, consider having a few designs and rotate through them randomly for an extra level of delight.
3. Provide context and actions along with errors. Do they make sense to someone who doesn’t know what they’re doing? Make them plain language with a clear action. Even if the action is to wait.

The details are what makes any app great. Delight your users and they will be much more forgiving if you make a mistake later on.

Contribute

If you have examples of well designed empty states, please submit them to http://emptystat.es including the app name and URL.

After previously writing a couple of basic Figma plugins, I wondered how much of a stretch it would be to build a Pexels one myself. Notice that I even added an empty state and skeleton states?

I chronicled my journey in a series of Tweets that, maybe unsurprisingly since I @ mentioned them, Pexels saw and subsequently reached out about.

Curious about my creative journey, Pexels interviewed me and published the story on their blog and Instagram. It is now recognised as an official Pexels branded plugin.

I also launched it on Product Hunt to try and gain some additional traction.

Recently I had a need to use random colors for a project in Figma. Yes, I could do it manually but instead I turned my hand to plugin development.

I found a plugin that appeared to do what I wanted and added random colours but it seemed to fail on Frames. It must have been written before Frames could have backgrounds.

At first I thought I could find its GitHub repo and clone it, poke around in the code, and hopefully understand enough of it to make it do what I wanted.

There was no repo.

I decided to make my own

I downloaded Figma’s plugin starter then search for and found a library that would create a random color.

There were a few concepts that were foreign to me (from my jQuery days). Certain properties on Nodes in Figma are read only. This means you need to clone them, modify the details, and apply them back.

After initially struggling with Webpack (and Typescript) for a while, I finally created what I needed. A plugin that changed the fill of all selected elements to a random color. No UI needed. It does one thing and it does it well.

After creating the collateral to use for publishing the plugin to Figma, I hit ‘publish’ and sat back; happy with what I had created.

It was published a few days later with only minor changes: I needed to notify users when nothing was selected.

And so, my first Figma plugin was published. I had made a thing. It’s during the 2020 Coronavirus pandemic quarantine in the UK so I had some fun with my demo.

A plugin for one person

Soon after the plugin went live I received a notification from GitHub when someone submitted a feature request.

Already!? Great! I consider ‘yeah but it would be great if it also did this…’ as one metric for success. It means that what you delivered was needed, obvious, and useful to the point that they want something more on top.

After some clarification of this issue I resigned myself to not delivering on the idea becuase it was out of scope for that plugin and would result in a breaking change (from a single step to one with a UI and options).

My mind was already thinking how to create the feature

The idea was to take a pre-existing set of colors and randomly fill a selection with only those colors.

I decided to start a new plugin to try a proof-of-concept and quickly had something running using a chunk of the work from the previous plugin.

This, it turns out, was actually the easiest/quickest part.

Swatches on swatches on swatches

It’s no good having a fixed number of swatches. Everyone has different use cases and being able to add an arbitrary amount seems like a good idea. But it was hard to execute for someone who has only been writing Typescript for ~6 hours total at this point.

I opted to use Figma’s default #C4C4C4 for the swatches and it worked well but it didn’t really feel that good to use (or look that good) and relied solely on the OS-based color picker. It turns out Figma doesn’t give you access to their color picker.

It did fulfil the brief though; to use an existing selection to create the swatches.

There is a lot of complexity in this:

• it reads the fills from the current selection if there is one
• if there isn’t it generates two swatches
• it allows people to add an arbitrary number of swatches
• people can change the

Using random colors when adding manually

I decided that, actually, when adding a new swatch it makes sense for it to be a random color rather than always the same. A nice touch that actually brings us full circle.

In the end, I demoed the plugin to the requester (who seemed happy enough), created some more collateral—following the previous style—and submitted it to Figma.

At the time of writing it is still in review but you can view it if it’s been published.

And I found a piece of UI that perfectly encapsulates the use case for the plugin. The GitHub contribution heatmap.

Now what?

This plugin was made for one person, and I hope it helps them. I hope other people find use in it. I’ve learned a lot and now I know (roughly) how to put together a plugin.

So the next time I need to automate a repetative task, I might end up making another plugin.

References:

• Chroma JS
• Figma Plugin Docs
• Random Color Generator (Github)
• Apply Colors to Selection (Github)

Sketch 45 has just launched and some great new features for plugins as well as fixed a bunch of frustrating vector editing bugs. One thing that didn’t get any improvements were symbol overrides.

It was important to identify what was causing friction, and explore how it might be improved. There were a few things that this concept set out to achieve:

1. Better visual identification of overrides and their relationship
2. The ability to override the border-radius and colour of shapes
3. The ability to override the alignment, colour, and underlines of text

Before

The current symbol override panel flattens the hierarchy so that all symbols exist on the same level and look identical.

This leads to confusion and a non-intuitive search through the labels (which can be truncated) to find the correct ‘top level’ symbol. And then search the symbols that follow those, to identify which nested symbol is needed, and override it.

After

Comparing the concept, in its collapsed state, with the existing symbol overrides panel shows that it still uses a similar amount of space.

Using a button with nested symbols as an example, the proposed solution uses an accordion mechanism to re-introduce levels of hierarchy back to the symbols.

• Easier to see the type of override, by using icons to represent them.
• Text is kept editable instead of using a placeholder (easier to identify).
• Direct access to colour overrides without having to create more symbols.
• Clear separation of top-level symbols.

Alignment

The whole design conforms to an 8px grid.

The grid makes alignment easy and the overall look more consistent than the current override panel.

Caveats

This design does not account for deeply nested symbols. The pattern could work with a little modification, so that would be an interesting avenue to explore further.

It could be problematic to show every shape or text layer within a symbol. One idea is to have a checkbox that designates whether a layer can be overridden; potentially extending to allow only specific properties. It’s likely the override will need to be checked by default, so as not to break existing files.

The proposed design is slightly wider than the current sidebar. It can be made narrower to fit but the sub-controls (text alignment for example) would need to be adjusted to survive in the smaller space.

Next Steps

The next thing to try and improve would be the way in which overrides are selected. They’re currently in a simple dropdown, with poor visibility of the content; relying mostly on the name of the layer.

Aside

The project was designed using the Abstract alpha which offers a way to track file changes in a similar way to GIT. The ability to visualise the history of an artboard or symbol is incredibly useful and allows an easy timeline of progress.

You can download the Sketch file and play around yourself. It’s an export from Abstract so should contain all commits if you use the app.

Great interface design is making sure your users complete tasks easily and efficiently. ‘Distraction free’ modes remove the UI but what if that’s the default?

Users should never be thinking about an interface while they’re using it; instead the interface should be unobtrusive and functional. There shouldn’t be any decoration when efficiency is the focus.

“Good design is invisible. Minimum input, maximum output, with minimal conscious thought.” — Oliver Reichenstein

Forms

Everyone is familiar with a web form. Login, register, update status, comment — all of them follow a similar pattern which is usually a label, an input, a placeholder and a button.

There has been a shift away from labels in favour of using placeholders for the same purpose, but this can lead to some usability issues because the placeholder disappears when you start typing. It may also affect accessibility if the label isn’t even in the markup.

There are some clever ideas to get around the issue.

In The Wild

The ‘new email’ form for Inbox by Google shows how typography, visual hierarchy and colour can combine to create a fantastic interface design pattern without an explicit UI for content. It plays on our innate sense of writing; start with a title and then add some copy.

It is clear from the size, weight and position of the text at the top that it is the title (Subject in the case of email). It’s also clear that the subsequent text is secondary and relates directly to the title; even when the placeholders are removed when typing. The placeholders serve to reinforce what content is expected.

The main difference is that there are no separate fields for title and content. It doesn’t care as notes are — by their very nature — freeform.

There is an easy way to tell if you’ve been successful in removing a form field interface: Can you still understand the field’s purpose when it’s populated by user content. Without a persistent label, content is all anyone has to go on.

It’s a little like skeuomorphism in that design elements are used to reinforce the real-world instances of their digital counterparts, allowing them to be easily understood.

Visual grouping plays a very important part in forming relationships between content, thereby giving it added context.

More examples

In Practice

I’ve applied these design principles to a ‘new event’ in a fake calendar app.

The placeholders serve to initially explain what content is required in each field. The visual hierarchy helps explain the context of each item when the fields have been filled.

• Untitled Event shows that the event needs a name. It’s at the very top and is the largest element indicating that it’s the most important.
• Location auto expands to take a full / partial address or just a meeting room. Easily recognisable content once filled.
• Date and time would prompt a picker of some description or take any form of date / time combo written
• Description is bold to indicate it too is a title of sorts. This could be used for an agenda or general overview of the event. More detail would go in the ‘notes’ section.
• Guest would trigger an autocomplete dropdown to select contacts (with avatars if present) but will also just accept a comma separated list of email addresses.
• Attachments would show a list of files once attached but having a drop-zone and a browse link easily indicate the purpose.
• Notifications might be better called ‘reminders’ as date and time by itself has no discernible meaning in this context. ’Remind me X hours/days/weeks before’ would be a good option.
• Notes is a dumping ground for any freeform content. It could be the entire agenda, cliff notes or anything not included in an attached document.

The important thing to note is that most of the inputs can be easily understood once they are filled because their content types are different.

Where the content types are the same (as with the title, description and notes) visual hierarchy, layout, typography, and user content, all go towards showing the context.

How far can this go?

This isn’t something that should be applied in a blanket fashion to all forms. For example: a long, detailed car insurance quote form wouldn’t work because the content can’t be understood without a label; it’s too detailed.

However the registration plate, make, model, and colour could be addressed with invisible UI if designed correctly.

Another approach is Progressive Reduction which starts with a full interface (including more verbose wording and help) but gradually reduces the amount of interface the more you complete specific tasks.

TL;DR

An interface typically includes icons, buttons, toolbars etc. but not all of those elements may be needed.

We’re good at reducing unnecessary tasks by asking:

“What is the minimum information we need from a user?”

Now we should be asking:

“What is the minimum interface the user needs?”

How many times have you tried to access a menu or some form of navigation on a touch enabled device, only to find that the it's based on :hover events and doesn't behave quite as you'd expect.

When designing interactions for menus and other complex flyouts such as help tips, how they will respond on touch devices needs to be considered. The simplest option is to convert hover to click (or tap in the case of touch devices) and be done with it. For the most part this is an acceptable solution which covers the aforementioned most scenarios. This will also benefit non-touch enabled users at the same time by preventing accidentally triggering the menus.

This presents new challenges though; how do you close the flyout? It depends on the context in question and what feels right. For example with a main navigation you could close the menu when the mouse leaves it or (the preferred method) when the mouse clicks somewhere else in the document. Sometimes a close button may be appropriate for help text.

If hover is a key interaction, another approach is to degrade to a more basic interaction.

This is where questions need to be asked of the user; ‘what are the most important tasks?’. If a key task can’t be completed on a touch device because it user a hover event and the predicted traffic from touch devices is high enough, then either change the interaction globally or target touch devices specifically.

Modernizr provides feature detection for many things including the presence of touch events. Use this to target touch enabled devices and tailor an experience for them. Swipe gestures could be a suitable replacement.

More complex apps are more complex

Think of Google Docs using right click events, something traditionally only seen on desktop applications. This adds another layer of complexity to the design process when thinking about how people will interact with those features on touch devices. The interactions for a document are ok but trying to edit a spreadsheet on a touch device is just about impossible.

Enhance progressively, don’t degrade gracefully

The best advice is to make sure that hover and right click events are enhancements. Ensure that the tasks that enabled by those interactions can still be completed through other (probably longer) means. While not ideal, nothing breaks. This allows you to only enable those events when the device detects no touch events.

With so many touch enabled devices connected to the web these days, you just can’t ignore them when considering interactions for your design.