Rosenqvist Design

Building a Color Contrast Design Jig

Simon Rosenqvist — Mon, 23 Jun 2025 07:00:00 GMT

When a driver glances at their dashboard at 70mph, every millisecond of recognition matters—and that's where color contrast becomes critical.

Today I will talk about another jig I've created to help me in my daily design work. You can read more about jigs in my recent post here.

The Problem with Traditional Contrast Checkers

When creating interfaces it is good practice to check that your background and foreground colors pass a contrast check. How to measure contrast is defined in WCAG and there are several color contrast checkers out there for both WCAG and APCA which is another algorithm that is meant to be more perceptually accurate. APCA is also better if you are designing dark mode interfaces, as the algorithm will give you a more accurate result for what is readable and what is not.

But all tools I've found take an exact color (as a hex value or something) and compare it to another exact color. This is great if you want to validate two colors but if you are exploring and trying to find a palette that will work you might need to adjust all colors again if some of them don't have sufficient contrast. This creates a time-consuming iterative process.

I needed a way to get an overview of how the colors relate to each other. More like a map than turn-by-turn directions, so I could see the general direction I should be heading.

The contrast toy is my attempt at doing that

It works by comparing a background color to all the hues. Since you see all the hues you only need to adjust lightness and saturation to try to find a color that could work.

Real-World Application: The Tesla Light Theme Challenge

Back in 20... Tesla released a car with light theme UI. This was something that had never been seen in automotive interfaces before and since then it has been something that has been asked for in all car UIs.

When you are designing for automotive interfaces you need to follow a whole bunch of regulations on top of just creating a good UX. One of those regulations is about the color of telltales (the little icons that show the state of the car). Some telltales are required to have a certain color. Red and green is usually no problem but yellow is not a great color on light backgrounds.

The Natural Lightness Problem

All hues, or more accurately all colors, have a natural lightness range. Some colors like yellow or turquoise only look yellow and turquoise when they are very bright. If you take a nice yellow and reduce the lightness it will turn into a muddy brown (same hue, different color).

You can't get a light color like yellow to have sufficient contrast against a light background.

Fortunately there are some ways around this. The regulation actually says that the telltales need to be yellow OR AMBER. None of these colors are defined but amber can be described as more towards the orange range of hues and this lets you inch your way over the contrast requirements. The other way, that is described in the regulations, is that you can add a border to the telltale and then you are allowed to measure the border value vs the background.

We ended up using a combination of both methods to ensure good contrast as well as darkening the "light theme" background which helped with the contrast as well. By the way, if you have a background that sits somewhere in the middle of lightness values then you will have problems getting contrast both to dark colors and to light colors. Not recommended.

The jig allowed me to see the whole picture

This jig helped me explore color relationships much faster than checking individual colors against each other so I could sketch things out with this and then validate them with other contrast tools. The visual overview allowed me to quickly identify which hue ranges would work for different contrast requirements, saving hours of trial-and-error testing.

If you have a problem that you think you will run into again, create your personal jig and add it to your personal toolbox. The time invested in building specialized tools pays dividends when you encounter similar challenges in future projects.

The automotive industry's strict regulatory requirements combined with evolving design trends like light themes create unique constraints that standard tools don't always address effectively. Sometimes the solution is building exactly what you need rather than adapting existing tools to fit your workflow.

Jigs, Not Tools

Simon Rosenqvist — Mon, 16 Jun 2025 07:00:00 GMT

A while ago, I came across a blog post by PJ Oneri about the difference between jigs and tools. It struck a chord with me.

In other craft disciplines—woodworking, machining, even ceramics—it's common to make jigs. A jig is something that a craftsman makes for themselves to solve a particular problem. It's something a maker builds for themselves to solve a specific problem, often a one-off or repetitive task. A jig is personal and quickly made.

Jigs are the custom tools that craftspeople create to enable them to do great work. In woodworking it’s often used to help make cuts with optimal precision. But, really, it can be used for anything. Jigs are what allow craftspeople to deliver quality predictably and faster.

Jigs are “fine, I’ll make it myself” made manifest. The tool they need doesn’t exist or is too expensive or is too much of a pain in the ass. So a jig is born. The craftsperson has a job to do and they’re not going to let a tool not existing stop them.
- PJ Oneri, Crafts and Tools and Jigs

Reading PJ's post made me realize: I've started building a lot of jigs too. Little scripts, templates, checklists—small things that help me solve my own problems, not meant to scale or be shipped but just meant to solve repetitive tasks.

I'm thinking that I will start sharing them as examples of what you can create to help you in your day-to-day job as a designer.

The Measurement Converter

Over the past few years, I've spent a lot of time working in the automotive industry. One thing that comes up again and again in that context is: how big does this icon or text need to be?

Screen Measurement converter

In automotive, you're almost always designing for multiple displays at once, and it's a heavily regulated environment. Certain visual elements, especially safety-critical ones, must meet strict size requirements in order for a vehicle to be legally sold in various markets.

There are two key ISO standards that typically guide this:

ISO 15008 – This one provides recommended minimum sizes for text and graphical elements. It expresses these sizes in arc minutes, which depend on viewing distance. It's technically a recommendation, but most OEMs follow it closely to avoid legal risk and ensure good usability.
ISO 2575 – This one defines concrete physical size requirements for telltales. These are the small warning symbols on the dashboard, and their size is supposed to be 75mm² measured in millimeters, not pixels.

As a digital designer, my Figma designs are measured in px. But compliance standards are written in arc minutes and millimeters. To bridge that gap, I needed an easy way to calculate:

• How many millimeters an element will be, based on pixel size and screen DPI

• How many arc minutes it subtends, based on viewing distance

And vice versa

During the design phase of a car project, the specs of screens and their positions change often. Many teams are working in parallel to get things to align, so you need to be able to give ballpark figures quickly. You also need to set hard limits for what is feasible from both a design side and regulation side.

In the past, I've built solutions for this using Python scripts and Excel sheets. Both work—but recently, I've found that building a small HTML page is often the fastest and most flexible way to share these kinds of utilities.

I think i was also a little inspired by Jim Nielsen and his small HTML pages approach.

This little jig is vibe-coded as an artifact in claude and the only thing I've fixed is to adjust the colors a bit and make sure it works for mobile sizes. Since it's all in one HTML file, I can email it, drop it in a Slack chat, or embed it in Confluence. People don't need to install anything, and it's more visual and self-explanatory than a spreadsheet.

Since it's a webpage created on my own computer in my own time, I can also take it with me. I can hang it on the wall of any workshop I join in the future, and it can help me improve the craft wherever I go.

More jigs and tools to come

I will share some more jigs in the future once I do some minimal cleanup on them. Whether or not this particular jig is useful to you, I hope you take away this: it's worth building jigs. Little tools for your own workflow. Not to scale, not to sell, not to impress anyone—just to help you work smarter.

My advice is to make them portable and standalone so you can take them with you in your toolbox. Make them with what you have at hand.

Also, if you make a jig, please share it as an example. The odds are that people don't have your exact problem (you would build tools for that), but they might have similar problems. Showing them some examples can make them go home and weld together something that suits them personally.

Please check out my jig and PJ's blog post, and if you have your own jigs, I would love to hear about them.

Screen Measurement converter

11ty RSS Feed Setup: Three Plugin Problems and How I Fixed Them

Simon Rosenqvist — Sun, 01 Jun 2025 07:00:00 GMT

I've been following RSS feeds since probably the late oughts so when I moved this site into 11ty I of course wanted to have my own feed. What started as a simple plugin install turned into a debugging process involving dependency management, configuration conflicts, and deprecated APIs.

I had planned to create my own feed and really dig into how the format works and how to put it together but after a quick look and thinking about how i wanted to spend my evenings i decided to just search for a ready made solution. Just searching "11ty rss" led me to this page https://www.11ty.dev/docs/plugins/rss/ and it seemed easy enough.

Setting Up the 11ty RSS Plugin: Two Installation Methods

I'll be honest - these issues were probably caused by using AI to install the plugin. I fed Claude the readme file and the docs and asked it to help me set it up. It gave me some straightforward steps: install the plugin with npm install @11ty/eleventy-plugin-rss, then I got a choice between an easy way and a harder way. Option 1 was using a virtual template where you just add configuration to your Eleventy config file. Option 2 was the manual template method with more control where you add the plugin in your config file and create feed template files in your project directory.

I went with the "easy" option first, and that's where I ran into problems.

Issue #1: "Trying to convert to absolute url with base undefined" Error

The first problem showed up as these debug messages: "Trying to convert '/blog/' to be an absolute url with base undefined and failed." Despite having properly configured metadata.url in the site's metadata file, the RSS plugin just refused to generate the feed.xml file. I tried everything - setting the base URL directly in plugin options, wrapping it in a nested metadata object, double-checking the metadata.json configuration. Nothing worked.

Eventually I had Claude dig into the plugin's source code and found this comment in absoluteUrl.js: "This is deprecated! Use the Eleventy HTML <base> plugin instead (2.0+)". Turns out the plugin had evolved way beyond the configuration approaches I were trying, creating this mismatch between what I expected and what actually worked.

Issue #2: Duplicate Plugin Configuration in .eleventy.js

When I looked at the .eleventy.js file, there were several issues. There was a proper import statement at the top: import eleventyRssPlugin from "@11ty/eleventy-plugin-rss"; but then later in the file there was an unexpected duplication with another copy of the same import statement and a competing plugin configuration block with different settings. Two plugin registrations fighting each other, each with conflicting configurations. The file structure was so mangled that every time I tried to edit it, it just failed.

At this point I switched to option 2 - the manual template method. Instead of wrestling with all these interconnected problems, I created a feed.njk template with direct control over feed generation. Set the proper permalink to /feed/feed.xml, used metadata.url directly to construct absolute URLs, applied the htmlToAbsoluteUrls filter for content processing, and excluded the template from collections to avoid circularity.

Issue #3: RSS Plugin Installed in devDependencies Instead of dependencies

And even when I thought I had the configuration issues sorted out, this recurring problem kept happening every few days where the RSS plugin would mysteriously stop working. I'd clear the npm cache and it would work again temporarily, but then break again a few days later. Turns out the plugin had been installed in devDependencies instead of dependencies. Node.js prioritizes dependencies over devDependencies during module resolution, and npm kept getting confused about where to find the package. So while clearing the cache would fix it temporarily, the fundamental problem was that the package wasn't where the system expected it to be.

Additional Fix: Changing feed.xml Output Path Configuration

There was one more gotcha though. The /feed/feed.xml path was something that just happened when using the LLM to help install it, and at first it seemed like that was the only way it could work. Whenever I tried to change it I just got an error. Turns out the fix was to change both the outputPath in the config (which I had tried) AND also change it in the feed.njk template itself (which I hadn't tried).

Lessons Learned: 11ty RSS Plugin Best Practices

Looking back, this whole saga taught me a few things. First, Eleventy plugin APIs evolve, and older configuration patterns can become deprecated without much fanfare. Second, build tools are really sensitive to duplication and conflicting settings. And finally, sometimes when plugin complexity exceeds the benefit, just rolling your own template gives you way more control.

The combination of issues was particularly frustrating - the plugin had evolved its URL handling approach making older configuration methods ineffective, the dependency classification issue wasn't obvious, and the configuration conflicts made everything worse. The recurring nature of that dependency issue was particularly annoying because clearing the cache would fix it temporarily, so I kept thinking I'd solved it when I really hadn't.

So I got it working and this post is mostly just a way for me to get rid of the frustration by writing it down. I will say that although the whole issue was probably caused by getting help from an LLM, it was also how it got solved. I would never have gone into the source code to find the deprecated comment, but I could just tell Claude to dig into it and it found the issue pretty quickly.

If you want to see the feed for yourself you can find it here: rosenqvist.design/feed.xml

PS: As I'm writing this, the plugin issue still occasionally resurfaces - the @11ty/eleventy-plugin-rss import sometimes fails and requires reinstalling the plugin and clearing npm cache. It seems to be related to some dependency resolution quirks, but the workaround is now familiar: npm uninstall @11ty/eleventy-plugin-rss, npm install @11ty/eleventy-plugin-rss, npm cache clean --force. The RSS feed itself seems to work once the plugin is properly installed, but I cant figure out why it needs constant reinstall...

UX Design's Role in the Automotive Sales Lifecycle

Simon Rosenqvist — Sun, 25 May 2025 07:00:00 GMT

UX Design's Role in the Automotive Sales Lifecycle

It is quite common that design leaders have trouble justifying the expense of a UX department and the work they do. A lot of of UX work is, in a way, supportive. Since it contributes to outcomes but is (often) dependant on other professions it is important that you are strategic about what value the UX team brings and what their role is.

These are my half-baked ideas around how the UX team can contribute to the business here. and yes, the focus is on the business side. I've never met anyone who don't think UX designers make a product better for the customer but i've seen people question what effect it has on the bottom line.

Lots of this comes from an article i read a long time ago that were talking about a mobile games company and their business strategy. It was a simple strategy with very clear roles where the marketing department were responsible for acquisition and the engineering (along with game designers) where responsible for retention.

They built their products as a feedback loop where essentially more people buying their game meant more money meant more marketing which meant more people buying their games. The role of engineering, product, ux was essentially to get them to pay for another month of the game and thereby lower the cost of acquisition.

The article contained more details than that but this idea was so straight forward and we had a discussion about UX research and UX design earlier this week, and I wanted to write down my perspective on how UX design and research can contribute to a product. This is written with the background of automotive HMI design but can be applied to any industry.

The Customer Lifecycle Model and Product Strategy

You've probably heard of the sales funnel before (the blue part in most lifecycle diagrams). After a customer makes a purchase, we enter what's called the "post-purchase funnel" or customer journey.

The sales funnel is typically managed by marketing and sales departments, but it's in the post-purchase phase where UX design can have the most significant impact. The ultimate goal is to sell more cars, and UX can contribute by creating advocates and enabling reactivation. To achieve this, customers need to feel they're receiving the value they expected from their purchase—or even more value than they anticipated.

Optimizing the Post-Purchase Customer Journey

Onboarding: The Foundation of Value

The post-purchase funnel begins with onboarding, which enables all the value in subsequent phases. In automotive, this means ensuring users understand everything they need to operate their car effectively—how to charge it, how to set up their music and navigation systems, and so on. UX can make a substantial impact by making these processes intuitive for first-time users.

Engagement: Measuring Active Usage

Engagement is crucial if you're building an app, typically measured through Daily Active Users (DAU) or Monthly Active Users (MAU). You can also measure engagement on a per-feature basis, such as "how many people are using our search feature." UX contributes here by making features easy to use, which is often what usability testing aims to address.

Retention: Keeping Users Coming Back

Retention occurs when people continue using the product over time. It's often seen as a result of good onboarding and effective value delivery, among other factors. For subscription products, retention literally pays the bills. With cars, which are typically one-time purchases, retention helps with advocacy and maintains high resale values in secondhand markets, making the car a better investment. UX has a significant impact on retention—if users are constantly frustrated by something in the car, they'll start looking for alternatives.

Advocacy: Turning Users into Promoters

Advocacy happens when people speak positively about the brand. Bugs and difficult-to-use features prevent people from becoming advocates or can even turn them against the brand. Advocacy is directly tied to the quality of the user experience.

Reactivation: Building Brand Loyalty

Reactivation occurs when someone makes repeat purchases from your brand. This is especially important in the automotive industry, where customers tend to stick with the same brand rather than switching. Once you get someone to buy a car, they'll likely purchase their next car from you as well. Customer loyalty to brands is more common in automotive compared to other industries.

UX's Role in the Sales Funnel

UX is also crucial during the sales funnel, particularly in the phases where customers are comparing options and showing interest. This is typically when they take test drives and evaluate common use cases. They also research cars online, making advocacy particularly important during this stage.

From a design perspective, the most critical aspect of the sales funnel is avoiding unusable interfaces while creating something beautiful. Test drives don't last long, and customers are more likely to purchase if they find the car visually appealing.

The Aesthetic-Usability Effect

Products that look good are also perceived as easier to use—this is a well-documented phenomenon known as the Aesthetic-Usability Effect.

The aesthetic-usability effect refers to users' tendency to perceive attractive products as more usable. People tend to believe that things that look better will work better — even if they aren't actually more effective or efficient. - NN group.

I've noticed in automotive that some people look down on designers who prioritize visual design. There's a perception that this approach prioritizes aesthetics over functionality. I think we need to let go of that false dichotomy. It prevents us from building better products and, honestly, during a test drive the visual design is what helps sell the car. Well-thought-through interactions help retain the customer, but the visual design sells it in the first place.

UX Design as Product Strategy Unifier: Creating Coherent Experiences Across Teams

One final thing that UX design really helps with, but is the hardest to measure, is the holistic impression of the product. When large organizations work on complicated products, they tend to get siloed. Often the UX team is the first team to notice that things will not fit together in the right way. Different teams have been working on different mental models and interaction patterns. One team might have taken it as an assumption that you should hide as much complexity as possible, while another believes it's better to be transparent about the complexity.

When you suddenly need to create a front-end for these systems, you see how the systems don't match. What the UX team can help with, if they are included early enough, is to catch the most severe cases before they become costly problems. Another thing is to lay out the design strategy and formulate some basic guidelines and principles that help the organization build something coherent.

This isn't directly connected to the customer lifecycle, but instead supports it and can help build a good product with a compelling story throughout the entire sales funnel and customer journey.

Building a Strategic UX Framework for Business Success

When we create product designs, they need to serve multiple strategic purposes: they must be usable for sustained user engagement, fit appropriately into the customer journey for retention optimization, and feature excellent UI design to encourage purchases in the first place. Understanding this balance is crucial for creating successful automotive user experiences that support the entire customer lifecycle and drive measurable business outcomes. By connecting UX strategy to each phase of the customer journey—from initial attraction through onboarding, engagement, retention, advocacy, and reactivation—design teams can demonstrate clear business value and justify their strategic role in product development. This framework helps organizations build not just better products, but more profitable and sustainable customer relationships.

Moving the Blog to 11ty

Simon Rosenqvist — Sun, 11 May 2025 07:00:00 GMT

Moving My Site to Eleventy: Streamlining for Writing and Future Projects

When I first started building my personal site, I made a deliberate choice to go with pure HTML and CSS. My goal to understand how everything fits together without any abstractions. I also saw myself making a lot of cool and unique layouts for each post. It started well, and I put together some posts (although without any amazing layouts). The experience was incredibly rewarding, and I learned a lot about layout, design principles, and the structure of web pages.

But after the first couple of posts, it started to feel like a ton of work every time I wanted to put a blog together. It drained my motivation, and even though I learned a lot, I feel like what is holding me back right now is the ability to put pen to paper and actually write things down.

Why 11ty?

The goal was to make the writing process easier, and after looking around a bit, I decided to switch to 11ty. 11ty (or Eleventy) is a static site generator that still lets me keep things simple but with much more efficiency. It handles templating, reusable components, and layout management. That means I can focus more on the actual writing and less on redoing basic page structures every time. Hopefully, it will allow me to focus more on the writing and remove some of the friction of creating posts.

The transition wasn't too difficult. I asked Claude to help with the migration, and using Cursor, it didn't take too long to convert the blog posts into Markdown documents and create page templates, etc. I decided to remove some of the gradients I had added when I first made the site since they didn't feel as fresh now as they did back then. I also made it light-themed by default to improve readability. I want to shift the focus away from the portfolio towards the blog, so I wanted it to be nicer to read.

I did run into some issues that are not quite resolved yet. Some of them had to do with the CSS: getting things to line up when using reusable components is a bit tricky. I might just remove the whole LLM-written responsive layout part and rewrite it myself.

The biggest issue was getting things to work together with the server. Git is not my strong suit, and making sure the page is deployed from the right branch has been a pain. If you are reading this, it means I'm on the right path to fixing it.

Next Steps: Posting more, RSS Feed, and Portfolio updates

Now that the site structure is more manageable, the next step is to write more consistently and set up an RSS feed. I want to build the RSS feed from scratch, similar to how I initially built my site. I know I could just use a plugin or a pre-built solution, but I think there's value in understanding the mechanics behind it. Building things from the ground up gives me deeper insight into how they work. I've done this before with my original site build, and it really helped my understanding.

I'm also planning to update the portfolio. This is always a challenge, given the nature of the automotive industry. Long lead times and the breadth of responsibilities make it tricky to create the clean, singular case studies that typically look good in a portfolio. It's something I need to work through and find a way to present that feels both authentic and engaging.

Moving Forward

So that's where I'm at right now. The focus is on building momentum with writing, updating my portfolio, and setting up an RSS feed. I also have a ton of side-projects running in parallel that I really should start posting about. I'm excited to see where this next phase takes me and if I can keep the motivation alive.

AI hardware products

Simon Rosenqvist — Sat, 30 Mar 2024 07:00:00 GMT

I've been confused about why we have seen hardware AI products pop up. Earlier this year there was quite a lot of buzz around the Rabbit r1. The fun design from teenage engineering together with hitting the peak of the AI hype made me interested. Even though I wasn't super excited about buying it or really understood what it was for I wanted to know more.

The AI pin was another product that was insanely hyped at the beginning of the year. It's a small device that you can attach to your shirt. It functions as an assistant who can help you remember things, put things in the calendar, buy things.

The AI pin blew up in a spectacular way with a review from Markus. It even started a discourse about if the reviewers have a responsibility to not make to harsh a review since it can kill a company before they even get started. (My worry is that reviewers get even more gagged than they already are. They should be critical and guide consumers to good purchases. The critique came mostly from, by what I saw, the type of tech optimist that I mostly see on twitter. If a company don't think the product is ready then they should hold the release until it is. And trust me I know that is a hard decision to make but I they don't they shouldn't be surprised when their stock tanks.). The Rabbit was less dramatic but it didn't escape harsh reviews and also got a lot of flack when it came to light that the people behind it were NFT and crypto grifters that had pivoted to AI last year.

Both these events left me thinking "Why?". And there were so many why's: Why did they decide to build a Hardware product in the first place? Why did they decide to release them when they were so underperforming? Why did so many people think it was such a good idea? Why are we so excited for "assistants"?

Why hardware?

There is a really funny clip from one reviewer of the rabbit where they talk about how they would redesign it. First they would remove the jockey wheel, then they would make it smaller with the edge all he way to the screen… by the end they have a smartphone with a rabbit logo. I was thinking the same thing. I wondered: If the selling point is the "assistant" functionality, which is all software, why go through the effort of making a hardware thing? Why not spend the time and money on building up the assistant capability which is not an easy thing to do and something they didn't manage to take care of?

My half baked ideas for why:

Maybe they were hoping to make back some investment by the selling the hardware. They would sell the hardware with enough margin to give them cashflow while they continued building the software. The AI pin needs a subscription to work but the rabbit was sold as is with no mention of a subscription. I don't know what their plan was since it seems like it would be hard to maintain growth (because lets be clear that these companies where built on the Silicon Valley model of funding that require exponential growth. Or maybe the rabbit wasn't, I've no idea what their business plan looks like, but I wonder where they got the funding from if it wants this model) by selling a 200$ gadget.

The second reason I can think of is that they wanted to build some kind of a moat. With Google, OpenAI, Meta, as well as newer companies like Hugging Face and Anthropic all building foundational models and the infrastructure to build solutions on top of them (like GPTs, Agents, RAGs) it will be hard to compete. You can try to build an assistant, which is close to the standard chat interface of these models, and fight against some of the biggest companies in the world to create a better product. Or maybe you build a hardware gadget that can be used to access these models. Maybe the form factor of your hardware is so nice to use that customers stay with your gadget and pay to allow their assistant to be housed in it… Was that the bet? Its really hard to build a product category.

Maybe the simple reason is that it is much easier to sell a device to an end customer than a subscription? People are reluctant to pay for software and it is much easer to sell B2B solutions. But a device might make people open their wallet? Maybe this is not Spotify, it is a vinyl record that you can hold and display and show your friends?

What's up with assistants?

I mean, I get it. I have a bunch of things I would like to get done and it would be great if someone could them for me. The thing is that most of the things I personally want to get done you need a body to do. I need to do the dishes and put away the laundry, the living room could use some tidying up. At most an AI assistant can assist me by making a TODO list.

What about the things you do online? I'm not happy about letting my browser know my location, handing over my login information to companies that recently was deeply involved with crypto seems like a bad idea. I don't think they have my best interest in mind. Since I struggle to make it through buying a plane ticket without adding extra costs you might understand why I wouldn't want an AI to pay my bills in 2024. I require a lot more hands on control. Did we, collectively, think that the AIs would be so good during this year that we would be happy to let them handle our online accounts?

There are quite a few companies that have started selling automated messages for social media accounts. But that is mostly for business accounts or a personal account that is run like a business. The type of account where you need to post several times a day to stay relevant. It's very different from the personal, private, assistant that the AI pin and Rabbit R1 claim to be.

The reason I started writing this post was because I read this blog about "Complicated Sticks". The theses is that these hardware assistants are a type of complicated stick. You could potentially do anything with a stick. The potential is the attractive part. You are buying the potential to have a magic stick that can help you book a trip, not the actual ability to do it.

How has the role of the UX designer changed?

Simon Rosenqvist — Sat, 30 Mar 2024 07:00:00 GMT

When I first learnt about ux design it was a role that did everything. Your job was to do research, make wireframes, hold workshops, make pixel perfect designs. It was a role where you needed to be able to talk with business people in business way, engineers in an engineering way, and with other designers. To me it seemed like daunting amount of skills you had to master.

When I actually started working i saw that the research role and the designer role was often split. It makes sense to me. Both of these roles takes a long time to become good at and they also the tasks for each role require a lot of time.

As time went on I saw more and more roles become popular. You had UX writers and then soon after that you had content designers. Graphical designers first became UI designers, then UX /UI designers and then maybe they started doing motion design when the big platforms started pushing video. And of course the design system designer.

As tech grew bigger and bigger there were more roles to fill. At big tech there were opportunities to niche yourself so you were both employable and able to focus on the of work that you enjoyed the most.

Today people are getting laid off left and right and the niches are disappearing. When your company suddenly need to "down-size" specialized roles are often the first to go.

I want to understand what niches might stick around but first we need to take a look backwards.

Were there as many niched roles before the dotcom crash?

It seems to me that thee were a couple of strands that ended up being lumped into the UX designer role.

The first strand come from the marketing agencies. In the 90s the internet exploded and the people who had previously done print design, graphic designers, suddenly got a new medium to work in. Over time we have seen a constant exchange, both ways, between marketing agencies and big tech. Graphic designers have today become (in many instances) brand designers. We have also added motion designers to this mix.

Another strand we see from 80s marketing agencies are copy writers. Copy writers have branched out into UX writing and then content designers.

The second big influence comes from engineering. If you were a programmer with a knack for figuring out edge cases on the front end you might start to call yourself Interaction designer. We also get a big influx from the ergonomics. Early usability material uses a lot of similar methods as ergonomics.

The third one is researchers. Often from behavioral science. Interviews and and observations are staple methods in research. It's not surprising that academics wanted to see what it was like outside of the university and design was a good place to go. We are mostly talking about qualitative researches, maybe a few who are good at surveys. When i was going through textbooks about research for design it was mostly qualitative methods. Sometimes more quantitative methods were used but since the number of participants generally low and descriptive statistics was enough. I've never read anything about how qualitative research was/is used in marketing agencies but if you have any suggestions please let me know.

The last strand I've seen is from the "consultant" industry. By that I mean IDEO and the ideas they promoted. A while ago it struck me that IDEO never talks to designers, they are always talking to mangers and directors without a design background. I can't identify a particular role that comes from this influence but they have given us a lot of ideas and ideological baggage. I'm thinking of the workshop methods and of course the design thinking courses. There are more agancies than IDEO of course but I feel they exemplify this kind of influence.

I think I need to stop here for the sake of time and come back to the more current roles in design. As I said in the beginning I don't have any sources for this and I'm more trying to describe a vibe than actual facts.

If you were around for the dotcom crash i would love to hear how things looked before and after and if you have seen the same influences that i have.

The Evolution of UX Design

Simon Rosenqvist — Sat, 30 Mar 2024 07:00:00 GMT

I'm trying to figure out how to deal with all the layoffs in tech and for UX designers. I'm writing this for myself, to myself, to figure out my thoughts where UX design have been and where it's going and how I can advise the more junior designers on my team.

As you may know I'm trying to get an overview for myself on the current state of UX. Last time I wrote about all the different roles that got incorporated under "UX Design" by the time I started getting into it. Today I will try to sketch out some current developments.

Graphic designers became brand designers

I will keep this brief since I mostly work in large enterprise environments and don't often come in contact with this type design. It seems like there has been a shift to calling yourself Brand designer for may of the people who might earlier have been graphic designers. I'm guessing that there were more and more customers out there that wanted things like logos and other brand assets and slowly people just started calling themselves brand designers. This group of people work as freelancers or in agencies more often than the other groups.

UX designers became Product designers

UX designers have always had it tricky to justify themselves. There have been a lot of discourse about how designers should change. "You need to learn about business"/"you need to learn how to code" and I don't know how many articles I've read about showing ROI of design. I think that if you were leaning more towards the business side you started calling yourself a product designer in 2020 and if you liked to code then you might slowly be moving into a design engineer role right now.

Being a product designer I think also reflects the changing climate around design. Compared to the beginning of the 2010s we don't talk as much about representing users any more. We were maybe a bit idealistic back then and maybe right now we are a bit cynical and jaded (There seemed like there was a potential back then to work towards something larger than ourself and more important than a bottom line. That potential seems gone now). Today you need to justify yourself by showing how you improved various metrics that are important to the bottom line.

Design engineering

There have recently been some good articles written about the design engineer and what they do (example, example, example). For the purpose of this post I lump in all kinds of "designers who code" under this category. I also put design system engineers/designers in this category. The design system have helped product designers enormously. In an enterprise environment it is not uncommon for product designers to drag and drop readymade components in Figma (sort of similar to wire framing) and this would not be possible without design systems.

For a company of small or mid size I think it makes a ton of sense to hire someone who can sketch out an interface and then code it. In large companies it probably depends more on that particular organisation. There can be a lot of politics and protecting of ones turf which makes a design engineer a bit difficult to fit in. Unless they work in a design system team of course.

Product managers stepping in

Although PMs have a background from marketing they are one of those roles that really grew up when the FAANGs started using SCRUM and Agile. Today the PM role is often described as being the voice of the customer. This used to be something that UX designers would claim. Maybe they still do? But UX design seems to have de-emphised the research part of the profession as time has gone on. The nature of research have also changed: I see less and less discussion about qualitative research methods while there have been an explosion in quantitative techniques. PMs are more often seen looking at a dashboard of quantitative data rather than post its for a thematic analysis.

These are the major ways I think the UX designer is evolving. I don't want to say that they are dissappearing but I believe the role was very broad from the beginning and it makes it hard to defend a role and a competency. I feel like we are moving toward a future with fewer UX design generalist and more product designers, PMs, Design engineers, and brand designers where the UX designer used to be. I feel like I need to put into words how this changes things and how you might stay ahead and ride this wave.

I'll end here with a reminder that these are very subjective impressions backed up by nothing. If you have a different view or would like to comment then please reach out. It's easiest on mastodon. Thanks for reading.

How to Become a Design Engineer as a Designer

Simon Rosenqvist — Sat, 30 Mar 2024 07:00:00 GMT

Lately, I've been writing more code both at work and on my own projects. It got me thinking—maybe I should understand the design engineer role better.

A design engineer bridges design and engineering. They can design user interfaces and have the technical skills to code them. They often make prototypes in code, contribute to design systems, and take projects from concept to production, which is why I'm interested in them.

Why Do Most Design Engineers Come from an Engineering Background?

One thing that struck me when reading about the role is that most design engineers come from a developer background, particularly frontend or web development. Many of the people in Maggie Appleton's "collection of Design Engineers" seem to come from an engineering background. Design engineers often start by writing software and then transition into design. It's pretty rare to see someone move into it from a pure design background.

As someone who comes from a design background, I think it is harder to move from design into a design engineering role than vice versa. I will lay out my position here and explain the hurdles you might face as a designer.

Learning to Code Isn't the Biggest Hurdle

Surprisingly, the actual programming part—writing HTML, CSS, maybe some JavaScript—isn't the hardest hurdle. There are tons of tutorials out there, and modern design tools are getting closer to how you'd style components in code. On YouTube, you can find loads of tutorials, and if you prefer to read, there are some great blogs and reference sites like MDN.

The first real challenge is figuring out the tools. If you're a UX designer today, you're probably spending most of your time in Figma. As you move more towards engineering, you'll need to get used to new tools.

Setting up an IDE like VS Code with some plug-ins doesn't take long but is very different from Figma. Then there's the whole environment setup and getting your head around version control systems like Git, where you'll have to type cryptic commands into a terminal just to get things running. For someone who's never touched the command line, that can be pretty intimidating. Especially for designers who haven't worked with version handling beyond naming files "final_design_v3_final.psd."

How Things Work in the Real World

Next up is learning how things are done "in the real world." Even if you've studied hard and done a lot of personal projects, when you get to an enterprise environment, things are often done differently.

Say you're a new web developer on the job, and you're given a ticket to have a button open an informational popup for users to read for extra information. You have a solid grasp of the fundamentals, so you make a Pull Request where you implement this as a popover (e.g. <div id="extra-information popover>Extra information.</div>).

Then the feedback arrives: … but that's not how it's done here…

At this job, with this current code base, you:

Use the existing <Popup /> element from the Design System.

Keep the content in the Copy package as HTML strings, so it can be translated.

Make an enum for it (e.g. export const POPOVER_EXTRA_INFORMATION = "POPOVER_EXTRA_INFORMATION") so that anywhere that refers to this component or copy has a consistent name.

Has a component test ensuring it functions correctly.

Use special classes from the design system in order to create variations, rather than it's own bespoke styles.

None of those things are really "fundamentals", they are conventions that this particular code base has grown into over time to make it manageable

— What Skills Should You Focus on as Junior Web Developer in 2024?

These conventions won't be in coding courses. Writing tests, code reviews, and engineering processes are areas where designers might struggle.

This is an area where there's surprisingly little information out there. I'm guessing it's the kind of trade knowledge that people just learn and don't feel the need to describe. The best resource I've found are videos from webdevcody.

The Biggest Hurdles Are Organizational

Honestly, the biggest challenges are organizational. You'll probably need to convince IT to give you admin access to install new programs. Getting access to repositories on GitHub or wherever means talking to the DevOps team or an engineering manager.

You'll also need support from your manager to grow into this kind of role. They might not fully understand what you're trying to do, but their backing is crucial. You'll also need guidance from someone in engineering, which might slow things down as you learn on the job. Remember, you're essentially taking on a junior or intern dev role in addition to your designer role.

If you're part of the design team but doing engineering work, you might end up out of sync with both sides. You could find yourself attending more meetings, trying to stay updated with both departments.

When performance review time comes around, things can get even trickier. How will your manager assess your performance? If you don't fit neatly into the usual job descriptions or leveling guides, it might be hard for them to justify a raise or promotion, even if you've made significant contributions. My only advice is to keep track of what you're doing and show how things would have been missed if you weren't there to catch them.

Is it easier for Engineers to move toward Design?

On the flip side, if an engineer wants to move toward design, it might be a bit easier. They can expand design specifications while still closing tickets. They don't need access to new tools and will still fit into the usual engineering org. They might take longer to finish tasks because they're spending more time on design, but that's a similar challenge designers face when they start coding.

One thing I've noticed is that learning resources for design aren't as comprehensive as those for coding. They often focus on how to use tools rather than teaching design principles. It's tough to find resources that delve into topics like advanced typography beyond the basics.

What to think about for Designers

If you're a designer wanting to become a design engineer, your best bet might be working freelance or at a smaller company. Startups are probably ideal since you'd need to help out with a variety of tasks anyway.

A design engineering role, like any hybrid role, works best if you already have trouble fitting into a mold. If you've been working for a while as a designer, it can feel like starting over. You'll need to augment the skills you already have to stand out.

Focus on areas where you can outperform a full-stack engineer. It could be animation, clever ways to handle design tokens, typography, or micro-adjustments to layout. Use your design eye to add final touches that make a difference.

Transitioning to Design Engineering is hard but possible

Making the transition from design to design engineering is challenging but definitely possible. It helps to be in an environment that supports your growth and understands the value you bring. Having managers and colleagues who back you up can make a huge difference.

So, if you're thinking about making this move, be prepared for some obstacles, but know that it's achievable. And if you're already on this path, I'd love to hear about your experiences.

How to adapt to AI as a Designer?

Simon Rosenqvist — Sat, 30 Mar 2024 07:00:00 GMT

Jakob Nielsen and an "Urgency around AI"

Jakob Nielsen recently wrote that designers need to have urgency about AI. But what does that really mean for our profession, and how should we respond?

Nielsen wrote a blog post declaring that designers need to have urgency about AI. When I first read this article, I was in the process of being let go from my job, and many of my design friends were at least being threatened with losing their jobs. Nielsen writes that designers need to learn AI but doesn't elaborate on what that would mean in practice. It left me with a vague anxiety and stress, and it's only now that I feel I have the energy to address it.

How Do You Use AI as a Designer?

When you search "Design and AI," you'll find numerous articles describing how AI has helped designers build new apps and improve their workflow.

In this article, they outline how they created both the product design roadmap and the most important features using AI. They used ChatGPT to generate the site map and break down each screen. They even used AI to generate code.

In another article, designers discuss using AI image generators like Midjourney, DALL-E, and Stable Diffusion to mockup web design ideas. They also talk about how LLMs can be useful for research—both preparing questions, analyzing data, and querying data afterward. They also used AI for copywriting and to create initial personas for their app.

In a third article, designers use AI for practically everything they need: creating personas, competitive analysis, transcribing user interviews, designing surveys, and generating moodboards.

The common theme across these articles is that AI is primarily used for the first steps of exploration and ideation.

If designers generate a moodboard or an image for a hero section, they still need to use Photoshop to actually finish it. When they create a persona, they need to fill in real data. Currently, AI seems most valuable for speeding up the initial sketching phase and creating quick starting points. The final touches still require a skillful human hand.

What Does It Mean to "Learn AI"?

If this is how AI is being used, what skills do designers need to develop? In this article, the "Grumpy Designer" discusses the skill of prompt engineering, suggesting that designers might be especially suited for it because it requires communication skills that designers supposedly excel at.

I agree that right now, prompt engineering is important. You need to learn how each model behaves and discover the "magic words" that get it to do what you want. But as the field matures, this pain point is something model owners will try to fix quickly.

Prompt engineering will not lead to job security.

A hard truth for designers to accept

Being good at prompt engineering may be valuable in the near term, but I don't see it as a sustainable skill. It's also not very transferable—although you can learn some basic guidelines that apply universally, you'll need to learn specific prompt structures for each model or service.

The article also suggests that building APIs on these models will be valuable. While I see potential in creating new services if you understand an AI model and its API, this isn't typically considered a core design skill. It either veers into a developer role (if you want to write the code that connects to these APIs) or into a more product-focused role. This requires designers to shift their skill set and potentially abandon traditional expertise in typography, color, and composition.

The last piece of advice given is that designers should simply start using all these AI tools. But as we saw in the earlier examples, this knowledge isn't sustainable either. Understanding a model now won't be the same a year from now. If you use one model for a few months and come back later, you'll need to reacquire those skills. This knowledge has a very short expiration date.

So What Is a Designer to Do?

If you listen to some voices, especially on platforms like Twitter/X, it sounds like AI will replace everything—the entire design profession. But if you read about how designers are actually using AI, it's more accurate to say that AI is taking over specific tasks, or even phases of tasks. It's useful to remember that a design job requires many different skills to handle a variety of tasks.

Both the Grumpy Designer article and various Forbes pieces suggest that designers should cultivate interpersonal connection and communication skills. In my experience, as you move from a junior position to a more senior one, you naturally shift from concrete "hard skills" to fuzzier "soft skills" as a manager or design lead. Senior designers typically spend more time in meetings and discussions rather than hands-on design work.

Are we essentially telling all designers to move into leadership roles? A more practical issue is that, in my experience, we're not great at hiring for soft skills. There's no "LeetCode for soft skills" to objectively measure these capabilities.

To Sum Up

Becoming proficient with a specific AI service or mastering prompt engineering won't help with long-term job security. Learning to build applications and becoming a developer might offer more sustained relevance, but then you're abandoning your core competencies as a designer.

The most sustainable approach may be to view AI as another tool in your design toolkit—one that can handle certain tasks more efficiently, allowing you to focus on the aspects of design that still require human creativity, empathy, and judgment.

Rather than fearing AI or rushing to completely reinvent your skill set, consider how AI can augment your existing abilities and free you to focus on the more uniquely human aspects of design.

Command line and prompt interfaces

Simon Rosenqvist — Sat, 30 Mar 2024 07:00:00 GMT

For last couple of decades, we have moved from CLI, the command line interface, to using more and more GUI. For most of us a graphical user interface is faster and it also makes it easier for designers to make functions easy to discover. Now we see a return to the CLI with generative AI we see a return to this prompt driven design.

Types of design for prompts

This blog discusses the trend of prompt driven design. They identify three types of prompt design, navigational core, UX and API.

An example of navigational UI is superhuman, the email app, where you use the keyboard to open and close emails and generally move around. I would add the Spotlight search feature as an example on Mac. The second type is Core UX and this is when the text input is the… core of the experience. An example is ChatGPT along with most of the new LLMs. The last example is APIs which make up the base for these other interfaces.

Accordion editing and Apple picking

Nielsen Norman group has done some research on how people interact with prompts (and AIs) and found some interesting new behavior.

LLMs will often generate something useful, a starting point, but not quite right. To make it better you ask it to write a bit more on a certain topic (expansion), or to reduce the text and shorten it to the most important parts (shrinking). The effect is that the text expands and shrinks as an accordion.

They also saw participants do Apple picking. The text you generate might be pretty bad over all but there are good parts. You copy and paste the good parts somewhere else, picking the good apples. They make the point that today's tools are not really made for this kind of behavior. When writing, or using AI to write, you don't write everything in one go. You want to go back and edit certain paragraphs or pick out the good parts and paste them somewhere else.

We are starting to see some concrete use-cases emerge around AI. The use case for AI is either to make something from scratch that can kick start your process. Change the style the text. Or Make a summary of some text so it is easier and quicker to understand.

I myself often do this and I've seen others talk about it on the Internet as well. If you want to write a longer piece of text, you first ask the AI to describe the different parts and write the first outline. Then you go back and ask it to expand on each section. Once you have a first draft you might move things around or re write certain parts. I often do a lot of text work in Figma because I can easily drag text around and find what I want to say. Supporting this kind of nonlinear way of working instead of this idea could be really powerful.

Examples of people doing this well

Lastly I want to highlight a project that is doing this in a very interesting way from Ink & Switch. Go and read their project notes on how they are trying to design for this new way of editing together with an AI. I think this is really cool and great example of how AI can be used to edit text that expands it outside the prompt box while still being very text based.

The Blunt and Sharp end of AI

Simon Rosenqvist — Sat, 30 Mar 2024 07:00:00 GMT

I read two interesting articles the other day. One about how you build personality into AI and the other about hands on experiences building AI products. They sort of complimented each other and also made me think about something i learned back in university when i studied urban resilience.

AI personality

The first article talks about the personality of an AI and how that can be a selling point in the product market fit. OpenAI is for example more permissive than googles Gemini. This have some guys on twitter up in arms but making a "safe" AI can help attract different kinds of user groups. If a company want a certain tone and to prevent their AI assistant to say controversial stuff you can use Gemini, for others there's Grok…

Thinking about how these companies are trying to compete on things other than accuracy, speed, etc. I thought would come later when these technologies are more commodified. Interesting.

Another things that struck me while reading it is that all of these companies are trying to position themselves to be THE AI service. Their ambition is to become the next platform in AI similar to Google in search, Facebook in socials, or Amazon in sales. right now we have so many options because everyone is trying to make a bet to be the next monopoly. Investors are happy to bet on a dark horse because, if worse comes to worse, they will be acquired.

There have been laws proposed about AI and what data they are based on and how they are allowed to be used but what we really need to have a discussion about is how to prevent more monopolies (and dismantle the ones we already have).

Hands-on advice

Going from the boardroom to the shop floor: this article is about the learnings during hands on building of AI products. The discussion in the news is that AI will come in and completely take over. You just feed the AI some input and write a prompt and they do the whole job. This framing reinforces the idea of a big monopoly platform that can do everything (and also AGI, a topic I dont want to touch with a stick).

One of the key takeaways from the post is that you shouldn't try to do everything because it will be bad and you will fail. Instead find a narrow use-case and build a tailor made solution powered by AI that is tailor made to make it good. This is so realistic and practical that i was surprised to find it in a post about AI. And, it reflects the thoughts of someone working on the sharp end of AI.

Blunt and sharp ends

While at university i studied urban resilience and safety and disaster studies. Very interesting topics for people who likes to mix technology, culture, organizations, and education.

During this i read about the concept of the "sharp and blunt end" of organizations. Let's say that there is a big accident. The sharp end of that accent will be the ambulance people who come to the scene and pick up people and get them into the hospital. They are hands on, they are under time pressure, and they are working with limited understanding of the overall picture (among many other things).

On the other side you have the blunt end of the organization. These are the administrators and managers at the hospital, and at the really blunt end you have politicians who allocate budget. Here time move more slowly, you can wait with a decision until the next department meeting.

The needs and responsibilities are very different between the blunt and sharp end and it feels like we view the AI from a blunt perspective. the details and hands on needs are waved away and instead there are some poorly made studies that simplifies things way too much. Maybe it's just the sources i read when it comes to AI and I should adjust my media diet.

I dont really have a point about this other than there were two articles that made me think and an old concept to tie them together. The blunt end/sharp end is also very useful tool when discussing B2B products, just throwing it out there. Give the articles a read.