Adam Sedwick | Design Operations

Everyone has a Hammer, No one sees the Nail

Tue, 21 Jun 2016 16:00:00 GMT

import { Picture } from "astro:assets"; import image1 from "@images/writing/hammer/ux-quote-1.jpg"; import image2 from "@images/writing/hammer/ux-quote-3.jpg"; import image3 from "@images/writing/hammer/ux-quote-4.jpg"; import image4 from "@images/writing/hammer/ux-quote-2.jpg";

Struggling with UX and Development

There was a recent conversation in the UX Community on Slack Designer Hangout about getting developers to follow wireframes from a UX team. I’ve seen this question, and struggles come up hundreds of times in the last couple years.

My ux team recently has been dealing with front-end developers deciding that they are designers & that ux wireframes are just a loose guideline. It’s been frustrating, because the development ends up having a lot of ux & usability issues. Our front-end devs are not focused on the user but instead what they prefer. I’m wondering if anyone has had experience integrating developers into the design process. Has it helped prevent issues like these?

Thankfully we’ve got lots of active and helpful users. Overwhelmingly the answer given was some form of “Involve the devs in the process sooner rather than later.”

… gives more of a sense of ownership over the project as a whole instead of feeling like the last phase of a long established process

… I try to include the development team in all design reviews, so their concerns can be heard, their input accepted, and their buy-in to design decisions pre-determined.

Definitely talk to them to find out the reason why they didn’t follow the wires, sometimes there are good reasons …

How does this translate to building a team?

The basic principle that everyone is trying to get across here is that a siloed work environment tends to create more problems than benefits. In an ideal world your teams will work closely together and all of the stakeholders (anyone responsible for the end product) are involved in the entire process from start to finish.

The Problem

When working in a siloed environment it’s all to common and easy to fall into the “not my problem” mentality. A strategist comes up with the ideas, a designer creates wireframes or mockups, and a developer is responsible for executing the design in a way that fulfills the users and business’ needs. The problem with this team dynamic is that it’s very linear in practice and doesn’t allow for quick pivoting or taking constraints into consideration early on in the process.

A strategist or designer is not expected to fully comprehend the constraints of a codebase or specific framework. Because of this their ideas and designs may be beyond the scope of capability. With the traditional siloed waterfall approach these issues don’t come to light until the “final” designs reach a developer; typically after they’ve already gotten client sign-off, when it’s too late to make any large changes. This often results in a lot of internal turmoil, and ultimately a lesser product; for both the end-user and the business.

There is also the issue of siloed teams with separate leaderships and goals. A UX team may be focused on creating the best experience for the user. A Design team may be focused on creating beautiful and “innovative” designs. A Development team may be focused on code quality, accessibility, and performance. If these goals do not align you end up with frustration on all sides and no one taking blame because the “other” team(s) weren’t moving towards the same goals.

The Solution

Unfortunately there is to one-size-fits-all solution to the problem. The truth is that solving the problem is hard work. The only way to solve these problems is communication. Communicating about potential issues with the design. Communicating about each teams separate goals and how to align them. Communicating about pain-points each team has and how to resolve them.

The best way to solve existing issues is to sit down and have a conversation, it’s not pretty, it’s not an app, it’s people. People are messy, people have different opinions, people are responsible for the work you’re company puts out. It has to be the people who want to make things better. A client isn’t going to pay you to figure out your process; you can’t put a conversation in a portfolio, but these things are going to make your team more productive. A happy team is a productive team. If your teams work together, if there’s a real bond between employees there is a noticeable boost in moral and a noticeable boon in the quality of work being put out.

People don’t put in long hours for a salaried paycheck. People put in long hours to help and support the people around them. They put in the hard work and the long hours because they believe in the work they’re doing.

As always, keep building better.

Special thanks to Designer Hangout users @gene, @birdsong, @briancrumley, and @bridgetecohen

Blind3y3Design Version 1.0.0

Wed, 08 Jan 2014 16:00:00 GMT

Yay! We're up and running using Jekyll. It took some time and has quite a learning curve, but if you're even remotely comfortable with the command line and you want to create a "simple, blog-aware static site" then it could be the thing for you.

I am by no means a command line guru, and before Jekyll I had never used any markdown language. In just two days I got up and running using Jekyll to set this up. The biggest thing that drew me to using Jekyll was that I wanted to set up a workflow using node, grunt, and sass. Once I installed ruby and set up my grunt stack I realized that it would take more work to version my site before I could push it through FTP to my web host. With Jekyll I could set up a site on Github Pages and my version control would be built in to site contruction and deployment.

I have had quite a lot of fun setting everything up and learning more about the command line and how to use these new technologies.

Big thanks to the creators of Jekyll @Nick Quaranto and @Tom Preston-Werner

Thanks for reading!

Designing a Workflow and Team Dynamic

Sun, 08 Jun 2014 16:00:00 GMT

The idea behind designing a single workflow is that at any time someone else should be able to jump in to your workflow and know where in the process you are and pick up after you if needed.

In our current development cycle this is imperative because we have people being added to and moved from one project to another on a regular basis. Ideally this would not be the case, but until we can fix that issue we can at lease alleviate some of the stress by setting up a unified workflow.

In order to do this we re going to set up some standards and best practices. One of these items is the standard operating procedure and it will be visable for anyone who has access to confluence. We will define these standards together as a collaborative effort so that they best fit the needs of the team as a whole.

A large portion of the new workflow will be the use of JIRA and CONFLUENCE as tools to enhance our productivity. We will use JIRA to outline all tasks to be done whether it is a bug or a new feature to be added. If you are doing something it should be associated with a ticket in JIRA. Confluence is a giant knowledge base. We will use it to hold all sort of useful information, from who is the tech load for a specific client to setting up a new environment or even just simple links to an useful or interesting article.

Atlassian an also has a product called hipchat that I will be looking into in the coming days. It works much like instant messaging and irc combined in to one. There is 1:1 chat and persistent group chat. This will be a great way for the teams to communicate with each other as well as allowing instant communication with another team member without the need to traverse the maze of desks.

The #Talkpay Hashtag

Sun, 03 May 2015 16:00:00 GMT

Something interesting happened on twitter this week. The #Talkpay hastag went viral. This sparked a number of conversations I had with my peers. On the User Experience Design Slack channel we spent a good while talking about the idea, and it's potential ramifications or benefits to the community. So, let's #Talkpay.

So what exactly is #Talkpay all about? I'll let the woman behind the hashtag describe.

Pay inequality is an oft-discussed topic. There are measurable pay discrepancies between groups when looking at race and gender which are further exacerbated when someone is a member of multiple minorities. One need only look at the statistics that show black women making $0.64 to white men’s $1.00 and Latinas making $0.53. These discrepancies exist in a very profound and measurable way across all manner of fields and experiences.

-Lauren Voswinkel | Lets Talk About Pay

If you want more information I would advise going and reading Lauren's full article. The idea behind the hashtag was to bring awareness to the issue of pay discrepancy and try to begin an open conversation about the issue. As I said before the issue blossomed very quickly among the tech community I call myself part of. I was amazed at just how open people were about this and how most of us seemed to have the same opinion.

I have personally been on both sides of the wage gap. My first job out of college was working as a barista at a Starbucks in my college town. It still amazes me how people seem to think that just because you work an hourly job that you're a lesser person. For this reason I still believe that everyone should spend at least some time working an hourly job; preferably some form of customer service. My first "real" job was as a Jr. Front-End developer at an advertising agancy. As someone pretty fresh out of school I was amazed at the amount of money that I was making. More than enough to pay bills and student loans while living under my parent roof.

I had an idea of what my coworkers were making and due to their experience I felt the pay differnce was justified. It was not until I moved out to New York City that I truly experienced the ugly side of the pay gap. My first job in New York was as a Front-End Engineer at an enterprise software company. I was only making slightly more than I had been before, but now I was living on my own and in one of the most expensive cities in the US. I was still making enough to get by, but now I had to begin thinking about budgets and expenses. My fiance on the otherhand was working 40 hours a week on a minimum wage salary, barely making enough to cover half of the rent each month.

I've also worked had the pleasure of working with some amazing women in my field, one being a very dear friend of mine. While looking for new positions we began to discuss our compensation. She had been with the company three years, while i'd been there only 9 months. We were making about the same amount. There was even a meeting that took place where we were told she deserved a promotion, but they didn't want to give it to her because she might use it to find work elsewhere.

The reason I'm writing about all of this is because I think this is a real and undeniable issue in the work force. Part of the solution is to have a discussion about these issues and bring awareness to the wage gap. I also think that having more open and available salary information is part of the solution. Making the discussion of salaries taboo only serves to protect companies that are paying less based on discriminatory grounds. If you think that open salaries is an opening for chaos to take control all you have to do is reaserch the topic a bit to see thats not what happens. There is a wonderfull TED Talk about it that was featured on NPR's TED Radio Hour.

I feel very lucky to be where I am in my career now. I know that I've gotten amazing opportunities in my life, I just want to see everyone else get those opportunities too. Maybe one day everyone will be on an even playing ground, but until then we need to at least be aware of the issues and try to avoid making these mistakes ourselves.

Keep building better.

Blind3y3Design 3.0

Fri, 07 Aug 2015 16:00:00 GMT

Welcome to the new Blind3y3Design!

"3.0? What happened to 2.0?" you say? Here's the deal; after about 4 months of this site being on vanilla Jekyll I decided to switch over to using Octopress. It was great and I didn't have to change much to get it working. The one thing that kept nagging at me was the design. The layout and design of octopress is generally a good layout. Unfortunately as a developer I like to tinker with things and tweak pretty much everything constantly. This meant editing or overriding pretty much everythign about octopress' design.

Over the last year and a half I have worked on a large and varied array of projects, as a results I've learned a number of new techniques and tools. One of these in particular is I've developed my own SMACSS/BEM based Sass naming conventions, even building a framework with it at one point. Now because of this it pains me when I have ot overwrite or use another convention. Along with the naming convention is an organizational folder structure to keep me sane when working on larger projects. I like to split my Sass files up in to folders describing their general purpose.

The reasons mentioned above, and a handfull of others; such as extreme comfort in the command line, have led me back to vanilla Jekyll. I've looked at tools like Grav and Kirby, and they're both great tools, but for Blind3y3Design I felt I didn't need to use such a large tool. If I were building a client site or working on a project with more than just myself I'd pick something like Kirby in a hearbeat; but as a simple personal site, I didn't see the need for a CMS, I'm comfortable in my editor and command line, I don't need an admin panel.

So here we are, I've got a nice simple layout based on Poole by @mdo. It's perfect for me to customize and tinker with as I like. I'm also much more comfortable with the command line, liquid templates, and ruby than I was 2 years ago. I look forward to how this site elvolves and changes in the coming months as my comformt with new web technologies grows and I can build modules on top of Jekyll. Thanks for sticking with me.

As always, keep building better.

Scrum and the Agile Philosophy

Sun, 08 Jun 2014 16:00:00 GMT

Developing our own Agile process is something that we should take pride in. We can take bits and pieces from frameworks and create something that works for our team. The point is not to go whole hog in to a single framework and force the team to work inside the constraints predefined for a different team.

The Origin of Agile

When most people hear the term Agile Development they instantly think of something specific. Unfortunately this is an issue of implicit vs explicit meaning. In it's very nature Agile Development is nothing more than a way of thinking. The philosophy was originally developed in 2001 by a group of programmers who believed the current way of working (the traditional waterfall) was flawed and that there had to be a better solution. This group came together and wrote the Agile Manifesto.

The Principles of Agile

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The Definition of Scrum

Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

Scrum is:

Lightweight
Simple to understand
Difficult to master

Scrum is a process framework that has been used to manage complex product development since the early 1990s. Scrum is not a process or a technique for building products; rather, it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and development practices so that you can improve.

The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules. Each component within the framework serves a specific purpose and is essential to Scrum’s success and usage.

The rules of Scrum bind together the events, roles, and artifacts, governing the relationships and interaction between them.

Creating our own Agile Process

Normally the first step I would suggest is to begin planning on a smaller scale; fortunately we already do this. The weekly "resourcing" that we do lends itself well to the Agile philosophy. In most cases a sprint is defined as a one to two week period of time that has been scoped out and a roadmap has been set for the team. This is where the wheels fall off of our wagon.

- Resourcing:

The current way we do resourcing is by assigning someone "x" hours for project "y". In order for us to move forward as a team this has to change. All scoping and planning for sprints should be task based. Task "x, y and z" need to be completed for project "q" this week. This allows the team to focus on concrete goals for completion and gives a much needed sense of accomplishment to the developers. Resourcing and progress tracking based on tasks also allows for more accurate status updates. If someone is resourced 10 hours on a project and runs into a particularly stubborn issue they may take 20 hours for that project, but what actually got done? It's much more clear is that person is resourced task "x, y and z", that way if they complete task "x" and get stuck on task "y" we can see the progress that was made. If any tasks from the current sprint are not completed it is much easier to understand why; it also sets the groundwork for the next sprint, all unfinished tasks are rolled over and set as priority one for the next sprint.

- Progress Tracking:

Now that we've covered resourcing we can move on to the next step. This is also something that we have implemented to some degree. That is the standup; our version of the Daily Scrum.

The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one. The Daily Scrum is held at the same time and place each day to reduce complexity. During the meeting, the Development Team members explain:

What did I do yesterday that helped the Development Team meet the Sprint Goal?
What will I do today to help the Development Team meet the Sprint Goal?
Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

With the implementation of proper sprints we will easily be able to talk about the progress towards the Spring Goal.

- Review and Retrospective:

Something that we do not really focus on as a team is a review of our progress. Much of this can be attributed to the fact that we don't track our progress in a good way. By implementing the tools mentioned above we can improve upon this and it will enable us to review the progress we have made and talk about adapting the process in order to become more efficient.

- The Sprint Review:

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.

- The Sprint Retrospective:

The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. This is a three-hour time-boxed meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches all to keep it within the time-box. The Scrum Master participates as a peer team member in the meeting from the accountability over the Scrum process.

The goal of the Reviews and Retrospectives is to:

Look back at the previous scrum and go over what has been completed. (Rev) Look back at the previous scrum and go over what has not been completed. (Rev) Discuss any issues that the team ran in to trying to reach the Sprint Goals. (Rev) Display the completed items from the previous sprint and answer any questions from the stakeholders. (Rev) Collaborate on what should be done in the next sprint, providing a baseline for the next sprint planing session. (Rev) Review the timeline, budget, and potential capabilities for the project. (Rev) Inspect how the last Sprint went with regards to people, relationships, process, and tools. (Retro) Identify and order the major items that went well and potential improvements. (Retro) Create a plan for implementing improvements to the way the Scrum Team does its work. (Retro)

Conclusion

I believe that by implementing, adapting and iterating on the processes listed above that our team will grow and become much more successful in the future. With a better process we will be able to develop our products more quickly and be able to take on larger projects. We will also be able to onboard new team members in a smoother fashion so that they can understand what we are doing and what is expected of them.

As always feedback is always appreciated and encouraged.

The Hamburger Menu Is Not The Enemy

Tue, 11 Aug 2015 16:00:00 GMT

Another anti-hamburger menu article is making it's rounds again. This time from deep.design. A simple google search returns a number of articles about how the design pattern is a "useless tool" and should be avoided at all costs. I'm going to argue that the ideas behind the design pattern are neither useless nor harmful.

The issue most often brought up is that you can't use what you can't see; and that a user is not likely to go searching for an option they're not even sure exists. While I agree with both of these points they're not the fault of the hamburger menu, they're the fault of poor lazy design. Case in point, the priority+ menu pattern works.

The issue tends to stem from people not wanting to do the hard work of IA. Pick the thing your users will actually use and display those, when there’s more screen real estate you display more content. The hamburger menu isn’t a catch all. No menu will ever be a catch all. You have to deliberately decide what to show and what to hide.

Designers like Luke Wroblewski do a good job of identifying the issues that come with the standard hamburger menu. I'm arguing that hiding everyting inside of a single menu with no context the issue be it a hamburger or anything else.

Part of a good design is a good underlying architectural pattern. Without a rock solid information architecture you're going to run in to any number of organizational and structural issues. Understanding this and setting up content structure is all part of the overall design. The hamburger menu removes any of the complicated hard work that comes with content strategy and information architecture, so people are drawn to it as the easy option.

As the designer part of your job is educating your stakeholders on the most effective way for them to increase value based on their business metrics. Again, I feel like this step is overlooked because it's hard and dirty work that requires research and planning, it doesn't fit the idea that the designer goes away and comes back with the mythical perfect design.

The Guardian is the perfect example of this. It's a massive news site with a complex and sprawling taxonomy, but things are easy to find. The Guardian also happens to use the Priority+ navigation pattern. The navigation displays relevant options based on how much screen real estate is available. When you lose real estate you get less options and they're moved to the expandable menu, when you gain real estate you get more options. All of the key actions are readily available and it's clear by the design that anything else is in the menu. The Facebook app is another good example of this. While it utilizes a hamburger menu it also has the most used actions readily available in the bottom bar.

Responsive Web Design turned the industry on it's head, there are a lot of challenging problems to deal with when your site can't be fixed to a single size and layout. Part of that work is creating a functional navigation; the hamburger menu was the first on the scene and people gravitated to it because it made a small portion of their job easier, while it's not the final solution it was a move towards better design at the time. We're constantly iterating over the rest of our designs, why have we stalled on this single pattern? We need to keep pushing forward and eventually we'll find better solutions and the hamburger menu will be a relic that we barely remeber.

As always, keep building better.

I dont want a 'Smart' Home, I want a Smarter Home

Tue, 28 Jun 2016 16:00:00 GMT

Living a simple, usable, connected life

Knocki, Amazon Echo, Google Home, Amazon Dash (and Button), the Ikea Smart Kitchen Concept. All of these products and ideas share one core value; making daily tasks available instantly and on demand. Putting what you need where you need it without any additional cognitive load. Each one of these products or concepts takes a different approach to the problem, but they are all essentially based on the idea of allowing you to do a task a little bit easier or faster. They may not be solving world-changing issues, but they do want to make your life a little bit easier.

Voice Assistants and Conversational UI

Amazon Echo and Google Home take the conversational approach. We all know how to talk to someone, so why not talk to our devices? “Alexa, turn on the lights.” “Okay Google, how long is my commute to work today?” These two phrases are both based on a simple task, getting up and turning on the lights, or checking your commute on a website or app. Neither task is particularly hard, but when you’re in the middle of something else, being able to quickly use a voice assistant can save valuable time. If I’m working on a project and it gets dark, getting up to turn on the lights may seem tedious to some, but the cost of context switching, and losing focus on what I’m doing could end up costing hours of work. The cost of context switching is a real and documented thing. You can read up on it here and here.

The commute question offers a more complex and interesting example that gives insight into how we might use technology down the road. First, there is the idea that your AI assistant has external context for the conversation. “my commute to work” I did not ask for specific directions from point A to point B. I did not even give an origin point. The phrasing of the question implies that I am at home, “my commute”, it also implies that the assistant knows where I work, or at least the location of a place that I have identified as “work”. Using a traditional mapping app or website I would need to input at least an end point, and either a starting point or allow my current GPS position as a starting point. I must then go through a series of interactions simply to get the duration of the trip and any potential traffic. If my assistant can do all of these things while I’m getting ready it saves me time, and again, allows me to focus on something that I have deemed more important at the moment.

Action at your fingertips, Tap and Click interfaces.

The Amazon Dash Button was a particularly unique product when it came to market. Many people didn’t quite understand the point of a physical devices that had a single purpose, click and instantly re-order an item from Amazon. Was there a real world use-case for such a specialized product? Did anyone really need this? It seemed like another tech bubble product that was designed to solve a problem that didn’t actually exist. Even if that was the case, it was an interesting experiment and opened the door for people to continue exploring the concept.

Amazon themselves expanded on the button’s concept when they released the Amazon Dash. This new product has a barcode scanner and voice recognition. It’s tied to AmazonFresh and allows the end user to quickly or say an item name and add it to their cart. Grocery delivery services are not new, PeaPod was founded in 1989, but having the ability to quickly scan a barcode and know that you’re getting the exact same product in a new innovation that makes the process that much easier.

Knocki is a new product being kickstarted right now. It brings automation to your fingertips, quite literally. The Knocki team is promising the ability to place their product on any surface and program it to understand a series of taps. You can then set the device to perform any “smart” function you would like. Place it under a coffee table, three taps to play/pause the television. Place it behind a door and it can send you a notification when someone knocks. The idea of the Knocki is particularly exciting to me because it is essentially promising the possibility of turning any surface into an invisible interface. As we teach about UX and building an unobtrusive UI, the best interface is one you don’t notice. Being able to tap on a table is exactly that. There is no interface, no buttons, no notifications, just you being able to accomplish a task when and where you want.

Smarter Living

In 1999 Disney came out with with the movie Smart House. This house could cook, clean, and provide anything the family needed. Often it feels like this is the goal we’re striving towards with all of the “smart home” and “home automation” technology, but it also feels like we’re missing the key point, it was all a single interface, the house’s AI.

The modern smart home could have any number of brands attached to it, Nest, Samsung, Philips, Amazon, and Google. All of this, and without some third party none of them really want to talk to each other. I don’t want 14 different apps or systems that I have to set up and control. I don’t want to have to fumble through an interface every time I want to change a lightbulb or plug in an appliance.

These new interface-less products and ideas are pushing us to rethink how we interact with our world. The smarter products get the less of a guided experience we will need to interact with them. You can ask Alexa to purchase something for you, you can quickly tap on your table to adjust your thermostat, one day you may be able to place ingredients on your kitchen counter and have it give you a recipe for dinner. In the future we may not need visual interfaces, these “smart” things are the stepping stones to that future. I look forward to what it holds.

As always, keep building better.

The High Horse Mentality

Tue, 12 May 2015 16:00:00 GMT

Spurred by Lara Schenck's post on CSS-Tricks I have decided to toss my two cents in to the bountiful fountain of knowledge.

It seems the age of 'Unicorns' has spawned a number of people who wind up simply being pricks sitting on their high horses. I'm not saying that people who claim to be unicorns are those people, or that they're wholly guilt free either. It just seems the issue has bubbled to the surface more apparently in the recent past.

After reading Lara's article and agreeing with pretty much every sentiment she expressed I decided to chase the article rabbit down the internet hole. There are two links they Lara shares in her article that caught my attention and elicited a strong reaction to their content. The first being about the Illegal use of the 'Engineer' title, and the second being Why Can't Programmers... Program. My first issue with both articles is the apparent superiority expressed in both articles. To a certain extent I understand a mechanical or civil engineer being protective of their title; it takes a lot of work to get those positions. But to claim that the use of the term should be illegal to all others, whom have potentially gone through equally, if not different, amounts of work seems a bit eccessive. On whose authority was it deemed that knowing the different electrical resistances, or tensile strength of a material, is inherintly more valuable then understanding how all the parts of a software stack interact with eachother, of the determining factors of packet loss and performance?

The superior mindset extends to CodingHorror's post and perhaps even exceeds the other. What defines a 'programmer'? How can we; both qualitatively and quantitatively, measure what makes one better than another? Code reviews and 'simple' programming tests can only go so far. At what point does willingness to learn outweigh inherent knowledge, particularly with entry level positions? Claiming that "... 199 out of 200 applicants for every programming job can't write code at all" is not only humorous, it's insulting. Again I'll ask, what is a "programming job" Is a typical 'Front-End Developer' a programmer? What about someone who develops entire web apps in Javascript? While I don't self describe as a programmer, I do believe that I can and do partake in the act of programming, if the project calls for it.

For arguments sake lets look at a couple of definitions. Merriam-Webster defines programming as "the act or job of creating computer programs", and a program as "a set of instructions that tell a computer what to do". Pretty sure; by those definitions, writing a simple html page qualifies as programming. You're providing the computer a set of instruction on how to organize the content of the page. I also understand that in the context of the article the term "programmer" has a certain connotation that is not the dictionary definition, but the article itself is still encouraging a negative mentality that only furthers the issue.

It would appear that the authors of those articles; and those they cite, are firmly seated on their high horses, and have forgotten that everyone has to start somewhere, and it is your job as a more senior member of the community to guide them and help them grow.

Now Lara's article isn't about these articles, it's about her experience interviewing for a job. I feel that part of the "199 out of 200" problem is that we as an industry have vague and constantly changing job titles and descriptions. For continuity's sake we'll examine programmer again. Depending on where you look; god forbid a recruiter contact you, a programming position could range in requirements from "html, css, and js" to "c# expertise" and "sql mastery", even "swift experience a plus" if you're looking at app development. So now we have a job title that could fit pretty much anyone, and just as confusing a job description that reads like a page out of "Buzzwords for Idiots". Sprinkle in some form of "UX" and you have an entire company being listed under a single position. This results in people applying for; and ultimately interviewing for, a position that they expected to be one thing, and ended up being something completely different.

I would never apply for a C# of Java position, but on any given day I could come across 2-5 "Front-End" listings that include those technologies under requirements. I've even seen UX positions that read like a senior developers job, and have no mention of any UX disciplines. When looking at a potential job listing I defer to something that people much smarter than myself have found useful; describing the actual job, describe a potential project role the new employee may be asked to fulfill. An interview should then be a series on conversations, in addition to gauging skill level it is also important to find cultural fit, willingness to learn, and leadership potential from the interviewee.

Titles are beginning to mean less and less in this new world that we are working in. Legacy organizational structures are going to be pain points. Innovation is already begging to emerge in this area, self sufficient agile teams and companies that follow the 'lean' methodology are proving that there is no need to adhere to the old way of doing things in order to produce exceptional products. In fact they tend to be able to iterate faster resulting in a better product faster.

I don't have a proper conclusion, or a solution to these issues. What I have found works for me, and teams I've worked on is to approach organizational issues as we would any issue we might run in to; propose a solution, test, and iterate on the successes while learning from the missteps. There is no one solution, find what works for you, and keep working to improve it.

As always, keep building better.

Bridging the Gap

Sat, 25 Apr 2015 16:00:00 GMT

Bridging the ‘Handoff’

uxreactions.com

While I appreciate a lot of what is on the site, I must say; seeing the number of developer complaints make me very sad. I also noticed this trend at a recent meetup I attended. A large number of designers; UX, visual, IxD, voiced a number of complaints about developers. I’ve heard the same from developers about designers. I think this is an artifact of traditional waterfall approaches and the 'hand off'.

If we want to grow as teams and communities I think we need to stop complaining about each other and finding ways to bridge the gap. Sometimes an overly decorative design really does affect performance, and a slow experience is a poor experience.

One of the worst offenders of this point of view is the clients from hell blog. More often than not, the issue is not the client. It’s the designer not providing clear instruction and having a feeling of entitlement that puts them above the client.

I’ve also noticed that a number of thought leaders in this area have found their success by getting their teams to work together. Ethan Marcotte and Karen McGrane; the host of theresponsive web design podcast, interview team members to often speak very highly of their counterparts, be it design or development.

Some of the best teams I’ve gotten to experience work in a very close manner. I believe the popular term form them teams right now is a ‘lean’ team. These teams work together to produce the best product, the design team understand the underlying structure of how the web works. Developers can not only give input on design decisions but are often invited into design reviews. In my experience this cooperation produces better results and happier teams.

Keep building better.

The Importance of UX and a Guided Introduction

Fri, 08 Jul 2016 16:00:00 GMT

import { Picture } from "astro:assets"; import image1 from "@images/writing/pokemon-ux/pokemon_1.jpg"; import image2 from "@images/writing/pokemon-ux/pokemon_6.jpg"; import image3 from "@images/writing/pokemon-ux/pokemon_2.jpg"; import image4 from "@images/writing/pokemon-ux/pokemon_3.jpg"; import image5 from "@images/writing/pokemon-ux/pokemon_5.jpg"; import image6 from "@images/writing/pokemon-ux/pokemon_7.jpg"; import image7 from "@images/writing/pokemon-ux/pokemon_8.jpg"; import image8 from "@images/writing/pokemon-ux/pokemon_9.jpg"; import image9 from "@images/writing/pokemon-ux/pokemon_10.jpg";

As with everyone else I picked up Pokemon Go when it released in the US this Wednesday. After pouring more than a couple hours in to it, and talking with a lot of people I have a few thoughts on the UX of the app and how it could be improved.

Guided Introduction Issues

When you load up the game you're dropped directly into the game (when the servers load, but that's a whole different issue). The main screen displays your digital avatar and a couple of visual representations on the bottom of the screen.

The first issue I take with this is the lack of information that the screen provides you. What does the portrait of my avatar represent? What does the Pokeball do? What is the list of Pokemon on the right?

Any "gamer" will almost immediately identify what the portrait represents and how to use it. It's become pretty standard for a portrait to represent your avatar with additional information, typically a health and some type of energy bar. In this case, the bar is for your trainer level. What may not be immediately identifiable is the fact that you can click this portrait for additional information, such as achievements, a "journal" of recent activity, and [when you hit level 5 and visit a gym] your trainer's team. The Pokeball is an interesting icon. If you're familiar with Pokemon you might think you'd use this button to catch a Pokemon you run into in the "wild", this is not the case. The Pokeball opens up a sub-menu that you can use to view other screens; Pokedex, Shop, Pokemon, and Items.

The last item on the initial screen is the most frustrating one for a lot of players. This bar can display up to 3 silhouettes, or images of Pokemon. It provides no additional information off the bat. When the user does an exploratory tap of the bar they are created with a new pop-up screen. Turns out this bar is displaying "nearby" Pokemon.

The pop-up menu can display up to 9 total "nearby" Pokemon. If you have seen a Pokemon before it will display their image, otherwise you get a "Who's that Pokemon!?" style silhouette. There is also a secondary visual on this screen, the footprints. Nowhere in the game does it every explain to you what these footprints are. People have been resorting to googling and trial and error to discover what they mean. Turns out that they represent the distance a "nearby" Pokemon is to your current position. Each footprint represents 100 meters, up to a total of 3 footprints or 300 meters. You can select one of the Pokemon in the "nearby" pop-up menu and it will "track" that Pokemon, displaying only that single Pokemon and a representation of the distance it is away.

How do I know where the Pokemon are? Is it completely random encounters?

As for finding Pokemon, this is where the game drops the ball again. It doesn't give you any insight into how to run into Pokemon. If you sit and stare at the screen for long enough you will notice little animations of rustled leaves. Through more googling a player can find out that these animations are showing a location with a higher change of discovering a Pokemon; however if you're tracking a specific Pokemon there is no guarantee it'll be that one.

Nice-to-Have Improvements.

After getting the hang of the core gameplay loop and getting to try my hand at a couple of gyms I inevitable came across a situation where I wanted to heal my damaged Pokemon. In this case, I had stationed a Nidorina at a local gym, the gym was challenged and defeated, this resulted in my Nidorina returning to me with 1hp.

My first thought was to click on the Nidorina in order to heal it. I was taken to the Pokemon's detail screen where I could see it had 1hp, as well as information about powering it up, evolving it, it's attacks, where I originally found it, and an option to "transfer" it. None of these options were what I was looking for. How do I heal my poor wounded Pokemon?

I know I have potions in my Items, so why can't I use one? I decided to go to my items menu and double check that I did in fact have potions.

Yup, 10 potions. I decided to click on the potion, and sure enough, you have to navigate to the sub-menu, then to the items menu, then click on the item you want to use. Seems like a lot of steps when I was already looking at my wounded Pokemon.

Once you click the Potion (or Revive) the game displays a list of all the Pokemon that would be affected by the item selected. While this is a nice consideration, I still think it would make more sense to allow the player to heal their Pokemon directly from the Pokemon's detail view. There is no way of knowing that a Pokemon is injured without going into the Pokemon menu, so it seems like a lot of extra steps to force the user out of their current menu, and through 3 additional layers of menus just to complete the desired action.

So, do I like the game?

Don't get me wrong, I love Pokemon Go. I think Niantic has come up with an incredible game that is amazingly fun when it works properly. I just feel like the product was rushed and more than a few corners were cut when it comes to the UX of the game. I didn't talk about how the game handles Pokemon battles, but as with everything else in the game, there is little to no explanation about how to participate in them, again the players are left to trial and error or google to figure out how to use the application. I hope the game turns out to be a profitable venture for both Nintendo and Niantic because I see a lot of potential for this type of experience.

Numerous other bloggers and new sites have stories about how they're seeing other people walking around playing the game. My wife and I have made a sort of meta-game where we try to see who is playing around us; turns out our community is pretty active on the game. We've seen at least 5-6 other couples or groups of people walking around playing the game. They've got a lot of momentum right now, it'd be a shame to see them lose it; and ultimate lose out on the change to continue growing and exploring this new type of experience, because of a few missteps at the beginning.

As always, keep building better.

Extending CSS with Programmatic Selectors

Fri, 13 Sep 2019 16:00:00 GMT

There are many powerful tricks in CSS that allow developers to apply styles in more nuanced ways than a simple class or id. The goal of this article is to introduce developers to some of the more obscure and nuanced selectors and how they can be used to apply styles in a more programmatic way.

Introducing the Attribute Selector

I often see developers write Javascript code to add or remove classes to apply styles that could be applied through native html or data attributes.

This is where the [attr=""] selector comes in to play. For example html[dir="rtl"] applies styles when the html element has the dir attribute with a value of rtl.

Data Attributes

Much like native attributes, you can select data attributes instead of also requiring a custom class. Many modern JS frameworks use data attributes to indicate the state of components. By using the [data-attr=""] selector you can apply styles based on this existing code rather than also applying additional markup for presentational means.

<button
  class="button button-with-tooltip button-with-tooltip--top"
  data-tooltip-text="I am a Tooltip"
  data-tooltip-location="top"
>
  I have a tooltip
</button>

The above code is how a developer would add classes to an element in order to use them as hooks for styling.

<button
  class="button"
  data-tooltip-text="I am a Tooltip"
  data-tooltip-location="top"
>
  I have a tooltip
</button>

The same element using data attributes to apply styles without additional classes.

.button[data-tooltip-text] matches any button where the data attribute is present regardless of the attribute value. We can use this to apple global styles for any button with a tooltip.

.button[data-tooltip-location="top"] matches buttons with the data attribute value of top. With this selector we can apply styles that are specific to buttons where the tooltip will be displayed above the button.

Wildcard matches

You can select elements with attributes — href, class, etc. — that include, start, or end with specific strings. This can be useful to target specific types of links, or a full set of class types.

Contains = [class*="card"]. The * wildcard matches any attribute value that contains the passed string.
Starts with = href^="tel:". The ^ wildcard matches any attribute value that begins with the passed string.
Ends with = href$=".org" The $ wildcard matches any attribute value that ends with the passed string.

Psuedo-selectors

Psuedo-selectors are used to target elements based on a specified state. :hover, :visited, :active, :disabled and :checked are the more commonly used psuedo-selectors.

Empty Element Selectors

:empty, :blank, and :-moz-only-whitespace. Useful for cleaning up excess whitespace that may be caused by empty elements generated by content management system text editors.

:empty targets elements with no content or only comments, but will fail to target elements that have any whitespace.
:blank is part of the level 4 selector spec. As part of the Working Draft it is not currently available, but is on the horizon.
:-moz-only-whitespace functions like :blank and is currently available in Firefox.

Focus-Within

:focus-within applies to an element that has received focus or contains any children that have focus.

:focus-within is a newer selector that has support in most modern browsers. There is no support in Internet Explorer or current versions of Edge; but, there are many small polyfills available if desired.

Content Length Selectors

:nth-child, :nth-of-type, :only-child, :only-of-type

The most common use-cases are to use :nth-child(odd) to style table rows in a zebra pattern, or :first-child and :last-child to remove margins.

Extending these selectors with some logic and math opens their potential to create new dynamic layouts. Chris Coyer wrote an extensive article back in 2011 detailing some of the more useful recipes.

One recipe I end up using a lot is :nth-child(Xn+Y) This formula allows you to select every X child, starting with child Y. When creating grids of items you can select the beginning or end of every row for more granular control.

.card:nth-child(4n+4) {
    // Add styles to every 4 .card elements starting with the 4th
}

The Target Selector

:target display styles when the id of an element matches the segment of the current url.

Pre-processor Selectors

Many developers now use CSS pre-processors like Sass, Less, and Stylus. These pre-processors have built-in-functions that provide additional utility when authoring CSS.

Pre-processor parent context selector

This selector is useful to reduce code bloat if you need to add a specific style based on the parent element’s class.

.class {
    &.other-class {
        // these styles apply if .class also has .other-class
    }
    .parent-class & {
        // these styles apply if .class has a parent with .parent-class
    }
}}

compiles to

.class.other-class {
  /* these styles apply if .class also has .other-class */
}
.parent-class .class {
  /* these styles apply if .class has a parent with .parent-class */
}

Pre-processor selector modifying

You can combine selectors by touching the ampersand. This works well with naming systems like BEM. Rather than writing out the block each time you can nest inside the block and use the ampersand.

.block {
    &__element {
        // these styles match .block__element
    }
    &--modifier {
        // these styles match .block--modifier
    }
}}

compiles to

.block__element {
  /* these styles match .block__element */
}
.block--modifier {
  /* these styles match .block--modifier */
}

Bringing it Home

Thinking in a more programmatic way about how to author styles allows for cleaner semantic markup, and reduces the complexity and points of failure when combining presentational and functional changes.

Combining this way of thinking with modern build tools available to developers means code can be easily scanned and human-readable speeding up the development process and reducing human error.

Thanks for reading!

If you have any suggestions or ideas, feel free to reach out on Twitter or drop a reply.

Header photo by Maik Jonietz on Unsplash

Is 'Mobile-First' as an idea dead?

Tue, 27 Aug 2019 16:00:00 GMT

Way back in January of 2016 Intercom wrote a blog post titled "Why mobile first is outdated". This post sparked a conversation over on the User Experience slack community Designer Hangout. I’m going to share some of that conversation.

Mobile-First in a Device-Agnostic world

The ideas behind mobile-first are relatively new, They only really came about with the advent of smartphones that could reliably access the internet. The iPhone had a large hand in this, and to this day that presence can be felt across the industry.

A number of companies still use separate mobile and desktop websites, and a lot of those that have moved to "responsive design" may still only think in terms of "desktop", "tablet", and "mobile" device sizes, typically with one or two breakpoints for each device. Many designers and developers should be familiar with these numbers: 1024, 768, 414, 375, and 320, these are the most commonly used static breakpoints. 1024 is the width of a landscape iPad, 768 being the portrait view. 414, 375, and 320 are the widths of portrait iPhones, 6(s)+, 6(s), and 4/5(s/c) respectively.

The real question is whether or not these breakpoints still matter in today’s web landscape. The answer to that question is: no, not really. In today’s web you have no real reliable way of knowing how a user will visit your site. While waiting for my morning coffee I may check your website on my phone or smart watch, same goes for commuting. While I’m working I have access to multiple large screens. I may even happen across your site being displayed on a television. A single day may take my eyes from phone to tablet, to monitor to television, you have no way of knowing which one I will be using when I visit your site.

How can you guarantee that I’ll have the same or equivalent experiences across all of these devices? You could set up a max-width on the entire site, but then you lose the ability to take advantage of the extra real-estate on larger screens. At the same time, if you stop thinking about devices at a 320 pixel width, i’ll end up with a sub-par experience on any device that falls below that. This is where Device-Agnostic design comes in. Trent Walton has written a great article on what it means to be Device-Agnostic.

Is the "Mobile" in "Mobile-First" hurting the industry?

When most people think mobile first their first thought is of the phone in their pocket. What would this look like on my phone? This is where the term "Mobile-First" does itself a disservice. "Mobile" has an implied connotation, that of a "mobile" phone. This connotation may prevent people from thinking about even smaller devices. The implications of thinking of "mobile" as a wireless, touch-screen device also impact how we think about designing for "mobile" and "desktop". Touch being one of the bigger features that we take for granted on mobile devices. Often we’ll see layouts better suited to touch on smaller screens. However, there is nothing stopping a larger screen from having touch capability. On the other hand, we often see larger "desktop" layouts with additional flourishes because we assume that people visiting the site on a larger screen have a more stable internet connection; as with touch, there is nothing that says a larger screen has a connection any better than a mobile device, particularly in emerging markets.

Device-Agnostic Performance Focused Design

It might not be a catchy buzzword, but essentially what we’re striving towards with "mobile-first" methodologies is a site that is performant across the board, works across all devices; big and small, and provides the user with the information they’re looking for.

In the end, if no one is willing to use the product, you might as well not have built it.

Header Photo by Thom on Unsplash

Rethinking Buttons in a Production Design System

Tue, 16 Feb 2021 16:00:00 GMT

import { Picture } from "astro:assets"; import originalButtons from "@images/writing/rethinking-buttons/original-buttons.jpg"; import buttonExamples from "@images/writing/rethinking-buttons/button-examples.jpg";

After two years of the Comet Design System being used by our teams in product we'd begun to see and hear designers and product owners consider non-system button styles and variations. In situations like this you need to make a decision as a system - either become the dreaded design police and "squash creative freedom" or embrace the idea of product inspired variation. We chose the latter.

Embracing external variation

Our original button component had two possible colors, two sizes, and three visual variations. All in all it was a pretty standard spread, you had your primary and secondary colors, "default," ghost, and flat buttons, and the ability to make them smaller with reduced padding.

This worked fine for a time, but eventually product teams would want a product branded button, or we'd hear concerns about the secondary color looking like a disabled button, causing the ghost variation to become our de facto "secondary button."

We also saw some explorations and desire for additional shapes of buttons. Younger audiences showed more interest in bigger, rounder, "softer" buttons, a pill button for example. Specific global callouts or action items could benefit from a FAB - floating action button.

Using these requests we began the task of internal system variation exploration. One of the key factors in this exploration was defining variation categories and their relationships to each other.

Variation categories

Looking at our existing button component it became clear that we didn't not have the ability to have a ghost or flat button using anything other than our primary color. This realization revealed that our button component was quite restrictive in use. You could have a "default" button in two colors, and then a ghost or flat button in one. Our amazing extensible, design system had unintentionally limited our design potential to 4 fairly similar buttons.

Why could we not have a secondary ghost? Was there logical reasoning behind it or had we simply overlooked it? Could there be the potential of color variation for product branding or creating intentional friction to slow a user when required? The answer to both of these questions is yes of course. Taking stock of our variations allowed us to identify what we call variation categories.

We identified four core categories to expand our button:

Color
Type
Shape
Size

Having these specified categories allows for a more nuanced way of thinking about the variations, a button would have any value from each category to create a custom variation.

Color

The color category defines what color a button is this may seem simple, but as a system it is important to identify and explore all options because we have made a commitment to inclusive, extensible, and sustainable design. Being able to identify color as a specific category allows us to identify when some variations should be disallowed - a light colored ghost button on a white background for example.

We expanded our button color palette to include product branded colors as well as light, dark, success, warning, and danger colors. We also made the decision to allow any button to be any color. This alone expanded the creative possibilities greatly.

Type

The type category defines the type, or style, of button. In our case we settled on the same three variations we had before; the filled, ghost, and flat types.

Shape

The shape category defines the shape of the button. What shape your button takes can change the feeling and tone if a design. Our default shape was a rectangle with rounded corners, we expanded upon this shape with a pill for use when a softer aesthetic is desired. We also created an icon-only FAB shape variation for use when we need a global-style callout.

Size

Size is simple enough to think about, is the button normal, small, or large. Smaller buttons may be desired in a denser interface or as actions in a table layout. Larger or expanded buttons may be desired as promotional elements or for younger audiences and those with cognitive or physical difficulties.

Now instead of limiting our designs to one of four variations our designers and developers could use and combination of category values to create hundreds of variations to fit their specific needs.

Header Photo by Siora Photography on Unsplash

2023 in Review

Sun, 24 Dec 2023 16:00:00 GMT

One Post a Week

Back in September I set a challenge for myself to try and write one blog post a week through the end of the year.

I figured, 7 days to write one single post? Peace of cake. Turns out that writing is a lot harder than I thought. I managed do to it though, and it’s something I plan on continuing moving forward. I’ve learned a lot not just about writing, but about managing time, and actually prioritizing tasks.\

Projects

Accessibility Playbook

I started a new project this year!

In an effort to document and share my experience and knowledge around accessibility and creating accessible experiences I created my accessibility playbook.

I’ve found over the years that I consistently point team and community members to reference sites or checklists and wanted to be able to centralize the items that I have found important or useful in my own work. By creating my own playbook I can customize it to meet my specific needs or thoughts, and link out to those same resources from a publicly available and centralized location.

I hope to continue to grow this playbook with more patterns, methods, tips and tricks that I come across and share with the teams I work with.

Design Tokens Community Group

Lots happening behind the scenes. The second editors draft was released for review in just of 2022. Since then the Format team has been hard at work figuring out all of the finer details of the spec. Lots of discissions are taking place in the Design Tokens Community Group github repo.

The DTCG is taking a break for the holidays, I am excited for what we’ll see come out of the spec team in 2024. We’re also beginning to take a hard look at what sorts of resources we can and should provide to the community from an educational and reference standpoint.

IndieWeb and a Slower Social

I added both a /Uses and a /Now page to this site. I hope to be able to keep these up to date as things change. It's been interesting to see these types of pages, along with other IndieWeb practices become somewhat more commonplace across the web; at least with the people I follow.

I have also added some basic IndieWeb features to this site, like rel=me links, and author/article h-cards. I'm sure I'll share some thoughts on my overall experience trying to adopt some practices in the future.

Finally, between mostly moving from Twitter to Mastodon, and spending a lot more time curating and consuming RSS feeds, I feel like I'm getting much more value out of the content I am spending my time consuming. Both Miriam Suzanne and Chris Coyier have exelent posts on this topic.

Other Life Updates

2023 has been a crazy year for the family. Our kiddo turned one this year and I can’t believe how much he’s grown over these last 12 months. It’s hard to imagine he’s the same tiny baby that couldn’t go more than 10 minutes without crying.

Two weeks ago a crazy off-season tornado ripped through our town. Our house made it out without a scratch but large portions of the community were affected and have been dealing with either damage or complete devastation. The timing of the event definitely put a lot of things into a new perspective this season. I’ve spent the last few weeks thinking about how lucky we are, and how important and fragile the normalcy of life is.

We’re also trying something new as a family this year. We’ve invested in a massive wall-sized calendar and are going to try to plan out our year in advance. We often hear that if you don’t make time for the things that are important to you work or other insignificant tasks will find a way to fill your time. I’m hopeful this will allow us the foresight and confidence to accept or reject invitations and plan our own family growth goals for the upcoming year.

Goals for 2024

Sun, 31 Dec 2023 16:00:00 GMT

As this year comes to an end and we begin looking into the next one I’ve decided to publish my goals for the next year in a hope that this will help keep my accountable to reaching them.

Visit Scotland

We’ve planned a trip for this fall to visit England Scotland and Ireland. This is one of our major family goals this year. I am very excited for this trip and It will be one of our first big travels with our child.

Config 2024

I’ve already purchased my ticket and am Very excited to be able to attend in person this year. I’m hopeful to get to connect with some web peers and get chatting more about design, tokens, accessibility, and how we use our tools.

Continue “1 Post a Week”

I’ve really enjoyed the challenge these past few months of holding myself accountable to publish 1 post a week. Some weeks are definitely easier than others, but as I want to continue getting better at writing and sharing knowledge I feel like this is a good goal to continue to hold onto in the coming year. Additionally, even at just 1 post a week, that’s 52 posts a year! and if you ask me, that’s kind of amazing.

Publish 1 larger “Essay” style post a quarter

I was really proud of the work I put into Be a Design A11y, and it’s something I’d like to be able to repeat. In addition to putting out 1 post a week, I’d like to try and publish one larger “Essay” style post a quarter. These posts could be about anything, but will probably focus on accessibility, design, and design tokens, especially if we get some good movement on design tokens in 2024.

Quarterly Check-ins

Similar to “week in review” or “vibe-check” style posts. I’d like to take time each quarter to reflect on any progress made towards goals, life changes, or just how I am feeling at in the current season. I feel like these check-ins are a good way to see progress being made over time, as during the hustle of day-to-day operations it may seems like nothing is changing.

Accessibility Playbook

I would really like to keep developing content and tooling around my Accessibility Playbook. The goal when I started this project was for it to be a place where I could collect knowledge and resources that I reference and share out to people as I work with accessibility. As I continue to grow, learn, and find new resources I would like to add them to my playbook and grow it into a sort of useful reference manual for myself and my teams.

A Conference Talk or Course

I’ve never given a conference talk or written a course before, and it’s something I want to push myself to try. Even if it doesn’t pan out the process of creating and researching for these items can become blog posts, or add to other items I am working on.

That’s it for now. I hope 2024 bring new experiences and interesting challenges to overcome. Here’s to 2024 🥂

Why I'm Not an Accessibility Expert

Mon, 30 Oct 2023 16:00:00 GMT

This past weekend Dave Rupert put out a blog post talking about being publicly shamed for having poor accessibility. In his closing thoughts he talks about how; despite his growing knowledge and experience designing accessible products, he stills finds “creating end-to-end accessible experiences difficult.” I particularly resonated with the penultimate sentence of the post.

After nearly thirty years of making websites –despite being someone who cares deeply– I’m more confident in my ability to produce an inaccessible experience than an accessible one.

I call myself an Accessibility Advocate, a term I am very comfortable with. I will always go to bat for accessibility, fighting hand-over-fist for individuals who so often are forgotten, ignored, or treated like an afterthought stapled on at the end. I believe that “Accessible Design” is “Good Design,” creating a more usable experience improves that experience for everyone. I have first-hand experience with cognitive disabilities, and have experienced temporary and situational physical disabilities.

Despite all of that, I do not call myself an expert. I do not believe any one person could be an “Accessibility Expert.” There is simply too much to know. I can not tell you how someone who is bind personally experiences the web, what tools they use, or how they navigate a page. I don’t have experience with getting vertigo because something moved too fast across a screen, or getting derailed from an experience because of a distracting audio source.

I know all of these things happen, and that all of these people are just as deserving of a great experience as the rest of us, but even I make mistakes. All I can do is try my best, and call for others to do the same. The world of accessibility is a vast one. It can often feel like an overwhelming amount of information to try and retain, but start small. Something is better than nothing.

In the words of the Lorax:

Unless someone like you cares a whole awful lot.

Nothing is going to get better. It's not.

A Playbook for Accessibility

Thu, 28 Sep 2023 16:00:00 GMT

In my work with Design Systems, accessibility often comes up as a topic. Questions can range from the incredibly basic, "What is accessibility?" to the more complex and nuanced, "Is the language of this modal clear enough?" Part of my job is to help guide the designers, developers, content producers, and product owners on their individual journies understanding accessibility and how it impacts their work.

In an effort to not only help the teams I work with, but the larger digital product community I created what I’m calling the Accessibility Playbook, a manual for teams and individuals to reference in order to ensure the products and experiences they create can be used by the largest number of people.

Accessibility is an incredibly dense topic to begin learning, and while there are many resources available already it never hurts to have more. I hope to grow this playbook beyond the basics of what accessibility is, to contain answers to common questions and bring clarity to potential pitfalls. Additionally, I would like to provide helpful insight and useful examples of how to create accessible products for all practices that contribute to the overall accessibility of a product.

Taking off with Astro

Sun, 17 Dec 2023 18:00:00 GMT

It's been about 3 years since I moved this site over to 11ty (Eleventy), and it's been a great ride. I still think 11ty is a fantastic static site generator, but I wanted to try out some new front-end frameworks and I feel like a personal website is always the playground to learn new things.

The two frameworks I've had my eye on for a while now were Astro and Svelte with SvelteKit. I originally explored rebuilding this site with SvelteKit and that work can still be found here. However, since I wanted to learn both, I had simultatiously set out to rebuild my Accessibility Playbook which was also an 11ty site using Astro. In the end I completed that project first, and found that I gravited more to the way Astro likes to do things over Svelte, so I abandoned the SvelteKit rebuild of this site and kicked off a new build in Astro.

Why Leave 11ty?

Since there was really nothing wring with 11ty if I wanted to just keep writing blog posts and updating the website there wasn't really anything that needed to change. What ended up ultimately convincing my to hop ship was the edges I kept running up against in 11ty with wanting to build a more component-based system. In my day-to-day work with design systems I am often working with and advocating for component-based design; and it just wasn't coming together the way I wanted in 11ty. Sure you can create nunjucks macros, and pass around data that way, but there was no "native" solution to "proper" component based design patterns, at least not one I had found at the time.

Benefits of Astro

For me, the biggest benefits to astro were:

The same native support for markdown (and MDX) files. Not having to move, or massively rewrite my content was a must-have,
Native component-based design patterns baked into the framework. It's an added benefit that Astro can effectively use any other framework's components as well. We use Vue at Discovery Education, and there's no reason I couldn't simply pick up and drop in a vue component onto this site if I wanted to.

Astro's "content collections" function very similarly to collections in 11ty with the added benefit of being able to define custom typescript based schema per-collection using Zod.

Moving Forward

I've still got a fair bit of tinkering and cleanup ahead as I reduce duplicated code and create components, but all of the site links should be working and I feel it's better to launch and update than continually tweak without every launching something.

One major change right now is there are no themes on this version of the site. Losing theme support is sad, but it's high on my prioroty list to re-enstate them as soon as possible.

I've had a blast moving over to Astro and look forward to the new flexibility that I have in creating components, layouts, and content.

Brad Frost on Atomic Design

Sat, 14 Oct 2023 16:00:00 GMT

Brad Frost recently posted this wonderful article reminding us all that Atomic Design is not a step-by-step process, and instead a mental model we should use to look at the parts and whole of a design at the same time.

I know that I’ve been guilty of this myself. It’s very easy to fall into the trap of designing in a vacuum; especially with “Atomic” components like buttons or input elements. The idea that you can just design something real quick and push it out to users in an incredibly enticing one, but designing anything without understanding the context in which it will live and the content that will ultimately surround it is a recipe for disaster.

So thanks for the reminder Brad!

Rendezvous with Cassidoo Newsletter 9/18 Interview Question

Sat, 23 Sep 2023 16:00:00 GMT

Here's my answer to the Sept. 18th Rendezvous with Cassidoo newsletter interview question. It was a fun little coding challenge.

It's a little more verbose than needed, but I liked the idea of calling out and explicitly naming the variables so that other people could follow the logic. I also adding small bit of error handing to ensure that you did in fact pass the function a number.

function buildStaircase(n) {
  const numberOfStones = n;
  let numberOfSteps = 0,
    stonesPerStep,
    remainingStones = numberOfStones;

  if (isNaN(numberOfStones)) {
    return "Error: must provide a number.";
  }

  for (stonesPerStep = 1; stonesPerStep <= remainingStones; stonesPerStep++) {
    remainingStones -= stonesPerStep;
    numberOfSteps++;
  }

  return numberOfSteps;
}

buildStaircase("not a number");
// Returns Error: must provide a number.

buildStaircase(6);
// Returns 3

buildStaircase(10);
// Returns 4

Andy Bell updated his CSS reset!

Tue, 10 Oct 2023 16:00:00 GMT

It seems I wasn't the only one who went to visit Andy Bell's post A Modern CSS Reset after it made an appearance on the Shoptalk podcast.

He's since put out an updated post, so I figured since I commented on the first it was worth sharing the new one.

A (more) Modern CSS Reset

CSS Reset, Normalize, and Base Styles

Mon, 18 Sep 2023 16:00:00 GMT

Inspired by a conversation between Dave and Chris on the recent shoptalk show episode 582, I wanted to take a look at the history of CSS resets and see what I could put into a “reset” or “normalize” file that was tailored to my specific sensibilities.

Why did we need to reset CSS?

Since the earliest days of the web different browsers have had their own opinions on what the default presentation of elements should be. The most common offending styles were the default padding and margin styles applied across base elements such as headings or p tags. A CSS reset was a file that would take all of these browser opinions and wipe them out.

As an example, one of the most well-known css reset created by Eric Meyer contained this selector:

html,
body,
div,
span,
applet,
object,
iframe,
h1,
h2,
h3,
h4,
h5,
h6,
p,
blockquote,
pre,
a,
abbr,
acronym,
address,
big,
cite,
code,
del,
dfn,
em,
img,
ins,
kbd,
q,
s,
samp,
small,
strike,
strong,
sub,
sup,
tt,
var,
b,
u,
i,
center,
dl,
dt,
dd,
ol,
ul,
li,
fieldset,
form,
label,
legend,
table,
caption,
tbody,
tfoot,
thead,
tr,
th,
td,
article,
aside,
canvas,
details,
embed,
figure,
figcaption,
footer,
header,
hgroup,
menu,
nav,
output,
ruby,
section,
summary,
time,
mark,
audio,
video {
  margin: 0;
  padding: 0;
  border: 0;
  font-size: 100%;
  font: inherit;
  vertical-align: baseline;
}

As you can see in this line of code, there is a massive list of elements, and all of those elements are being force to have no margin, padding, or border. The font size for all of these elements is also set to be 100%, which for most browsers equates to 16px. font: inherit and vertical-align: baseline force these elements to all use the same font settings and vertical alignment respectively.

These practice of using these types of files allowed designers and developers to work from a completely blank slate without needing to fight with or override existing styles for every individual browser.

Normalizing browser behavior instead of wiping it out

In 2012 Nicolas Gallagher created and released normalize.css the idea behind this project was to move past the idea of completely wiping out browser defaults in favor of preserving useful defaults and “normalizing” them across all browsers.

Resets impose a homogenous visual style by flattening the default styles for almost all elements. In contrast, normalize.css retains many useful default browser styles. This means that you don’t have to redeclare styles for all the common typographic elements.

When an element has different default styles in different browsers, normalize.css aims to make those styles consistent and in line with modern standards when possible.

By this time HTML5 and CSS3 along with web standards had taken hold and browsers had come closer into alignment on more generally agreeable base styles. Using something like normalize made much more sense for projects as it meant that we did not have to manually write styles for every element being used, and if you forgot to style an element it wouldn’t appear completely broken since we didn’t completely destroy it’s native styles.

Proving it’s usefulness and widespread adoption, you can still go to the normalize.css github repository and see the project has over 50k stars and is used in over 545k other repos.

A modern web reset?

As discussed on the Shoptalk show, Andy Bell created a post in 2019 titled A Modern CSS Reset. If the community had moved away from resetting styles and adopted something like normalize.css so strongly, why would we go backwards and reset css today?

For starters when taking a look at Andy’s post you’ll note the reset is significantly smaller, more conservative, and even uses a few modern selector features to intelligently target specific situations.

Starting at the top the very first item in the reset should be familiar to anyone who has worked with CSS:

/* Box sizing rules */
*,
*::before,
*::after {
  box-sizing: border-box;
}

To the chagrin of many CSS developers, one of the great things about the web platform is how unlikely it is to change something in favor of backwards compatibility. Because of this the browser default for the box model and thus box-sizing is still content-box. Unfortunately for us, this means that if you add a border to an element, by default that border is not included in in the width calculations for an element. This universal reset forces every element, as well as the psuedo ::before and ::after elements to use the border-box model; matching how many people think about sizing, and saving developers from having to make complex calculations to account for borders.

Similarly, Andy’s reset removes the base margin from many elements. In my own work I often find I am either removing or overriding browser default margins on all of these elements as well, so this is another case where I feel a reset is also applicable.

Looking at one last item from this reset:

/* A elements that don't have a class get default styles */
a:not([class]) {
  text-decoration-skip-ink: auto;
}

I wanted to call this out because it shows the novel thinking behind this style of reset and I feel this sets the foundation for thinking about our own resets or base styles. What this selector is doing is grabbing any <a> tag that does not have it’s own custom class and applies the text-decoration-skip-ink: auto; style. I personally jive with this line of thinking. Often when we’re styling an experience we will create our own custom styles for elements, and with a selector like this we’re still defining what we would consider a pleasant default to be even if an element does not end up getting the full treatment of a custom class.

My own base styles

While I don’t necessarily consider it a “reset” I will often find that I am creating a similar baseline to build my styles off of. I would consider these to be my “base styles,” a clean and simple foundation that I can build the rest of my styles on top of.

I’ve taken many of the ideas in Andy’s post with some of my own personal thoughts and combined them with some of CSS’s new features like custom properties and nesting to create my own personal base styles.

Here they are:

*,
*::before,
*::after {
  box-sizing: border-box;

  @media (prefers-reduced-motion: reduce) {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

body,
h1,
h2,
h3,
h4,
h5,
h6,
p {
  margin: 0;
}

body {
  color: var(--text-color);
  font-family: var(--font-family);
  font-size: 18px;
  line-height: 1.4;
  min-height: 100dvh;
}

h1,
h2,
h3,
h4,
h5,
h6 {
  &:not([class]) {
    color: var(--header-color);
    font-weight: bold;
    line-height: 1.2;
  }
}

a:not([class]) {
  color: var(--link-color);
  text-decoration-skip-ink: auto;
}

img,
picture {
  max-width: 100%;
  display: block;
}

input,
button,
textarea,
select {
  font: inherit;
}

Culture Eats Strategy

Sun, 12 Nov 2023 16:00:00 GMT

Culture Eats Strategy for Breakfast

This famous quote from Peter Drucker has popped up a few times of the past couple weeks for me.

We've been working on ways to improve our processes and strategy for design and how we work with other teams within our organization. I've spent countless hours of the previous months looking at team processes and organizational strategies.

One thing I keep coming back to is "How do we get people to want to do this?" We could outline and micro-manage our process until we turn blue in the face and none of it would matter if we can't get people to actually read docs, follow a process, and encourage others to to the same.

I just started reading Culture Wins by William Vanderbloemen, and in the opening lines there it was again "Culture Eats Strategy for Breakfast."

It's hard to think about designing a culture, what does that even mean? Often a workplace or team culture will develop naturally on it's own, forming it's shape based on the individuals present. This can result in an incredibly powerful and productive culture in the indivuduals who are there to shape it have those qualities. Unfortunately, in the same manner, an unintentional culture can also grow to be incredibly apathetic, negative or at it's worst, hostile.

In UX and product design we often talk about customer empathy; understanding the feelings, emotions, motivations, and frustrations of your customers. However, I feel like we often neglect this very same principle when thinking about management and organizational design, our coworkers are our customers.

I hope to find ways to be intentional about the sort of culture that I cultivate within my teams. My goals are: continued learning, empowerment, and celebration of success. I am not sure of the roads we'll take to get there, but I look forward to the challenges and victories along the way.

I don't know that I have a lot to say on the subject right now, these are just some ruminations as I continue to learn about and research developing an intentional culture.

Be a Design A11y: An Introduction to Accessibility

Tue, 05 Sep 2023 16:00:00 GMT

import { Picture } from "astro:assets"; import { Icon } from "astro-icon"; import contrastExample from "@images/writing/design-a11y/contrast-ratio.png";

This is an introductory overview of Accessibility and how it relates to designing and building digital products and experiences. The goal of this post is to provide a general reference for high-level accessibility topics that anyone can use. It is assumed that readers have basic computer literacy and an understanding of how digital products are built.

What Is Accessibility?

Mozilla's page on What is Accessibility puts it best:

Accessibility is the practice of making your websites usable by as many people as possible. We traditionally think of this as being about people with disabilities, but the practice of making sites accessible also benefits other groups such as those using mobile devices, or those with slow network connections.

In short, caring about accessibility and creating accessible digital products means you're putting in the effort to ensure that anyone who wants to experience your product can.

What about A11y?

You may often see the term A11y when reading about or looking up accessibility. A11y is a numeronym or number-based word for Accessibility. Similar common numeronyms in the tech space would be L10n and I18N for Localization and Internationalization respectively.

The 11 in A11y stands for the 11 letters between the A and Y in the word accessibility. Due to the fact that the term A11y looks like the word Ally the community often uses the shorter numeronym because we enjoy and encourage the thought that working in accessibility means you’re being an ally to people who need accessibility features and support.

Why should I care about Accessibility?

As a creator of digital products accessibility should always be a consideration at any stage of the product development cycle. According to the CDC, 1 in 4 adults in the US live with some type of disability. On top of this, many accessibility features are not just for disabled individuals, building products with a consideration for accessibility often means that the overall experience will be better for everyone.

<div class="svg-container"> {/* {% svg "@images/writing/design-a11y/inclusive-design.svg" %} */} </div>

As part of their Inclusive Design work, Microsoft has outlined and documented the realities of disability in the modern age. According to the World Health Organization, "Disability is not just a health problem. It is a complex phenomenon, reflecting the interaction between features of a person’s body and features of the society in which he or she lives.” Microsoft has represented this in their guidelines with different modalities of disability they call the Persona Spectrum. For example, a person with 1 arm, a person with an arm injury, and a new parent holding a child all fall into the same modality of “has one arm to interact with the product.”

Additionally depending on the market your product serves there are now many laws in different parts of the world that require digital experiences to be accessible. In recent years that has been an increasing trend of digital product and experiences facing litigation for failing to provide accessible experiences, you can find more details in the 2022 recap report from Level Access.

Understanding Accessibility Principles

So now that we know what accessibility is, how do we actually go about crafting accessible products and experiences?

A good place to start is with the 4 principles of accessibility: perceivable, operable, understandable, and robust, often referred to by the acronym POUR. At it’s most basic these are the 4 pillars on which all other guidelines sit.

<div class="svg-container"> {/* {% svg "@images/writing/design-a11y/pour.svg" %} */} </div>

Perceivable

Information and user interface components must be presentable to users in ways they can perceive. This means that users must be able to experience the information being presented; it can’t be invisible to any of their senses.

The idea behind the principle of perceivable is that no matter how a user is accessing your product they can experience the content. For a sighted user this is as simple as displaying an image or text on the screen. For a non-sighted or low vision user this would mean adding meaningful alt text to non-text content and ensuring that the text is properly read by a screen-reading tool.

Operable

User interface components and navigation must be operable. This means that users must be able to use the interface and it cannot require interaction that a user cannot perform.

The principle of operable states that, much like perceivable, a user should be able to use an interface, regardless of how they’re using the product. An example of this would be a user being able to navigate through an interface using a keyboard. A control on an interface should not require the user to use a specific input device such as a mouse to interact with it.

Understandable

Information and the operation of user interfaces must be understandable. This means that users must be able to comprehend information as well as how to use the interface.

The understandable principle outlines that a user should not only be able to experience and interact with a product or interface, but that they should understand what they are doing or expected to be doing. The simplest example of ensuring an interface is understandable would be to include instructions and labels with any input or form. On a login form the inputs should be clearly labeled so the user knows which field is for a username and which field is for a password.

Robust

Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies. This means as technologies and user agents advance and evolve, content should remain accessible.

Finally, the principle of robust explains that on top of all of the above criteria your product should be able to integrate with or be interpreted by as wide a range of tools as possible. Robust products and experiences not only work in a browser, but properly expose their contents to assistive technologies like screen readers without errors or crashing.

Accessibility Guidelines and Standards

Putting the principles into practice is easier now than ever before. Thanks to the Web Accessibility Initiative (WAI) of the W3C we have the Web Content Accessibility Guidelines, more commonly known as the WCAG. The WCAG is an international standards document that outlines the what and how of specific accessibility features.

The original document known as WCAG 2.0 was published in 2008 and outlined 12-13 guidelines, which in turn had testable success criterion with the defined levels of A, AA, and AAA. In 2018 the updated WCAG 2.1 was published to expand upon the 2.0 version with 17 additional success criterion. As of the writing of this article there is an additional update, WCAG 2.2 that is scheduled to be published in 2023.

Color Contrast Example

One of the most common success criterion discussed and cited is that of adequate color contrast.

Success Criterion 1.4.3 Contrast (Minimum)

(Level AA)

The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following:

Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;

Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.

Logotypes: Text that is part of a logo or brand name has no contrast requirement.

As you can see the requirements within the success criterion are very clear and explicitly testable. Any time text appears in an interface, the color of that text should have a contrast ratio of at least 4.5:1. There are of course exceptions to this rule, but those exceptions are also clearly denoted and provided with testable values of their own where applicable.

In Summary

Accessibility is the process of ensuring that your digital products and experiences can be used by everyone. Accessibility practices not only improve the web for those with disabilities, but can also enhance the experience for all user by providing clear instructions, descriptions, and wayfinding markers.

I hope you’ll take what you’ve learned here and join me as an A11y, helping make the web a more inclusive and accessible place for everyone.

Additional Resources

Web Accessibility Initiative

Introduction to Web Accessibility

MDN Accessibility Guides

Level Access

The A11y Project

Accessibility For Everyone

Inclusive Toolkit Manual

Microsoft Inclusive Design

Diving into DesignOps

Tue, 12 Sep 2023 16:00:00 GMT

Over the last few months I’ve been spending more of my time learning and thinking about how to implement a DesignOps practice across the teams I work with. Large portions of my work with Design Systems already relate to a number of DesignOps ideas and principles: helping teams solve for efficiency, effectiveness, and codifying standards around commonly used patterns so that teams can focus on the hard problems of their individual domain expertise.

DesignOps refers to the orchestration and optimization of people, processes, and craft in order to amplify design’s value and impact at scale.

As the teams that I work with continue to grow and the organization itself scales it has become clear that we need to implement and codify some operational standards. How we organize our teams and files within Figma, how we handle design reviews, who is responsible for what, and how we measure the success of our work to name a few.

I am excited to dive in to the topics above and explore solutions with my team and the teams we serve to continue pushing the boundaries on what we can achieve.

I want to give a massive shout out to Elyse Eshel and Meredith Black for founding the DesignOps Assembly as it has been an invaluable resource when looking for how to get started with DesignOps providing a Slack community, the DesignOps Guide & Glossary (DOGG), and even their formal training through the DesignOps Assembly Learning Lab.

Learning Grid Thanks to Codepen Challenges

Sat, 18 Nov 2023 16:00:00 GMT

This past week I partook in my very first Codepen Challenge.

This month’s Codepen challenge is Style Trends. It’s an interesting “meta-challenge” where every week the HTML template provided is exactly the same and you need to create a unique design that matches the theme of the week.

This past week the theme was Neo-Brutalism, and while I don’t fancy myself the best designer in the world, I do happen to enjoy a good challenge, Having a background in print design focused on Bauhaus and International Typographic Style I thought this would be an exploration that is right up my alley.

The Challenge

The most interesting part of the challenge for me was the limitation that you can’t alter the markup in any way.

<p class="codepen" data-height="600" data-default-tab="html" data-slug-hash="poGdqGb" data-user="Blind3y3Design" style="height: 300px; box-sizing: border-box; display: flex; align-items: center; justify-content: center; border: 2px solid; margin: 1em 0; padding: 1em;"> <span>See the Pen <a href="https://codepen.io/Blind3y3Design/pen/poGdqGb"> Neo-Brutalism Codepen Challenge</a> by Adam Sedwick (<a href="https://codepen.io/Blind3y3Design">@Blind3y3Design</a>) on <a href="https://codepen.io">CodePen</a>.</span> </p> <script async src="https://cpwebassets.codepen.io/assets/embed/ei.js"></script>

As you can see, every “section” is nested within a single parent. There is no actual implied or intended layout at all. With the goal of making a “dashboard” I wanted to be able to have grids of “cards” that I would be able to arrange into a specific layout.

In terms of modern layout technologies I know flexbox like the back of my hand, but it’s also the tool I typically reach for when designing components and layouts, unfortunately without any additional layout-based containers flexbox wasn’t going to work here.

I was going to need to use CSS Grids. Within my own work I’ve only dipped my toes into the power that Grid provides. I’ve used it to great simple “grids” of cards, and occasionally within a component itself for layouts, but never for anything this big or complex.

.dashboard {
  grid-template-areas:
    "profile profile profile profile profile profile activity activity"
    "schedule schedule schedule schedule exercises exercises activity activity"
    "calories calories personal personal challenges challenges activity activity";
}
.profile {
  grid-area: profile;
}
.schedule-table {
  grid-area: schedule;
}
.exercise-table {
  grid-area: exercises;
}
.calories {
  grid-area: calories;
}
.personal-bests {
  grid-area: personal;
}
.challenges {
  grid-area: challenges;
}
.activity-feed {
  grid-area: activity;
}

I initially tried to use grid-template-areas, but it quickly became frustrated with the way they work, given I wanted a row with 2 items, followed by a row with 3, and then 4. In order to accomplish this I would need to spell out exactly where I wanted each item in a repetitive fashion with named grid-areas, It just seemed like more work and duplication than what I could achieve with grid-template-columns and grid-template-rows.

Focusing on my chosen method of using columns and rows, I was able to combine multiple selectors that had similar styling in order to reduce the complexity of the code. In my design the .calories, .personal-bests, and .challenges elements all had the same basic style and layout, so I could combine all of that code into a single style.

.calories,
.personal-bests,
.challenges {
  --color-inner-shadow: var(--color-white);

  background: var(--color-white);
  border: var(--brutal-border);
  box-shadow:
    10px 10px 0 -3px var(--color-inner-shadow),
    10px 10px var(--color-black);
  display: flex;
  flex-direction: column;
  gap: var(--space-1);
  padding: var(--space-1);

  @media (min-width: 1024px) {
    grid-column: span 2;
    grid-row: 3;
  }

  ul {
    gap: var(--space-1);
  }
}

The main layout heavy work here is being handled within the media query. The entire dashboard is single column below 1024px. You better believe this dashboard is responsive.

@media (min-width: 1024px) {
  grid-column: span 2;
  grid-row: 3;
}

Because this style is being applied to all 3 elements I know that they will all span 2 columns, and be located in the 3rd row. These elements are the first, second, and third elements in this row, so they take up the first 6 columns, leaving 2 columns of space all the way to the right for the .activity-feed element, which is styled to start at column 7 and span 2 while starting in row 1 and span 3.

.activity-feed {
  // Other Styles

	@media (min-width: 1024px) {
    grid-column: 7 / span 2;
    grid-row: 1 / span 3;
  }
}

Final Thoughts

This was the most I’ve ever worked with CSS Grid, and by far the most complex layout style I’ve done with it. My go-to would have been to wrap the content in multiple containing element in order to section out the layout and use flexbox to achieve this same design. I’m incredibly happy with the final product, and don’t know if I would have had the opportunity to explore the layout power of Grid had I not attempted this challenge.

I look forward to evaluating past code and, when considering work in the future, watching for where we can begin to smartly implement CSS Grid over multiple nested elements to achieve a layout.

If nothing else, I had a blast with this challenge, and will be trying my hand at the next 2 weeks as well to see what different kinds of techniques, layouts, and designs this inspires. I would encourage anyone to take a look at these challenges as they’re a great way to practice your skills and try out new things with “real-world” style constraints.

Here's the final results (for a full-view visit the pen):

<p class="codepen" data-height="600" data-default-tab="result" data-slug-hash="poGdqGb" data-user="Blind3y3Design" style="height: 300px; box-sizing: border-box; display: flex; align-items: center; justify-content: center; border: 2px solid; margin: 1em 0; padding: 1em;"> <span>See the Pen <a href="https://codepen.io/Blind3y3Design/pen/poGdqGb"> Neo-Brutalism Codepen Challenge</a> by Adam Sedwick (<a href="https://codepen.io/Blind3y3Design">@Blind3y3Design</a>) on <a href="https://codepen.io">CodePen</a>.</span> </p> <script async src="https://cpwebassets.codepen.io/assets/embed/ei.js"></script>

Invest in Improvement

Sat, 02 Sep 2023 16:00:00 GMT

I have been reading "The Making of a Manager" by Julie Zhou over the past few weeks. In chapter 5, titled "Managing Yourself," she emphasizes the importance of taking advantage of formal training opportunities.

Zhou points out that even if a 10-hour training experience results in only a 1% overall improvement, the net benefit is still significant. Over the course of a year, a 1% improvement in work output or efficiency translates to roughly 20 saved hours.

As the lead of a team focused on design systems and operations, I am always seeking ways to improve the efficiency of my team and the teams we serve. It is easy to view a 10-hour training opportunity as a huge time commitment and question its value. However, we should redefine the worth of such opportunities based on their potential value.

For example, a full-day workshop with nine attendees may seem expensive from a cost and trade-off perspective, requiring roughly 80 work-hours. But what is the potential outcome of the workshop? If it results in the team coming into alignment or finding a clearer path to success, then it is worth the investment. Even a small 1% increase in efficiency makes up for the time spent. That one-time 80-hour investment could result in an efficiency improvement of 160 hours a year.

Investing in yourself and your teams may seem costly in the short term, but over time, the benefits will become clear.

Learning IndieWeb with Apple Annie

Sat, 09 Dec 2023 16:00:00 GMT

I’ve been wanting to learn more about indieweb tech and how to incorporate more if it into my site.

This past week Anne over at Apple Annie’s shared a post collecting her recent writing about her own indieweb adventures using indiewebify.me

I plan on reading and learning from these over the next few weeks and thought a signal boost was in order.

Thanks for putting this all together Annie!

The Production-Ready Myth

Fri, 06 Oct 2023 16:00:00 GMT

For years now there have been programs, tools and libraries that all claim to deliver on the same promise, delivering to you “Production-Ready” code.

Dreamweaver was entirely based on the idea that you could design a website in their visual tool and it would generate all of the HTML for you, neat!

And now, in this new era of AI, there is a sea of tools, plugins, and apps making the same claim. Just feed the hungry machine a juicy prompt and it will spit out a fully formed “production-ready” app, magic!

The problem is that neither of these things are true.

Production-Ready For Who?

In the early days of “web design,” when we were still using tables and very rudimentary CSS the Dreamweaver proposition made a lot of sense, and surely did end up saving people time. We no longer live in that word, websites and apps have become much more complex, and (as of today) computers simply aren’t smart enough to parse an image and understand the best way to build a website from it, let alone all the nuanced decisions that come along with the range viewports of modern devices.

I have not personally used many of the magic AI tools, but it doesn’t take a wizard to understand that these tools are not going to generate perfectly usable, responsive, and accessible code that can just slot right into any kind of existing product or project. Maybe if you’re starting something completely from scratch one of these tools could get you to a quick alpha or beta release, but I just don’t buy that we’ve cracked the code here. The majority of the internet is not accessible, if these tools were trained on code that already exists, they learned to write code based on a majority that does not concern itself with being accessible to everyone, that doesn’t sound production ready to me.

Providing Realistic Expectations

Working in design systems, I and my teams have often used the term “Production-Ready” when describing the components, patterns, and styles that we provide. After the thinking that went into this post, I don’t know if I will continue to make that claim. The reality is that the work we put out is suitable and viable for production, but I can not determine how that code or styling is being integrated into a product or experience.

If you take a component from our system and plop it onto a page it should be completely ready to go. We don’t ship anything that is not responsive, accessible, or functional. If you don’t change anything, are working in the same stack we build in, don’t have other potential integration needs, and are trying to solve the same problems, sure our stuff should be 100% production ready; but that feels like a lot of caveats.

For me, I’d much prefer to think of what we create and ship as Production-Viable, or Production-Suitable. These things can be used in production, you don’t have to start from scratch and we’ve solved many problems already, but we should still validate that the final implementation meets our requirements and not assume that the “production-ready” code just works.

Using Block Quotes for Social Embeds

Mon, 06 Nov 2023 16:00:00 GMT

import { Picture } from "astro:assets"; import twitter from "@images/writing/social-block-message/twitter.png"; import mastodon from "@images/writing/social-block-message/mastodon.png";

Back at it again, Chris and Dave on the Shoptalk Show (ep. 590) mouth-blogged the idea of having custom block-quote styles based on the location of the source of the quote.

Chris already wrote about the concept of using a block quote in place of an actual social media embed, but he simply matched the design of the blockquote to his site.

I thought it would be a fun excercise to take their idea through to completion and allow for "custom themes" based on the source of the quoted material.

The basic setup is pretty simple. We start with a blockquote with a cite child element.

<blockquote>
  <p>"Make the common configurable and the uncommon composable"</p>
  <cite>
    — Adam Sedwick (<a href="link.to.author">@AdamSedwick</a>) —
    <a href="link.to.post">Nov 16, 2022</a>
  </cite>
</blockquote>

Which results in:

<blockquote> <p>"Make the common configurable and the uncommon composable"</p> <cite> — Adam Sedwick (<a href="#">@AdamSedwick</a>) — <a href="#">Nov 16, 2022</a> </cite> </blockquote>

It's a bog-standard blockquote!

Now lets add some magic:

blockquote {
  background: var(--blockquote-background-color);
  border-inline-start: 5px solid var(--blockquote-border-color);
  color: var(--blockquote-text-color);

  a {
    color: var(--blockquote-link-color);
  }

  &:has(cite a[href*="twitter"]) {
    --blockquote-background-color: #000000;
    --blockquote-border-color: rgb(29, 155, 240);
    --blockquote-text-color: #ffffff;
    --blockquote-link-color: rgb(29, 155, 240);
  }
}

And the result:

<blockquote> <p>"Make the common configurable and the uncommon composable"</p> <cite> — Adam Sedwick (<a href="https://twitter.com/AdamSedwick">@AdamSedwick</a>) —{" "} <a href="https://twitter.com/AdamSedwick/status/1592922558403604481"> Nov 16, 2022 </a> </cite> </blockquote>

<figure class="no-has-support"> <Picture class="blog-post__image" src={twitter} alt="Blockquote styled with twitter theming" /> <figcaption> At the time of publishing :has() is still behind a flag in firefox. Here is an image of the blockquote with :has() enabled. </figcaption> </figure>

Leveraging the same :has() selector we could create a theme to match any social network. Here's the same post thing as if from a mastodon instance:

&:has(cite a[href*="mastodon.social"]) {
  --blockquote-background-color: #282c37;
  --blockquote-border-color: #6364ff;
  --blockquote-text-color: #ffffff;
  --blockquote-link-color: #6364ff;
}

<blockquote> <p>"Make the common configurable and the uncommon composable"</p> <cite> — Adam Sedwick ( <a href="https://mastodon.social/@AdamSedwick">@AdamSedwick</a>) —{" "} <a href="https://mastodon.social/@AdamSedwick">Nov 16, 2022</a> </cite> </blockquote>

<figure class="no-has-support"> <Picture class="blog-post__image" src={mastodon} alt="Blockquote styled with mastodon theming" /> <figcaption> At the time of publishing :has() is still behind a flag in firefox. Here is an image of the blockquote with :has() enabled. </figcaption> </figure>

Sure, you could load up react, vue, or some other component-based system that accepts or sets a prop based on a passed value, but that's all additional overhead and ultimately more data sent over the wire.

I think it's pretty powerful that we can combine something like :has() with the attribute selector to be able to create custom styles based on the contents of an element in native web tech without any additional libraries.

Semantic HTML and Accessibility

Mon, 27 Nov 2023 16:00:00 GMT

What is Semantic HTML?

In programming, semantics refers to the meaning of a piece of code. HTML (Hypertext Markup Language) is the backbone of the web, it is ultimately what is rendered in a browser when someone visits a website.

Semantic HTML is the concept that markup should be coded to represent that data that an element contains and not just based on default presentation or styling. Presentation (how does this look) is the responsibility of CSS.

A simple example of semantic markup is the h1 element. You can style an h1 to appear however you want, but simply by using an h1 you are explicitly telling the browser that “this is first, and primary heading of this page.”

What Are The Benefits of Using Semantic HTML?

There is implicit meaning associated with semantic HTML elements. This means that by simply using semantic markup we can effectively describe the structure of a layout without additional markup.

Assistive technology can use the same implicit meaning of semantic elements as signposts and landmarks to help users navigate the web.

Semantic markup elements can assist developers in understanding the types of content that will be populated into them.

Some semantic elements have intrinsic interaction and event bindings reducing the need to write custom code to account for these interactions.

Understanding Semantic HTML By Creating A Custom Accessible Button

Take the simple HTML <button>element, at it’s simplest:

it is understood in markup to be an interactive element
it is announced to assistive technology as a button indicating that a user can interact with it
it can be clicked with a pointer device, or interacted with through the space or enter keys on a keyboard
it accepts a disabled attribute to prevent interaction and indicate that it is disabled
it has default visual styling that indicates default, hover, focus, and active states
it can be passed any other native html attributes such as an id or class

<button>Button</button>

The following example but does a good job of demonstrating why we should strive to use semantic elements.

const Button = (props) => {
  const { disabled } = props;
  const onClick = () => {
    if (!disabled) {
      console.log("Click!");
    }
  };
  const onKeyDown = (event) => {
    event.preventDefault();
    if (event.key === "Enter" || event.key === " ") {
      onClick();
    }
  };
  return (
    <div
      onClick={onClick}
      role="button"
      tabIndex={disabled ? "-1" : "0"}
      onKeyDown={onKeyDown}
      className={`button ${disabled ? "button--disabled" : ""}`}
      aria-disabled={disabled}
    >
      Delete
    </div>
  );
};

Neither one of these “button” elements does anything yet. This is the bare minimum required to get an interactive button onto the page. Not only does the semantic HTML button have significantly less code, it is easier to understand as a developer, and there is no concern about accounting for different interaction methods or states.

Breaking Down the Implicit Attributes

If we look at the “button” created with react code you can see multiple attributes need to be added to the generic <div> element:

onClick and the associated function is needed to handle pointer interaction
role is needed to indicate what the “role” of the element is to assistive technology
tabIndex is needed to allow the element to be accessed through the keyboard, however we need an additional conditional and property here to disallow this access if the button is supposed to be disabled.
onKeyDown similarly to onClick is needed along with the associated function to provide keyboard interactivity
className is needed to provide classes to the element in order to give provide any meaningful visual styles, since be default a div has none. Again we see the disabled prop is required here as well
aria-disabled is used to indicate to assistive technology that this element is disabled

All of these properties and attributes are provided “out of the box” with the natively semantic <button> element.

Final Thoughts

We’ll dig into what ARIA (Accessible Rich Internet Applications) is in another post, but there’s two great principles that can be used as checkpoints when considering how to code accessible applications using semantic HTML.

The first is known as “The first rule of ARIA”:

If you can use a native HTML element [HTML51] or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible**, then do so**.

This may seem pretty obvious, if something already exists natively as a part of the web platform use that. Anything that is provided as a part of the HTML spec has often already gone through rigorous testing to ensure that it is understood across all browsers, has any necessary interactions, labels, and identifiers by default, and will be understood by assistive technology.

The second is a common saying among accessibility professionals:

No ARIA is better than bad ARIA

The idea behind this is that often, even with the best of intentions, simply slapping aria attributes or roles on an element can cause more harm than good. If you’re creating a custom element and finding yourself needing to add a multitude of attributes or complex logic it might be a good idea to take a step back and evaluate if this is the best way to achieve the desired goal.

Shoutout to Syntax Highlighting

Sat, 21 Oct 2023 16:00:00 GMT

import { Picture } from "astro:assets"; import slidePreview from "@images/writing/syntax-shoutout/slide-preview.png"; import highlightExample from "@images/writing/syntax-shoutout/highlight-example.png";

Syntax highlighting is something I think most developers take for granted. Regardless of your chosen editor, language, or theme, we all have access to this incredibly powerful yet understated feature. Syntax highlighting makes it easy to skim and parse code, identifying the parts that are relevant to a task at a moments notice.

I’ve been working on a presentation this week for accessibility, as a part of this presentation I am displaying code snippets.

I am creating this presentation in Figma, as I do many presentations, but this is the first time I’ve opted to try and include live code over a screenshot.

There is no concept of “code” within the Figma design interface. There is no way to specify a language, or a theme with which to highlight. Because of this, I have had the pleasure of manually coloring the text to match the highlighting of my editor; it’s been a painstaking process.

One positive to this process would have to be my new appreciation for syntax highlighting. When pasting the code snippets into Figma everything within a text node is the same color.

It has been truly eye opening to compare the highlighted version to the monochrome version, whether through “muscle memory” or simply having unique colors differentiate the parts of code, it’s so much easier to read code that has been highlighted.

I don’t have some big point to make here, just wanted to share some love for a basic developer feature that may not always get its deserved time in the spotlight.

Starting a Digital Garden

Sat, 23 Sep 2023 16:00:00 GMT

This idea was inspired by a conversation at the end of the ShopTalk show Episode 583 with Maggie Appleton.

Maggie’s essay on the Digital Garden concept really struck a cord with me. The idea of being more open and flexible with what is considered “blog worthy” is interesting to me as I am trying to develop my writing skills and share thoughts more openly.

The essay also links out to a swyx post about learning in public which further reinforces the concept of openly sharing what you are learning and working on. This idea is often shared by other prolific bloggers and educators on the web, it’s fairly common to hear “Write about something you recently struggled with and how you solved it,” the idea being that there will inevitably be someone else who comes across this problem and your content may be able to help them.

As a part of this process I hope to update this site more frequently as well as adding additional “digital garden” features like bi-directional links, learning in public, and clear statuses of thoughts as well as exploring some IndieWeb features like WebMentions.

Uses and Now

Mon, 04 Dec 2023 16:00:00 GMT

Decided to jump on the /uses and /now bandwagons.

What the heck are `/uses` and `/now`?

From my own personal interpretations both of these ideas, pages, and products feel like they fall squarely into IndieWeb territory. They’re small ways you can share interesting information about yourself on your own site.

uses.tech is a project put together by Wes Bos for devs to share the tools, resources, etc. they use to do their job. From the contribution guide on github:

What's a Uses Page? A /uses page lists a developer's setup, gear, software, and configs (what they use). It's a great reference for those looking to add to their library of tools or reconfigure ones they already use.

What Should I Include? Include the hardware you use, such as your computer and other related equipment. Include your preferred terminal, text editors, tools, frameworks, and other related software you use. If you can, include configurations for software (such as fonts and themes). The more you have on your /uses page, the more interesting it'll be to those who view it - just keep it on-topic!

nownownow.com/ is a project started by Derek Sivers. A /now page is meant to be a big picture glimpse into the things you’re currently focused on. From the nownownow about page:

If I wonder how someone is doing these days, it doesn’t help me to see that they went on vacation last week, are upset about something in the news, or even got a new job. That’s not the big picture.

Think of what you’d tell a friend you hadn’t seen in a year.

Like, “Still living in Dallas, though considering moving to Austin. Working at ABC. Really getting into cycling. The kids are age 3 and 6. I’m reading a lot of Pema Chödrön, and listening to a lot of jazz piano especially Brad Mehldau. I’ve stopped taking on web design clients, since I’d rather keep improving my back-end database work.”

That’s what a now page is for.

Leveraging AI to Improve Accessibility

Sun, 24 Mar 2024 16:00:00 GMT

There’s been a lot of talk over the last few months about using AI to improve accessibility. I’ve seen and heard people talk about the potential for a browser or OS level AI to swoop in and solve “last-mile” accessibility issues for a user that a designer or developer has not considered or accounted for. Examples of this type of AI include:

A colorblind user asking AI to fix color contrast issues on a page e.g. “I’m red-green color blind, this site is usable, can you [AI] just fix the colors on this site/page for me?
AI using computer vision and/or context clues to provide alt text for images.
AI interpreting a web page and dynamically creating or pairing form elements with labels. If a label exists, but isn’t attached to an input properly AI could just add the proper name and id attributes, or if no label exists, understanding what the input is for and providing an appropriate label.

I think these are all incredible future possibilities, but I also would like to live in a world where we don’t put the onus on the end user to solve our shitty code.

Using AI as a Trojan Horse

One thing I haven’t seen a lot of discussion around is the fact that a lot of these AI tools; especially the new-to-market physical devices, are promising a lot of usability out of the box. Devices like the Rabbit R1 tout the ability to visit a website and place an order or book a plane ticket for you.

Rabbit R1

At CES this year the Rabbit R1 became a viral phenomenon, if you visit their website now they’re already sold through their fifth batch of preorders. If you’re not familiar with the device, the R1 is one of many new devices this year claiming to be AI assistants for your every day life. What set the R1 apart is what they call their LAM (Large Action Model).

Instead of a standard web-connected LLM like ChatGPT or Bard, which can search the web and return answers, this device is supposed to be able to take actions on your behalf. According to Rabbit, you’ll be able to use the R1 to order food or a ride share, translate conversations, take notes, or even research points of interest.

Again, I feel like the POUR principles of accessibility could be incredibly important here. In order for this device to navigate a website, especially something like a checkout flow, those pages need to be designed and built well, perhaps even more so than a human user.

Pushing for Accessibility with AI

In a time when many accessibility experts are getting burnt out and leaving due to the constant brick walls we’re running into, I can see these new technologies as something we could leverage to bring accessibility back into the fray as a critical practice for web design and development.

Businesses need to be looking at these AI tools as another potential revenue lane. They’re going to need to ensure the non-humans can use their products. Seems to me like we’ve got a perfectly good set of principles in Accessibility that are focused on making sure the widest range of use is possible within any interface or product.

Whether through computer vision or crawling the code, AI tools are going to benefit from well designed accessible sites and the use of semantic markup to build them. Getting buy in to ensure that interactions and experiences can be done by an AI can also lead to those experiences being better for users with assistive technology needs. AI doesn’t have a mouse, neither does someone who is navigating with a keyboard or a voice-based interface.

We’ve seen “AI Code Tools” produce all kinds of accessibility issues, and with a history of bad accessibility overlay products and companies it’s easy to see or hear about AI and become despondent about the future of accessibility on the web. I think, with this framing, we have the potential to use AI to our advantage and make the web a better place for everyone in the process.

Anfield Stadium Tour

Sun, 15 Sep 2024 16:00:00 GMT

One of the highlights of my recent UK trip was a special meet-and-greet and tour of Anfield Stadium. If you're a soccer fan (or football, as it's called in the UK), you might be familiar with Anfield. It's the home of Liverpool Football Club, currently second in the Premier League and overall just a fantastic club.

The event kicked off with a 45-minute meet-and-greet with an LFC "Legend." We were fortunate to speak with Jan Mølby, a midfielder who played for the team for 16 years. He shared insights about changes in the league and the game since his time, offering fascinating historical tidbits about the sport and team.

Following the meet-and-greet, we embarked on a guided tour of the stadium, delving deeper into the team's history. LFC's slogan, "You'll Never Walk Alone," has evolved significantly since becoming their signature in 1963. After a tragic incident in 1989 where 96 fans lost their lives in a human crush, the phrase became central to the team and community. It now serves as a poignant reminder that no one is alone, and that football is more than just a sport—it's a family.

The Box Model for Design

Fri, 08 Mar 2024 16:00:00 GMT

Everything on the web is structured using the box model. HTML elements (e.g., paragraphs, div blocks, sections, etc.) are expressed in boxes. By default browsers stack these elements vertically, like boxes on top of each other. Through the use of modern CSS features we can organize and position these boxes in a range of ways to achieve the diverse range of layouts on the web today.

What is the Box Model?

When we talk about the box model we're referring to the way in which the browser understands what an HTML element is. There are 4 major sections of the box model: content box, padding box, border box, and margin box. In order to understand the amount of space any element takes up on a web page the browser combines all of these values and computes the box that needs to be placed on the page.

Content Box

The Content Box is the area in which your content is displayed. This area can be sized using properties like inline-size and block-size, or width and height.

Padding Box

The Padding Box is created and calculated by taking the content box and applying additional white space around it. This is controlled using the padding properties.

Border Box

The Border Box wraps around the content and padding. The border properties are used to style this.

Margin Box

The Margin Box is the outermost layer of the box model, it wraps the content, padding, and border with additional white space. This property is often used to separate elements on a page. This is controlled using the margin properties.

What is `box-sizing: border-box`?

It's common to see some version of the * { box-sizing: border-box} style on websites these days.

The default styling mode for HTML elements is content-box. The content box does not take the padding or border of an element into account when sizing itself. Under the content-box model we need to manually account for padding and border when sizing an element.

<p class="aside"> Due to the nature of the web, and the desire to maintain backwards compatibility the default model used by elements is not likely to change any time soon. </p>

In an effort to resolve these issues, the “alternative box model” was coined. By setting the box-sizing attribute of an element to use border-box the padding and border are included in any specified dimensions (inline-size, block-size, width, or height).

The * selector is known as a “wildcard” selector, it will match all elements. This style forces all elements within a webpage to use the alternative model, behaving how most designers and developers have come to understand.

How the Web Uses Boxes

All HTML elements are expressed in boxes on the web. You can imagine an invisible boundary around each element, which contains that element within a box. You can style elements and create layouts using these invisible boxes; adding space within a box's bounds using padding, between elements using margin or gap, or add a visual border to an element's box. Depending on the layout style and CSS properties these boxes can sit next to or stack on top of one another.

Web layouts behave like a text document, where content flows naturally from the top-left of the page, then moves to the next line (i.e., wraps) when it hits the right-side boundary of the document. The content is responsive because the content conforms to different resolutions.

For instance, if you resize a text document window, the content layout will adjust accordingly, without decreasing the size of the content. Similarly, when resizing a browser window the content does not remain static and shrink or scale, it will adjust it's positioning based on how much available space there is before wrapping to the next “line”.

Nesting Boxes to Build Components and Layouts

A core principle to understand when it comes to web design and the box model is that boxes can nest inside other boxes. This allows designers and developers to place elements inside other elements in order to group, align, and style related content.

In the example above you can see an image, title, description, and button and their boxes nested inside another element's box in order to create a generic “card” style component.

Understanding Spacing Within and Around Boxes

By default, when the contents of a box increase, the size of the box increases too. That means there's usually no need to set defined heights on elements — instead, you can let the content determine the height. For instance, if you have a heading and paragraph element inside of a container element, the container's height is determined by the heading and paragraph elements.

You can also create spacing between elements and within elements with margin, padding, and gap.

Margin

Margin creates space outside of a box, pushing other boxes away from itself. Margin is most often used to create space between elements, it used to be a mainstay for layout design but has been replaced in many instances and layouts by the use of flexbox or grid along with the gap property.

There are multiple quirks with margin that come from the typesetting and document layout origins of the web such as margin collapsing. Josh Comeau has written an incredibly detailed deep-dive into margin collapse over on his website.

Padding

Padding creates space within a box, between the box's borders and contents. There are some scenarios where a desired effect may be achieve with padding in lieu of margin. If you want multiple elements to butt up next to each other, but do not want the content of those boxes to touch, you would use padding to add additional space between the edges of the box and the content areas.

Gap

Gap is a relatively newer property that must be used in conjunction with the flexbox or grid CSS layout styles.

Similarly to margin, gap creates space between elements. However, the gap property is set on a parent element and only applies between the child elements. If you have 3 elements in a row setting an inline margin on those elements will apply space to both the left and right sides of the elements, including the outside of the first and last element. Gap on the other hand, when set on the parent container will only create space in-between the 3 child elements, with no additional space on the outside of the first and last elements.

The Box Model in Figma

The auto layout settings within Figma expose some elements of the box model within the design tool space.

The auto layout direction feature is a pretty direct mapping to the flex-direction CSS property. Within a display: flex container this setting determines the direction in which elements of the parent stack, vertical or horizontal. The wrap feature is a reflection of the flex-wrap: wrap setting for horizontal flexbox elements.

The Horizontal Gap and Vertical Gap settings in this panel are similarly a direct mapping to the gap property within flex and grid containers in CSS. As shown in the example above, this gap property determines the space between elements, without affecting the spacing to the left/right or top/bottom.

Finally the Horizontal Padding and Vertical Padding options are, as their name suggests, representations of the padding property in CSS. When viewed in dev move Figma is using the shorthand padding property, but it's easy enough to understand that Horizontal Padding is padding-inline, and Vertical Padding is padding-block.

Borders in Auto Layout

Another feature of the auto layout system within Figma is the ability to determine whether strokes are included in the spacing calculations for your auto layout. This feature is a pretty good analog for visualizing and understanding how different box models calculate spacing.

By default in Figma strokes are not included when accounting for the size calculations of objects. From Figma's own docs:

By default, strokes aren’t accounted for when calculating the size of objects, and thus don’t affect their parent frame or surrounding siblings.

This may not be ideal during developer handoff, as it doesn’t accurately represent how CSS renders borders.

In the image below you can see how the 16 pixels of spacing overflows and sits on top of the border.

By contrast, in the next image you can see how the 16 pixels of space is calculated inside the borders. This is because the borders are being included in the width calculation. This operates similarly to the border-box model mentioned above.

Beyond the Basics

In this introduction we've explored the basics of what the box model is, how we can use boxes to construct interfaces and components, and a representation of one model within Figma.

We briefly touched on the concepts of Margin, Padding, Gap, and different layout models like flexbox and grid, I encourage you to learn more about these CSS layout properties as they're the foundational tools we use to construct page layouts. Understanding more about how interfaces come together can highlight potential challenges to something that may appear easy in a design tool, or bring to light new and interesting ways to explore in design.

Design on the web has always been incredibly unique and diverse, and as we gain new features and tools for creating layouts and interfaces it becomes increasingly important to understand the underlying principles and technologies that power it. Hopefully this article helps you understand a little bit more about what the box model is and how we use it to build the web.

It's Autism Acceptance Month

Sun, 07 Apr 2024 16:00:00 GMT

import PostLink from "@components/PostLink.astro";

In case you didn't know, April is Autism Acceptance Month. In this month we take time to recognize and celebrate the unique qualities and differences that make all of us who we are. No two humans are the same, and rather than look as those differences as things that set us apart from each other, I like to look at this month as a time to highlight those differences as things that can help bring us together.

In honor of this month I want to help spread the reach of Ellie Middleton's TEDx talk about her experience with her Autism Diagnosis. This is an experience that is all to familiar for many individuals with a late diagnosis.

If you or someone you know is neurodivergent, I encourage you to listen to and share these stories. The more we talk about these experiences and bring them into the light the more we encourage others to do the same.

How To Center a Div

Tue, 20 Feb 2024 16:00:00 GMT

import PostLink from "@components/PostLink.astro";

Josh's tutorials are always a joy to read and interact with. Even as someone who is familiar with all of these methods Josh provides such an in-depth and details analysis, with incredible examples.

For a long time, centering an element within its parent was a surprisingly tricky thing to do. As CSS has evolved, we've been granted more and more tools we can use to solve this problem. These days, we're spoiled for choice!

Chasing the Spark: ADHD, Burnout, and Guilt

Sun, 20 Oct 2024 16:00:00 GMT

It’s been roughly 4 weeks since my last post, not great for my “1 post a week” goal. Rather than pretending like it didn’t happen, I thought this would be a good opportunity to share what it’s like to live with ADHD and some of the troubles that come with it.

The ADHD Superpower

I’ve never been one to use my neurotype as an excuse, even before my official diagnosis, I’d known my brain was different. I truly believe I am successful; not in spite of my brain, but because of it. I can quickly and easily recognize patterns, and I’m always looking for ways to improve upon processes. Understanding complex systems; how one small change in a chain would affect something down the line, came naturally to me even at a young age.

I often hear this type of ability and the phenomenon known as ADHD “hyperfocus” referred to as superpowers. While they can be beneficial when properly wielded (or when the stars align), if you ask someone who actually has ADHD, they’re not always thrilled. More often than not, we don’t get to choose our hyper-fixations, when they arise, or when they’ll mysteriously disappear, leaving behind a void of motivation and purpose.

Sure, on a particularly good brain day I may be able to do a week or more’s worth of work in a single day if left uninterrupted, but the downside it that also likely means I’ve completely ignored my body. At the end of the day it’s unlikely I’ve eaten anything, and all too common to have the same cup full of untouched water in front if me. I’ve also likely sunken into my chair in some gremlin position and when I’ve awoken from the ADHD trance my body will be in incredible pain.

I’m lucky to have ended up in a career where I’m presented with interesting and unique challenges and opportunities that help keep my brain engaged and interested. The downside is that when a particular project or problem is long running or requires intense levels of focus and coordination over an extended period, it can become a hyper-fixation, causing me to want to pour all of my time and energy into it. This leads to a cycle of intense productivity followed by an equally intense period of burnout as the project winds down and there’s a lull in the thrill of deadlines and pressure to perform.

From Blazing to Burning Out

Burn out is different for everyone, and it can also vary within individuals depending on the cause. I’ve had periods of burnout so bad that even the motivation to get out of bed doesn’t exist, little is interesting, and nothing feels worth doing. Thankfully over the years I’ve found ways to identify the signs of burnout begging to set in, and can mitigate the damage before it takes hold.

These days it tends to look more like decreased productivity, both personally and professionally, and a retreat into dopamine rich media consumption; preferring mindless scrolling or video games, over reading or listening to a mentally engaging podcast.

Using the spoon theory metaphor I may find that a daily supply of 10-12 spoons can shrink to only 5 or 6. Because I like having a job, and I have a family to support that means most of my mental energy gets dedicated to work, even though productivity may drop some, I need to spend most of my available capacity on work tasks. By the time work is over, I may be down to only one or two spoons for the rest of the evening; having to choose between making and eating dinner, playing with my toddler, or helping maintain the house becomes a difficult, and guilt inducing decision.

Habits, Overwhelm, Task Avoidance, and Guilt

Many ADHDers talk about how they can’t form habits, not that it’s hard, or that they’re unwilling to work at it, or even that they can’t stick to doing something; but rather that it never really becomes “automatic” they way neurotypical people describe them. Almost everything I do, I’m consciously aware of, I don’t think I’ve ever woken up, brushed my teeth, and taken a shower on “autopilot.” For me it’s a series of steps, “convince myself to get out of bed, walk to bathroom, turn on sink, wet toothbrush, put on toothpaste, brush (make sure you’re counting!), spit, rinse, wash.” From there it’s another similar sequence of steps to shower, get dressed, or do just about anything; and if somewhere in the chain something goes wrong, well then the whole task is off the rails. If my toothpaste isn’t where it’s supposed to be, I may end up changing a lightbulb and forgetting to brush my teeth because I got sidetracked by a flicker looking for the dang toothpaste.

I bring this up because of it’s relevance to my posts. I managed to go an entire year, 52 weeks of writing a post a week, if a habit was going to form, surely that was enough time. Lo and behold, Helene impacts the southwest US where we have friends and family and I spend a weekend communicating and coordinating rather than writing. You think I’d be able to just pick it right back up and either post late or just skip a week, but because I’ve had a break in the pattern everything gets thrown out the window.

In my mind, because I missed a week I’ve now got to write two posts. This is not an expectation placed upon me by others, but something my brain has convinced itself of. Now I’m stressed and overwhelmed trying to think of what to write, and how I’m going to put out two posts. The brain gremlins begin their scheming and now I’ve got voices of disappointment swirling in my head because I failed to meet some completely made up and arbitrary goal.

This is where task avoidance comes into play. The internal monologue turns from disappointment to apathy, “Well, I’ve failed, so what’s the point in trying now. Might as well just stop.” This fights with the other parts of my brain that are concerned with the commitment I made to myself, and the fact that the entire point of setting personal goals is to try to improve and achieve something. Now there’s an unrelenting guilt building inside because I told myself I would do this, and there’s no reason I should stop. “It’s not that hard, just sit down and write. You do this all the time, just write.”

Task avoidance and Task paralysis are often seen externally as a lack of motivation or discipline. I can tell you first hand, there is nothing else I am focused on than the task I am unable to do. The internal voices of shame, anger and guilt at my inability to do seemingly simple tasks, especially if I’ve done them before.

Just Start Moving

Something I’ve found that often helps when I finally realize I’m in one of these ruts is to “make a deal” with myself. Sure it sounds childish and silly, but “lets just clean for 5 minutes,” can often turn into a completed task, because once I’ve started a task, it turns out it might not be that big of a challenge and after 5 minutes I’m either almost done, or I’ve found some motivation to keep going, even if only for a few more minutes, it’s more progress than if I’d done nothing.

I used to laugh at the corny quote painted in the foyer of my high school, “Shoot for the moon, even if you miss you’ll land among the stars.” As I’ve grown, listened to mentors, and mentored others myself, I find that while corny, there’s a great message hidden in there. When you set goals for yourself, even if you don’t achieve a perfect 100% outcome, you’ve still improved, you still made progress, and can now either try again, or push for even farther goals now.

A great example of this is people who do marathons; sure, you might not run your entire first marathon, you might need a break, but you still completed a freaking marathon, that’s 26.2 miles more than someone sitting on their couch. Next time maybe you’ll run for longer; or even the whole thing, maybe you’ll run 2 marathons next year.

Perfection is the enemy of progress. As long as we keep trying, even if we stumble, we improve; and for me, that’s something to be proud of.

Chasing Two Rabbits

Sun, 09 Jun 2024 16:00:00 GMT

A Swiss Army Knife is undoubtedly a useful tool, so much so that it has become the “go-to” item when referring to a product that can “do anything” or solve many needs. However, when we closely examine a Swiss Army Knife, it also becomes clear that none of the included items are a “best in class” for the intended purpose.

The classic Swiss Army Knife comes with 7 functions: Blade (small), Scissors, Key Ring, Tweezers, Toothpick, Nail File, Screwdriver (2.5mm).

It’s certainly something that is worth throwing on your keys or into a pocket or bag if you want a light general use tool “just in case,” but depending on the use-case or need, are the tradeoffs worth it? If you need a larger knife are you at a disadvantage because you chose this product? The screwdriver likely works in a pinch, but it’s an arduous task that is clearly better completed by another option.

When we’re developing products it’s easy to fall into a pattern of Swiss Army Knife style decisions. It’s likely that a smart person will come along with a smart idea for our products. It’s easy to say “Yes!” when smart people bring smart ideas. The problem is that we also likely work with multiple smart people, who each may have their own ideas; eventually a consistent pattern of “Yes!” answers will mean that we wake up one day having no idea what our product does or who it’s for.

Do More by Doing Less

As counter-intuitive as it might seem up front, I have found that it’s often much easier to do more when doing less. Instead of agreeing to every smart idea or adopting each new proposal that comes our way, we need to maintain a steady focus on our product and teams mission and goals, even when that means not pursuing an interesting or exciting new idea or technology.

Many newer fitness trackers have been ditching their screens. The Whoop tracker has an entire page on their site dedicated to what makes it different. The CEO even did an interview discussing why they intentionally chose not to pursue a screen. “Once you have a screen you tell the time, once you tell the time you’re a watch.” Regardless of your feelings on the device or their philosophy, by ditching the screen and focusing on the actual health monitoring aspects of the device they have been able to intensely dedicate all of their resources to their goal to be a “best-in-class” health monitoring device.

When working on a product, the best thing I think a team can do is to really understand and continually reinforce themselves towards their goals, towards their desired outcomes. Whenever a new idea comes up, or someone suggests a new feature or function, bring the team together and evaluate that idea against your outcomes. Is it going to help achieve the outcome? Is it going to help move the needle for your users and your business? If you can’t confidently answer yes to those questions you can’t say yes to the idea. This is not an indication of a bad idea, but rather a reaffirmation and rededication to and from your team, that in order to provide the best product to your users and the business you need to stay focused on what you’re doing now.

Good Product, Great Product

There are a lot of good products in the world, I’d even be willing to generously claim most products are good. Good products don’t win customers for life, good products don’t pull customers away from other good (or great) products. Adding more good features to a good product does not make it great, and often times can end up having a net negative effect if the feature is more additive than improvement.

The “AI” boom of the last year or so is the perfect example of this concept. There are a multitude of companies and product slapping “AI” onto the product whether it needs to be there or not. I don’t need ChatGPT on a bicycle for example. Other products might make more sense, a device for cooking that uses “AI” or machine learning to adapt and learn how I like to cook is a more logical and deeply integrated solution to a potential problem. Similarly, something like a recipe book application that can learn what recipes I like and recommend similar items or a weekly menu based on my catalog sounds fantastic.

The main difference between between these ideas is how they consider and integrate the new technology into their mission and goals. An “AI” bicycle screams “we added AI for VC money,” there is not a clear advantage over any other bicycle when the goal of a bike is to exercise or commute. Meanwhile my fictional recipe book proposes a real solution to a common user need within the same space. It involves the product team knowing what the goal of their customers is, and creating a feature that adds meaningful value to them. This is what makes a great product.

If you want to create lasting meaningful products, dig in and dedicate your time, energy, and focus to a narrow set of goals. Clearly identify what is most important to your users and relentlessly filter out anything that does not move you towards those goals. As the proverb goes: “If you chase two rabbits, you will not catch either one.”

Config 2024 Day One

Wed, 26 Jun 2024 16:00:00 GMT

Figma started off the day strong with their opening keynote. UI3 looks like a fresh take on the editor interface, and aims to solve a number of existing issues, from small improvements to massive overhauls that needed a refresh to tackle. The improvements to dev mode are a welcome addition given my previous complaints about it not feeling worth the price, code connect coming out of beta is a huge plus. The AI features announced are numerous and varied, from a visual and extra fuzzy “find similar”, to the ability to generate entire design explorations based on a prompt. Just like any good product demo, they ended with a riff on the “one more thing,” for Figma it’s a new product called Slides. I tweeted about the fact that the crowd was collectively more vocally excited for this feature than anything else in the keynote.

Wishlist Review

So how many items on my wishlist did we get? Quite a few actually!

Variables

There wasn’t much talk about additional variables or support, but given the type support is relatively new, and all of the other changes, this is not all that surprising.

Auto Layout

Massive changes and additions for Auto Layout! While the functionality is not changing all that much, the reorganization of information and settings as a part of UI3 is a welcome change that I see helping a lot of designers understand and use the feature more. Additionally, as part of UI3 and the new AI functionality there’s a new option called “Suggest Auto Layout.” What this does is Figma analyzes the contents and layout of your component or frame, and generates nested frames on the fly in the position and order required to achieve the existing layout as an auto layout.

Without getting to play with it yet, I am beyond excited for the updates to auto layout and look forward to getting my hands dirty seeing how far I can push the suggestions and how this ability is going to speed up our teams.

More Dev Mode

Another massive win for the wishlist. Between updates in UI3, and a whole sweet of new features, dev mode is coming into 2024 with a strong argument for the cost and it’s place in the product development process.

Figma iterated on the “Ready for Dev” feature, by addition additional states that identify when something previously marked as ready has had changes, and a new interface to indicate what those changes are when re-marking as ready.

The big changes come in when the dev themselves come into the file. Their new focused mode means developers no longer have to worry about navigating or understanding a complex Figma file, everything they need is surfaced in a lightweight and clean interface. The addition of the “Mark as complete” functionality means that this system can and should be integrated into the traditional “handoff” and “review” process. When a developer completes their work they can mark the change in Figma as complete, and The designer can review those changes against the section.

Rounding out dev mode, Code Connect is out of beta and it’s value prop and path to provide developers with actual system code that your team has written, with matching and aligned props is a clear value add. The component explorer combined with this looks like it could be a potential replacement or competitor for basic implementations of storybook or other dev tools. If you just want to be able to see how a component is going to look and change when you change prop values, that’s not possible through Figma Dev Mode and Code Connect.

Enhanced Documentation Support and “Design Clippy”

Lumping these two together as I feel like they both got mostly answered by the AI releases today.

My wishlist item for enhanced documentation was centered mainly around the ability to provide documentation at “point-of-use” for designers, while we didn’t get exactly that, the visual and “extra” fuzzy search enhancements are a step in this direction. Whether drawing an icon or asking Figma “where is this interface?” And having it spit out exactly what you were looking for a a huge win for ease-of-use, and exactly what I described in the first part of my “Design Clippy” item: “If a designer isn’t sure what the exact name they’re looking for is this sort of ‘helper’ could provide suggestions.”

The second half of my Design Clippy was also admittedly a bit of a softball, creating a feature to allow Figma to automatically generate explorations seemed like a no-brainer to include if they were going to invest in generative AI. I do appreciate Dylan pointing out that these explorations are likely the most basic and common solutions, given that the models in use were trained on the most basic and generic data. Only time will tell if teams allow Figma to train on their designs, and how effective this feature is in the long-term.

First-Class Responsive Support and Responsive Typography

One of the new features showed off as part of the UI3 demo was a responsive prototype viewer! This was awesome to see, and is absolutely a step in the right direction for enhanced responsive support. I’d still like to see more features come to components in terms of responsive behaviors or breakpoint-style controls. The responsive prototype viewer did ring a little hollow knowing that one of my other major asks was responsive type. Maybe some day in the future, but for now responsive type is still missing. This means that we can now design and wire up fully interactive, responsive prototypes, but if your design system or development teams are using fluid type scales, you’re still going to be unable to replicate that functionality.

Inline Elements, and Less Paywalls

Nothing explicit about changes to how text or inline elements behave, but I’ll have to explore how things work and are laid out in UI3 to see if there may have been some small enhancements that weren’t announced.

As for less paywalls, we got even more!

Figma’s newest addition to their software is called Slides, It’s a full-blown presentation tool. Myself along with a significant portion of the keynote audience is incredibly exited for this. Now we can create, edit, reorganize, and present with notes all from within Figma. It’s free for the remainder of 2024, and then is moving to a pricing of $5/seat/month for org and enterprise teams.

All of the AI features are incredibly new, and Figma is unsure of cost, or level of usage for these tools, so for now that is also going to be free, but they’ve stated they’ll be watching usage and cost data, and are likely to put out a pricing model for these features next year.

Overall, while I don’t love seeing things put behind paywalls, at least the pricing and value of the different products seem to be much closer aligned. Dev mode is looking to provide massive value for teams, Figjam is still a simple collaborative whiteboard, and Slides is the Keynote/Powerpoint killer I think a lot of designers have been wanting. If we’re going to have to pay more, at least the product are delivering on that cost.

Presentations, People, and Pubs

I only ended up catching 2 sessions outside of the opening and closing keynotes in person.

Building and the Craft of Figma started with a talk by KC Oh, Ryhan Hassan, and Joel Miller where they dove into the changes, updates, and work behind the UI3 redesign. It was great to hear them talk about the challenges, explorations, and ultimate path to launch for such a major change. With a through line of “Try the hard thing,” I think there’s a number of lessons many product teams could take away.

Showcasing skills like product discovery, idea validation, and market viability analysis, Saron Yitbarek made a clear and simple argument for developers to slow down before diving into the work of building in her talk Should Developers Design. Too often developers jump right into building, spending time thinking about or debating frameworks, tech stacks, deployment strategies, etc. before we know if the thing we’re so excited to build is even worth building.

I ended up meeting 5 coworkers in person for the first time, most of these people I’v been working with for the better part of 5 years. I also managed to chat with Jina and Adekunle from the Design Token Community Group for a bit, always great chatting about design tokens. Got a photo with Jason Lengstorf, and spoke with many others in the hallways, lines, and in passing.

Wrapping up the day, I hung out with Chris, Jina, and many other Design System professionals at the Clarity/Knapsack happy hour event. Got to share and hear stories from some amazing folks including representations from the Wayfair and REI (Cedar) Design system teams.

Closing Out

Day one of Config 2024 definitely didn’t disappoint. Looking forward to arriving early tomorrow to get some shopping in and customize by bag before diving in to multiple sessions on design systems and running teams.

If you see me say hi! Happy Config.

Config 2024 Day Two

Sun, 30 Jun 2024 16:00:00 GMT

Starting off day two strong, I was lucky enough to get upgraded access to the leadership collective, massive thanks to our Figma rep for pulling in that favor.

Opening Keynote

Leaving Fingerprints

Karla and Nash kicked off the talks with Leaving fingerprints: product, design & stories at The Browser Company. The talk was full of inspirational stories of creating unique products and telling the story that scares you the most. They encouraged us to look outside of technology, and remember that when we set out to make great products we’re setting out to tell stories, real, vulnerable, and human stories.

Shitty Robots

Closing out the opening ceremony was Simone Giertz with Why shitty robots are the antidote of perfectionism. I’ve been an avid follower of Simone through her YouTube for years. Getting to see her on stage was great, and the take aways from her talk felt incredibly valuable, even if you had no idea who she was prior.

Session 1: Leadership Collective

During the short break between the opening ceremony and the first set of sessions I was able to catch up with and grab a picture with Miggi from Figgi!

Rituals to Unbreak Planning

Originally I was planning on attending Scaling Up Design Systems, but I’ll have to settle for the recording of Nate Baldwin’s opinions. Because the leadership collective offers an additional track, I thought my time would be better spent at this talk by Sashir Mehrota and Yuhki Yamashita. At last year’s config they gave a talk that I loved called Rituals of Modern Product Teams.

This year they decided to move onto the next step in the process and focus on planning, something that in their opinion is largely broken across the industry. As they put it “Planning algorithms today produce winners and losers, resulting in an unproductive zero-sum game.”

Sashir and Yuhki go deep into how they think we can all improve planning, providing a few new techniques, as well as a critical look at the reality of planning activities, even going so far as to suggest that ideally only 10% of our time should be spent on planning each quarter.

One important takeaway I want to bring back to the teams I work with is to remember that exhaustive planning is exhausting, and often well beyond what needs to be done in reality. Another being the YouTube Hoodie Squad mindset, which helps reinforce the idea that we should strive for individuals only being dedicated to a single team, and those who are on multiple teams are an exception that we should work to reduce or eliminate as much as possible.

Session 3: Building (your own) PM Principles

I wasn’t really sure what to expect going into this session. Having been moonlighting as a PM for the last few years I have a decent understanding of what goes into the job, and was curious to hear others’ takes on the role.

Hard Truths About the Future of Product Management

I didn’t really jive with the first talk Hard Truths About the Future of Product Management by Claire Vo, it felt like a weird tacit admission of the fact that corporate America has decided not to promote younger people into more senior roles, and that we should all just accept that fact and become “Super ICs.” The entire talk came off as the old advice of “take on more to get ahead,” never mind the fact that the corporate climate for the last decade or so has often proven that all taking on more results in is frustration and burnout.

I’m all for pushing yourself to get better at your job, hell I’ve become a full-stack product polyglot, I studied front-end and design in school, learned enough back-end code to understand and explore personal projects, and then learned product management on-the-job because we needed someone to do it, and I had already started doing half of the work because that’s what a good leader does. However, I’d never tell someone that they needed to do that, or that they should be expected to do or know all those things in order to be a product manager.

The fact that a significant portion of the audience was Gen Z individuals who are likely in their first or second corporate jobs made for a rather interesting set of conversations during and after the talk. I have a feeling the term “Super IC” is quickly going to become meme material among the more cyclical audience members.

Turning Ambiguity into Clarity

The second talk of the session, Turning Ambiguity into Clarity: Learnings and Principles by Lane Patrick Shackleton on the other hand, had a much more positive and practical vibe.

As a long-time listener of the ShopTalk Show, the first principle Lane presented: “Learn by making, not Talking” is right up there with “Just Build Websites.” It’s advice I’ve long followed and have applied in many places in my career and personal life. The only way to get better at something is to be bad at it first. Sure you can read a book or watch a YouTube video, but until you actually try whatever it is you’re trying to learn, you’ll never build the skills to complete the job. I can’t remember the exact quote, but it goes something like “Being really bad as something is the first step to not being really bad at something.”

His second principle: “Create cathedrals, not bricks,” is great advice for anyone who is looking to inspire people into action, not just PMs or someone in a management position. The idea here is that you need to show your team what they’re really working on; show everyone the vision, and inspire them to achieve that vision. You don’t build a beautiful cathedral by having someone create bricks, someone else put those bricks into a bucket, someone else carry that bucket, and someone else build a wall. They’ll likely wind up building a decent structure, but unless everyone is bought in to the vision at every step of the process, you’re unlikely to build Notre Dame.

The final principle: “Create systems, not just goals,” implores us to take action towards our successes. Goals are great, but as Lane points out in his talk:

You don’t rise to the level of your goals, you fall to the level of your systems

Rather than setting goals and hoping that you achieve them, set up systems that reinforce the behavior that moves you towards that goal. A personal example would be my goal to write at least 1 blog post a week. Rather than just hoping that happens, I set aside a little bit of time a few days a week to write, sometimes writing is easy and the posts come naturally, other times Sunday rolls around and I have to fall back to another system where I force myself to write a post before I am allowed any “R&R” style activities.

Session 4: Beyond the Hype: A Critical Look at Design Systems

The Broken Promises of Design Systems

Cam Worboys from Cash App kicked off this session with a cutting analysis of what design systems are, what they’re not, and some false promises or mistakes we may have made along the way.

We (Design Systems) can’t prevent bad [design] decisions.

At the end of the day, no matter how much time, effort, or pure willpower we pour into our design systems, if someone wants to make a bad design decision they will. You can easily make boring or uninspired pages and layouts exclusively using components and patterns from the design system. Simply using the system is not enough to avoid this issue.

Speed should not come at the cost of great ideas
Strive for consistency without commodification
Give teams the recipe not just the ingredients

I particularly like this framing because it reminds us that while a design system is a great multiplier, if the ideas, behaviors, or patterns it’s multiplying are not beneficial, you’ll quickly find yourself with roadblocks, confusion, and abandonment of adoptions.

Avoiding the Design Systems Values Oasis

Wrapping up the talks of day two Diana Mounter and Neha Batra from GitHub’s Primer team spoke on how teams can evolve and adapt to Avoid the Values Oasis. They opened with a story about the initial build and success of the Primer system, which was followed up by the pandemic we all know and love, causing their team to see cuts and an unknown future. Diana worked hard to set up a new partnership with Neha to ensure the ongoing success of their teams. The closing lessons from their talk struck a chord with me around building resilient teams:

Build teams that will last when you’re gone, and are resilient to change
Make connections across organizational lines
Don’t lose the goodness from before

Closing out

Excitedly I was able to find Dan Mall before the closing ceremony, having read through and implemented many part of both versions of Design System in 90 Days, and looking forward to his new book, Dan was definitely someone I wanted to be able to meet and shake hands with.

I ended up cutting out early due to a bit of a headache and the undeniable signs from my lower body that I need to get out and walk more. Still, I had an amazing time, the people I got to meet, conversations had with friend and stranger alike, and amazing talks, so many in fact, that I’m sure I’ll be spending a good chunk of next week watching recordings.

Thanks to everyone who said hi or started up a conversation. Huge thanks to Figma for putting the event on, and to Discovery Education for allowing and encouraging members of our team to attend.

Config 2024 Wishlist

Sat, 22 Jun 2024 16:00:00 GMT

With Config 2024 right around the corner I figured I’d put together a little wishlist of things I’d like to see them announce, some more plausible than others.

The Likely

More Variable Support

The most likely thing on this wishlist is additional advancements of Figma Variables. As a member of the Design Token Community Group, I’d love to see them adopt a broader set of tokens and use-cases, as well as adopting the term Token, instead of continuing to call them variables.

Additional Auto Layout Changes

I’m not completely sure what this would or even could look like, but some additional changes or enhancements to the auto layout system seems likely. Auto Layout is the closest thing we have to true flexbox in a design program that is not using direct web features. I’d like to see some enhancements for auto layout to also provide a “grid-like” experience. CSS Grid has been available and adopted in browsers long enough that having a tool that allows for grid-like layouts and behavior would be a huge benefit to design and development teams.

More Dev Mode

Again, not sure what this would end up looking like, but since locking down dev mode behind a paid seat last year, I feel like there needs to be enhancements and additions to this functionality that make the paid seat worth it. We’ll likely see some tie-ins with “AI” functionality here.

For me, from a design systems lens, I’d like to see a broader native system for aligning coded components with settings in Figma. If I can create and maintain the relationships between props in a coded component, and the props and settings in a Figma component it would be great if dev mode could just show the coded component’s code with all of the correct settings and props to enable a simple copy/paste of that snippet. Taking this a step further, if I have multiple languages or frameworks, provide my developers with a dropdown that can swap them between those specific snippets.

Less Likely Bets

Enhanced Documentation Support

Currently within Figma components you can provide a description for how to use a component. You can also link a component to external documentation through dev mode functionality. I could see a function or feature that uses an “AI” or ML model to combine or enhance these features. Providing “point-of-use” guidance or documentation for a designer without needing to open another window or app in order to access this information

Design Clippy

Don’t get me wrong, I don’t think anyone actually misses Clippy, but some kind of “AI” assistant that could help a designer get their work done sounds cool. It may even just be a deeper integration with a specific set of features within Figma. The search function for components already checks the name and description of components. If a designer isn’t sure what the exact name of something they’re looking for is this sort of “helper” could provide suggestions.

Alternatively, one of the biggest challenges in design remains the time it takes for a human to generate multiple explorations of an idea, something computers are amazing at. If I could prompt an “AI” design assistant to provide 10+ iterations on an idea or even a concept I’ve already produced this could save time. Obviously a human designer would still need to review and vet these explorations, but that likely takes less time than producing those explorations by hand. I’m all-in on anything that enhances a product team’s ability to explore more broadly, while also taking less time.

The Long Shots

First-Class Responsive Support

One of the few major drawbacks that still exist when designing with Figma today is that by its very nature the design and elements are still static.

While we’ve gained the ability to use the tools and mental models of component-based designs, at the end of the day, you still need to understand that Figma is a static snapshot of what a design will end up looking like on a production site or app. Components still need to provide “breakpoint” style sizes or variants if the shape or contents change when a viewport size does, this in turn forces a designer to design multiple “screens” using static frames and component variants.

I’d love a world where library or component designers could define styles using breakpoints or other modern responsive methods and have those components simply “do” that behavior when placed in a design at a specific size. We’ve got parts of this model in Figma already, using the auto layout fill property along with min and max width settings we can state the upper and lower bounds of an element. The next logical step for me, would be to allow me to define points where this component could natively change, even if it’s just swapping between variants.

Responsive Typography

Much like the full-blown support above, I’d love to see responsive type make its way into Figma. When looking at modern methods for creating fluid responsive type stacks the inability to replicate this pattern in Figma feels like a major drawback.

A single look at a tool like utopia.fyi makes it clear that a single static value no longer meets the needs of modern typesetting. If my system and development teams have adopted a fluid type scale how am I supposed to represent that within a tool like Figma? Should I pick the biggest size? What if our designers are not designing at the largest possible screen size? Then their designs will not match. Sure, we could specify multiple type styles that indicate different size viewport “snapshots,” but that feels like it could turn into a usability nightmare if our designers are now being asked to filter through a massive list of styles.

Giving designers and teams the ability to define these fluid type scales and having them act appropriately within a design seems like a much better option. Simply set the text element to fill and have the font increase or decrease in size based on the width of that fill.

Enhanced Inline-Element Functionality

With the caveat that I have no knowledge on the underlying functionality of how Figma works, I’d like to see some improvements around laying out and working with inline elements. Due to the nature of elements in Figma all being boxes, it can be hard to work with inline-style elements.

Placing design elements like a footnote indicator, or a “read more” link inline or inside of a text element often requires abandoning the functionality of auto layout. Likewise, modifying a single word or line of text within a larger text-block requires breaking any existing test style that may be applied. While this may be an edge-case, designers may choose not to use text styles if they can’t modify individual nodes within the text element that may require bold or italic styling.

On the web, we can wrap those individual nodes with a span, strong, or em tag to apply those styles without abandoning the larger parent styling, or losing the inline nature of those elements. Something similar would be great to see when it comes to laying out type in Figma.

Less Functionality Locked Behind Paywalls

From a business standpoint, this is probably the least likely on the list to happen, but as things currently stand, I feel like it needs to shift at least a little.

Dev mode is great, and if they want to push more advanced features of this mode I’m okay with a paid seat to access those features, but Figma removed a lot of what I’d consider to be “basic” developer features from view mode in order to entice companions and teams to purchase dev seats. I feel like in the long run this has, and is likely to continue to hurt teams who don’t want to, or can’t pay for those developer seats.

I spoke about this last year with Chris Strahl when I was on Knapsacks Design Systems Podcast, but the arbitrary limit of 4 modes for Figma Variables is another thing I’d like to see adjusted. This issue is compounded to me by the fact that the only way to get around this limit is Figma’s top-of-the-line Enterprise plan. Figma continues to showcase amazing things that can be done with their variables functionality, but unfortunately for you if you need more than 4 modes, better get on the phone with your IT or Finance departments, because there’s a massive jump in price to access this feature. Not to mention the fact that access to the REST API is also locked behind this same enterprise wall.

If we want designers and developers to work closer together, and as a community we’re pushing for teams to use this sort of functionality, this steep restriction flies in the face of that ability. Figma has already been able to help teams work better together, restricting these tools, processes, and functionality from teams who can’t foot the enterprise bill feels like a mistake.

I’m looking forward to everything being presented as well as getting to hang out with some other community members in person. I’ll also be attending the Knapsack/Clarity event on Wednesday. If you see me there please say hi!

CSS Architecture Archeology

Sun, 25 Aug 2024 16:00:00 GMT

In web development, one of the most crucial aspects of creating efficient and maintainable CSS is the ability to reduce code duplication and establish a reliable system of reuse. This approach not only streamlines the development process but also enhances the overall performance and scalability of web projects. Thoughtful CSS architecture strategies can create a more organized and flexible codebase that allows for easier maintenance and faster iterations.

In this post, I reflect on some of the CSS architectures that have influenced my approach to structuring and reasoning about CSS, exploring their strengths, limitations, and impact on my web design practices.

Starting with SMACSS

Back in 2011 Jonathan Snook wrote a book about Scalable and Modular Architecture for CSS (SMACCS). I was immediately drawn to this concept, and my teams ended up implementing it across all of our projects at the company I was at, it proved a means to think about the architecture of CSS in a way that worked with, and built on top of the cascade.

Ethan’s industry-changing Responsive Web Design had only been published a year or so prior, and SMACSS provided a lens to look at web pages as a structural layout that gets populated by modules (we call these components today). This approach to organizing and thinking about front-end code as reusable modules was a major step towards creating more robust reusable systems.

Moving to and Using BEM

While I can’t pinpoint exactly when I was introduced to or started using BEM, I have been using it for the better part of a decade. BEM (Block, Element, Modifier) is a naming convention for CSS that quickly saw adoption among many teams in the 2010s because it provided a meaningful and robust means to think about the relationship between elements, and how we named them.

The core idea behind BEM was the relationship between the three parts of it’s name, the block, element, and modifier. A block is a standalone entity that is meaningful on it’s own, some examples are header, navigation, or menu. An element differs from a block in that it does not have any meaning by itself, and is directly related to the block it is a part of, a menu item for example. Finally a modifier is a flag on a block or element that indicated how it is different than the base configuration or style.

BEM allowed teams to quickly and easily understand and reason about the architecture of their components, you’d be able to see at a glance how and when sections of code related to each other, and what was unique about them. A block would simply be a class name, where an element would need to follow the block class with a double underscore indicating it’s relation to the block, something like card and card__description.

Common issues with BEM

While BEM was undoubtedly helpful it also suffered from a number of issues that would inevitably come up when working on larger components and codebases.

The most common question or concern that would come up was that of the “grandchild” selector. In BEM, every element is a “child” of a block, but there is no direction or indication on what to do if an element has “children”. A frequent example of this issue is navigation blocks.

<nav class="navigation">
  <ul class="navigation__list">
    <li>
      <a href="">One</a>
    </li>
    <li>
      <a href="">two</a>
    </li>
    <li>
      <a href="">three</a>
    </li>
  </ul>
</nav>

In this example we have our navigation block, and a navigation__list element, but how are we supposed to name the list items and links? The proposal that typically comes up first is the “double element”, navigation__list__item and navigation__list__link. According to BEM standards, every element should be directly related to it’s block, so the “correct” way to name these would be navigation__item and navigation__link, this can be confusing for individuals when working on large components that may have many descendants or complex relationships.

The second most commonly discussed issue is the fact that BEM does not generally align with or allow for generic or utility classes. In BEM any time you’re adjusting or modifying something you should be using a --modifier class. This strict pattern often results in significant code duplication for common patterns like --hidden or --active, where in other systems you might simply have a generic is-hidden state class that is reused across multiple components.

Enter CUBE CSS

In the last year or two I became aware of Andy Bell’s CUBE CSS architecture. CUBE (Composition, Utility, Block, Exception) CSS is an architecture that I feel builds on some of the best parts of both SMACSS and BEM, while solving issues that both had. CUBE is; as Andy puts it “an extension of CSS,” it builds on the foundational function of the cascade and then enhances it with additional functionality.

The Composition portion functions very similarly to the layout function of SMACSS in that it defines the macro “composition” of elements. The biggest difference is that in CUBE a composition is not tied to a page layout alone, it could be used to define a page, section, or even single component’s compositional properties.

The Block in CUBE is equivalent to it’s BEM counterpart, but without the strict syntax rules. A block is used to identify and style a group of elements that “only apply in that context.” Unlike BEM however, because most of the “structural” work has been done in the composition layer, block styles are much lighter and specific to the unique context of the block.

Utility styles are built right into the name of the architecture, so they’ve got first-class treatment and support. In CUBE utility styles are very small and specific, doing only one thing: bg-primary vs bg-secondary defining only the background of an element, or sr-only applying styles that visually hide an element, but leave it available to assistive technology.

I’ve only used CUBE-style architecture on a few side projects, but my experience with it has been exceptional. This site is built using CUBE ideas and the composition classes alone feel like a superpower when coming from a strict BEM environment.

The Tailwind Sized Elephant

I’d be remiss if I didn’t talk about tailwind in a post about CSS architecture. For me personally tailwind isn’t the vibe, I know plenty of developers who enjoy working with it and think it “solved CSS,” but the complete dismissal of the cascade and excessive markup don’t align with my own personal feelings of front-end code. I’d much rather have some semantic meaning when looking at my code than an alphabet soup of pure utility classes at every level.

Thoughts Moving Forward

In today’s modern component-based development ecosystem something along the lines of CUBE’s architecture feels like it strikes the right balance of meaningful code and developer freedom. Within a design system we can expose these sorts of compositional freedoms through “structural” components like a stack, box, or card. This type of structural composition component can be lightly prescriptive in what they do, and allow development teams freedom to place whatever content is required for the interface inside of them. Pairing these with existing block style components like button or badge provides teams with the ability to create a multitude of layouts and interfaces without the need to override or duplicate code for one-offs.

Using Data to Improve Design

Sun, 18 Aug 2024 16:00:00 GMT

When setting out to create a design for a new product or reimagine an existing product, how we decide what to focus on and how to know if a change is working are critical to understanding and discussing the work. Design by its very definition has to have intent behind it; there is a motivation and a purpose that a design serves.

So how do we measure if a design has been successful? In the field of advertising, it’s relatively simple to understand. If you run a new ad campaign and sales go up, the design of the ad was a success. How do we translate this kind of 1:1 relationship to a complex web application with multiple touchpoints and a unique sales cycle, though?

This is where data comes in. Almost all massive product organizations that people think of today are constantly running experiments and collecting data on usage, tracking how small changes to an algorithm or interface impact and drive user behavior and interactions.

Data-driven Design

Making design decisions based on data insights and user analytics leads to more informed and effective design solutions. By analyzing user data and behavioral patterns, designers can optimize designs for better user engagement and satisfaction.

This approach sets up designers to identify pain points and areas of opportunity within the user experience. By leveraging data, designers can identify patterns that may not come up in contextual interviews. It’s an established bias that people will say one thing in an interview or survey, expecting there to be a “right answer,” even if that answer is not true to their behavior or actions.

Using data to inform design fosters a more collaborative environment. It provides a common baseline of understanding for discussions and decision-making among team members. By encouraging the integration of quantitative data with qualitative insights, we can develop a more holistic understanding of the user experience.

Another important aspect is the ability to test and iterate on design solutions. A/B and usability testing are great co-creation methods that can be used to gather input on different design options and determine which provides the best outcome for users. This iterative process allows for continuous evaluation and enhancement of the design.

Using a design approach centered around data also opens the door for cross-discipline collaboration. The conversation about design becomes more holistic in nature, factoring in things that fall under engineering like performance metrics. A product designer is not expected to be able to improve metrics like time-to-interaction or the results provided by a search algorithm, but these metrics clearly affect how a user experiences a product.

Measuring Success

Incorporating data into the design process also helps in setting measurable goals and tracking the success of design changes over time. This continuous feedback loop supports a culture of ongoing improvement and innovation, allowing teams to adapt and evolve their designs in response to user feedback and changing trends.

A few common metrics that teams use to track the success of design changes include: Top Tasks, Customer Satisfaction (CSAT) Rating, and System Usability Score (SUS). These metrics all have a few things in common: they’re consistent, ongoing, and robust.

A consistent metric is one that does not change over time. For each of the above metrics, the team asks the same questions every time. This provides a comparable baseline; if the metric is trending in one direction or another, you know it’s likely because of a change to the product, and not a change in the language of the questions being asked.

In order for a metric to be ongoing, it needs to be continuously measured at regular intervals. Depending on the size of the product or the frequency of changes being evaluated, these metrics can be measured anywhere from every month to once a quarter or half. The key here is that these are not ad-hoc one-off metrics. In order to have reliable data that you can check against and evaluate the success or failure of a design, you need to be constantly collecting and evaluating this data.

Finally, and perhaps most importantly, these metrics are robust. What I mean here is that these metrics need to be completed with a large enough sample size of relevant user segments. If you’re testing a product with 100,000 monthly users, a sample size of 5 is likely not going to provide statistically significant results, and the chances of outliers skewing data are very high. The standard for these metrics needs to be set at a level where you’re getting data that has stabilized and can be reliably trusted to align with the majority of your users.

Challenges with Data-driven Design

Challenges do exist in implementing data-driven design. As stated above, ensuring data accuracy and relevance is crucial, as making decisions based on flawed data can lead to undesired outcomes. It’s very easy for teams to fall into a trap where they don’t have enough participants, or the user group is not relevant to the tasks being assessed. In a desire to use the data anyway, the wrong conclusions may be drawn, and the experience is likely to suffer for the end user.

Additionally, there can be a tendency to over-rely on data, potentially stifling creativity and innovation. While I am a fan of indexing closer to data than dogma, we hire designers for a reason. Amazing brands with personality like Figma, Robinhood, and Duolingo don’t come to be from pure data; there are incredible creative minds at work developing the personality and joy those brands provide.

Striking the right balance between data-driven insights and creative intuition is essential for achieving the best results.

Wrapping Up

Using data in design offers a powerful approach to creating effective, user-centered solutions. By leveraging data to inform decisions, product teams can increase user satisfaction, improve performance, and achieve better overall outcomes. The integration of data into the design process supports a more objective, evidence-based, and multi-disciplined approach, outlining a path for continuous improvement and innovation.

Data Over Dogma

Sun, 07 Jul 2024 16:00:00 GMT

When working on design at scale one of the largest speedbumps you’re likely to encounter is a designer that feels like a design needs to change. Whether it’s something relatively small like the padding on a button or a heading’s font size, or something much larger like the layout of a card or the size of a drawer. More often than not, these designers are coming from a place of good intentions., they truly feel like their change would improve the overall experience for the user.

The Problem with Dogma

The problem with I Feel statements is that they are by nature, tied to an individual’s own sense of taste or understanding. This doesn’t make these feelings wrong, and there are times when I’ve agreed with the designer bringing up the change. The issue is that we’re not designing for our own understanding or our own taste; we are not our users.

This distinction becomes even more important when working on large-scale design work. Often a change request, even when well intentioned, does not take into account the sweeping effects that change may have across the entire product (or multiple products). If you want to make a localized change to a bit of UI or product interface that you or your team owns, I still think you should run a test and validate the idea, but by all means go for it. However, if you’re looking to make a change to a component or pattern that is used across multiple interfaces, teams, and user touchpoints, well the bar just got set much higher.

If we’re going to make a change to a system, we need to know how that system, and the systems it’s a part of are going to respond to that change. We need to move slower, test, validate, test again, and make absolutely sure that we’re not going to negatively impact one part of the business in order to support another. Big Medium put out an excellent article last year on the idea of Pace Layers that is worth a read if you’re not familiar.

The Solution in Data

As I mentioned in the previous section; the solution to the dogma problem is simple, collect and analyze data. Run small-to-medium scale experiments, see how users and other systems react to those changes, and implement what works. Sometimes this will mean rejecting proposals that may work for one part of a product or system but fail others, the previous example of changing a heading’s font-size for example; this is a change that likely can’t or won’t be done to solve a single product or interface’s issue, because that heading is used across multiple interfaces and user touchpoints.

Shifting Focus

While some designers who are especially production or visually focused may cry foul as this sort of design at scale is “stifling their creativity,” I believe this is a sign of a larger issue with the role of design at this level. By the time your design practice needs to be concerned with “enterprise-level” scale and consistency issues your designers should not be overly indexing on the visuals of an interface in the first place. If requesting your designer(s) run an experiment to validate a change request is ruffling feathers it’s likely that the change is not where they should be focusing their time or energy.

If the visual identity of a design is being changed the designer(s) working on it should be able to clearly and confidently show and explain why those changes are directly tied to an improvement in a user outcome. If we can’t answer “how does this help the user complete their job?” it’s likely not something that is providing direct value to the user or business, and should not be the focus of our time or attention.

Working with product teams, I see this as a fairly simple and powerful analysis tool for what the team is focused on, and whether or not those are the right things. Whether we’ve onboarded a new designer who does not have the background or understanding for why decisions were made, or if we’ve got a designer who is just extremely passionate about how they feel the product should look or work; if we look at every proposal through the lens of “How does this help the user,” we can ensure we’re remaining focused on what is truly important for them and the business.

Declarative Design and the Unknown Web

Thu, 29 Feb 2024 16:00:00 GMT

This past week I got enticed into and pulled down a web design rabbit hole. Chris Coyier wrote on FrontendMasters back in mid February about part 2 of Jim Nielsen’s The Case for Design Engineers.

The post Chris links to is a great argument for why we need people who can "bridge the gap" between design and development. It’s a fantastic article in it’s own right, but to get further context I wanted to read part 1.

Down the rabbit hole we go.

In Jim’s original post he links out to Jason Grigsby’s Traditional Web Design Process is Fundamentally Broken series, naturally I had to read all 5 parts. The main point of Jason makes is that we’re spending far too much time designing a facsimile of a final product, rather than producing actual products in the actual medium that they will ultimately live in. Jason’s thoughts are largely centered around responsive design, how we can easily get to "sixty artifacts in a best case scenario."

The second article in the series is titled "Design Happens Between Breakpoints," with the main idea being that we don’t know how a user may actually come to the site, and building a design based on 3 static mockups means there’s a lot of "in-between" where decisions need to be made, often times by a developer.

Thematically related, Jim closes out his post with a link to Jeremy Keith’s Declarative Design post, in which Jeremy explores and identifies the similarities in work like Intrinsic Web Design, Every Layout, and Utopia ultimately aligning on the ideas of "Declarative Design," the idea that you’re setting up more general rule-sets and allowing the browser to do the work of selecting which font-size, spacing, etc. to use in order to achieve the desired design. This is in opposition to something like Tailwind which is imperative in nature, strictly stating how something should appear in every case.

Does This Even Matter?

The ideas expressed in all of the posts, videos, books, and sites above really jive with the way I think about web design and design systems. As I’ve continued to work with diverse teams and products with differing needs I find that often times I’d much rather be able to give a globally useful, generally generic ruleset rather than strictly defining how something should look or behave at every single possible viewport or breakpoint.

It seems both simpler and more robust to say "I want you to be generally this size, but no bigger than x, or smaller than y," than it would be to say "Be this size at this viewport, and this size at this viewport, and this size at this viewport, etc. etc. etc."

Specifically from a maintenance standpoint when I think about creating text styles in a design system, using a single clamp() function with intrinsic sizing for a globally usable font-size feels more maintainable than trying to identify any number of breakpoints or use-cases that could arise.

This method of declarative design might also explain why I prefer using gap to something like margin when spacing elements within a layout. Rather than saying "every item here should have x space on the top/right/bottom/left," it feel more natural to say "put x space between all the children of this thing." If you’re defining something complex or unique you can reach for margins or other tools, but for the standard or generic layout you can use a more general rule.

I like the idea of defining a "good" base of styles that can be generally applied and used across most interfaces, I think it’s a big part of why I’m naturally drawn to design systems work. If we have these baselines, and our teams work with an understanding of how pages and layouts shift based on those rules, it’s possible to get some of the benefits of a design engineer just through the use of those rules. Maybe we don’t need to mock out every scenario, because the team already knows how a component or layout is going to behave across those screens.

Design for the web

Sun, 21 Apr 2024 16:00:00 GMT

While catching up my my RSS feed, I read through Brad Frost’s recent post Should Designers Code? I’ve always agreed with the overall sentiment of the article, especially this bit:

Designers need to understand and work with the grain of the medium for which they’re designing. For the web, that means understanding important concepts related to how things play out in the browser.

I’m not sure if there’s something in the water, or if it’s just that time in the cycle of discourse, but it feels like this topic has come back to the front of a number of conversations recently. Last month I published The Box Model for Design after having a few discussions with peers and coworkers, similarly Nathan Curtis tweeted about how designers struggling with auto layout, “Designers don't understand the box model and hierarchically nested layout techniques.”

Similarly, I feel like there’s been more conversations recently about what it means to be a web designer, the concept of a design engineer, and how we work together to build digital products in general.

I cut my teeth on the web right as the era of responsive design was taking off. Having a background in design and development was incredibly valuable when it came to understanding how we could shift and adjust layouts on the fly for mobile sites, and even more so when responsive became the norm and the mobile-first methodology became the norm. I could quickly take a design done by someone else and understand how to shift elements and layouts between sizes and devices.

In this modern era of design it feels like we’ve lost this sort of thinking.

I still see many designers working on their own, in a tool that tries it’s best to imitate what the web does, but ultimately falls short. I’ve had conversations about convoluted solutions to problems that would have been much easier to solve for the designer if they had just had a quick chat with a developer, or understood how elements on the web worked.

I have tremendous respect for the team at Figma, and think they’ve done a wonderful job of bringing design and dev closer with the release of things like Figma Variables and Auto Layout, but at the end of the day a design in Figma is still just a simulacrum of a finished web product. While Auto Layout allows designers to guild in a way that is similar to Flexbox, there is no analogy within the tool for CSS Grid, and even with the new typography variable support released this week, we still cant do “true” responsive or fluid type scales within a design.

As design tools stand today there is still no better way to see how an actual web product behaves than to load it up in a browser, interact with it, and resize the window.

I don’t believe that designers should know (or be required) to write production-ready code, but I do think we need to begin asking for, and expecting more, our of our designers. If there is a lack of understanding of the basic principles of web development, we’re inevitably going to see designs that don’t align, our designers are going to continue to struggle to understand how to use features like auto layout, and we’re going to continue down the road of slow arduous handoffs or updates.

What can we do about it?

I think that as designers and developers we need to have more conversations. I think we can hold ourselves and our peers to a higher standard, designers don’t want to “just make it pretty,” so lets take the time to work with our partners in development to understand how our designs are actually coming to life, and how we can put those designs together in a way that can take advantage of that understanding.

If you’re a designer and you want to learn how to code I think that’s phenomenal, you’re going to be an incredible partner and asset to those you end up working with. If you have no desire to learn how to code, please, at least understand how the building gets put together.

Using Object Maps in Design

Sun, 12 May 2024 16:00:00 GMT

import PostLink from "@components/PostLink.astro";

Came across this post from Adobe and I've been tossing the idea around in my brain for the last few weeks.

Using Object Maps in Design

The core idea is simple, an object map is essentially a visual representation of the relationships between the objects (people, places, and things) that exist in a product.

I really like this as a fundamental step in discovery, prior to any sort of exploration or ideation. The act of creating an object map ensures that you and your team understand the underlying relationship between the elements that you're exploring.

A great example of this could be a class roster system. When thinking about classes, students, teachers, etc. it can be helpful to break down and understand all of the different objects and their relationships. Some questions that may come up when creating the object map are:

Do students belong to classes, or are classes a simple grouping of students?
Can a teacher have a list or group of students that are not in a class?
We know that students can exist as an object without a teacher, they're both user types, but is there a requirement to always have some kind of relationship between them?
Is the relationship between a teacher and a class nested or linked? Can a class exist without a teacher, or are classes independent objects that are simple “available” to teachers?

There's no right answer to any of the above questions, it all depends on what the goals of the system you're creating. Creating an object map allows you to identify these questions, and begin answering them as part of the design process.

It's easy to jump into Figma and start adjusting or manipulating interfaces based on assumptions, but stepping back and using something like an object map creates space for those assumptions to be tested and validated.

Design Operations Focus

Sun, 14 Jul 2024 16:00:00 GMT

For the past few weeks, I've been contemplating the most valuable activities and practices to start a design operations practice. The key metrics I've focused on are team effectiveness, reduced time-to-money, reduced operational overhead, and overall product team health.

Accessibility and Inclusive Design

One of the most crucial aspects underpinning all of our products as an edtech company is the need for accessibility and inclusivity. To create truly great accessible products, the entire team must understand and value accessibility, and test with real disabled users. Achieving this requires someone dedicated to the practice who can educate the rest of the organization.

Having a DPM whose entire focus is accessibility signals its importance to the organization. This individual should understand and communicate market requirements and coach teams on how to meet them. By creating resources and running workshops on building and designing for accessibility, this person becomes a practice multiplier, spreading their skills and knowledge among product teams.

Additionally, given the specific nature of edtech products, this individual would handle responding to the accessibility portions of sales RFPs and conducting product VPATs (Voluntary Product Accessibility Template), to assess our products' current accessibility status and identify areas for improvement.

Product Development Lifecycle

This is pretty standard across any large organization. To continually improve our product development processes, we should constantly evaluate our current practices to see what can be improved, added, or removed.

A DPM focused on the product development lifecycle would partner with the product leadership team to facilitate the creation and communication of the overall product vision and strategy to individual product teams. This DPM would also work with teams to identify internal roadblocks in design and development workflows. To support team autonomy and reduce time-to-money, we need to ensure that design and development teams are not hindered by invisible obstacles.

Additionally, this individual should have a firm grasp of the overall planning process, evaluating it for inefficiencies and improving aspects like dependency management, inter-team communication, and the activities of individual teams as they prepare for planning.

Product Discovery and Research

This practice might seem like it could be rolled into the above, and while they are related and could be led by the same DPM, a few unique aspects make it worth being its own practice.

First and foremost, this individual should focus on how we conduct research and discovery. While the Product Development Lifecycle practice focuses on the entire operation through delivery, this practice zeroes in on how we conduct discovery.

As a larger organization, it can be easy to lose past research or discovery findings without a strong documentation, storage, and retrieval process. Research done by one team may be applicable to others, but if the data isn't easy to find or access, subsequent teams may feel the need to conduct duplicative research because they are unaware the information already exists.

This individual would also be responsible for removing logistical constraints on product teams. Instead of having multiple teams spend time and money figuring out how to contact users or conduct interviews, this DPM would streamline and automate this process where possible.

Finally, like the other roles, this individual would be responsible for creating resources and coaching teams and individuals on how to conduct product discovery.

Design Culture and Team Operations

When it comes to improving team effectiveness and ensuring overall team health, the organization's culture plays a significant role. Whether implementing something like Google's infamous "20% time" or facilitating casual gatherings, being mindful and intentional about the team culture you're trying to build is critical.

In addition to culture building, the daily operations of the design organization fall under this person's responsibilities. This includes coaching on how to conduct design critiques, facilitating skills gap analysis, and working with design leadership to protect "heads down" design time by reducing extraneous meetings.

Other Opportunities

There are many other practices and activities not covered here that fall under the purview of design operations. The list above is a short list of what I believe are the most valuable focus areas for a new operations practice in my organization at this time.

I already see other potential practices within my organization today, but they aren't as pressing. Since we're just starting down the design operations path, it's important to prove the value of the practice first.

My hope is that over time, we will continue to grow the design operations team and provide additional support across new avenues for the business, resulting in better products for our users.

Solving Complex Dynamic Problems with Systemic Design

Sun, 17 Mar 2024 16:00:00 GMT

Over the past few weeks, I've been collaborating with a product team to create an interface for state and academic standards. The primary idea is that a user could select the standards document they want to view and then browse or filter the records for a specific standard. They could then view all related assets and materials that we provide for that standard.

Everything seemed to be on track. We were refining some visuals with the project's designer to align them with our design system. However, during a design review last week, it was pointed out that the designer's assumption about categorizing content into headings was flawed. It turns out that there is no uniform structure across all the different states and standard documents, and these headings could be repeated, even within the same section. This left the designer feeling frustrated and overwhelmed. What were they supposed to be designing at this point?

The Drawback of "Traditional" Design

Situations like these highlight the value of design systems and, more importantly, systemic design. The designer's previous approach was to design an interface to accommodate the structure of a single standards document. While the designs they presented looked great, they didn't account for other structures or the unexpected repetition of data.

Many people are familiar with this design approach, which is often the go-to design process for projects. When all the requirements are clearly laid out, and there are minimal unknowns or constraints beyond your control, this approach works well. But why doesn't it work in this instance?

In this case, there are significant constraints that we cannot control. We don't determine the structure or data within these documents. They are produced by governing bodies within individual state or academic groups. If we design a clever interface based on one dataset, we can't guarantee that a completely different dataset will function the same way. Additionally, assumptions made based on the document's structure, such as headings, parent/child relationships, additional metadata, etc., may not hold true across the diverse set of documents we need to support.

To use this design method for this project, we would need to create unique interfaces for every new type of document we want to support. Even if we only consider the 50 states in the US, each state has multiple documents for different subjects, and these documents could be created and released decades apart.

Systemic Design as a Solution

Systemic design is more of a design methodology than a single change in the design process. The main idea is to view the entire design as a system, or series of systems, and consider how they interact to produce the final result.

In this case, it involves identifying the basic elements shared across all documents, understanding how these elements relate to each other, and defining a set of rules for how they can be combined to create an interface.

Identify

The first major step in creating a systemic solution to any complex and unpredictable design problem is to identify as many variables as possible up front. This sets us up for success moving forward.

For us, this involved creating a single "item" with conditional elements based on the data present. We ended up with an item that:

May have children
May have aligned resources within our products
May have one or many labels that need to be displayed
May have a number associated with it
Will have a description

Understand

By identifying all these conditions, we can start with the simplest definition of an "item" as a piece of text. The only thing that every "item" has in common is a description. From there, we can begin to layer on and combine other elements to create a full interface.

Some questions we can ask to begin understanding the relationships between these systems include:

Does this item have children? How do we indicate that relationship? How many descendants can we feasibly support?
What does an item look like with no label? With one label? With multiple labels?
How do we indicate when we have resources within our product that relate to this?
How complex is this single item if all these variables are present? How do we gracefully increase or decrease that complexity?

Define

Once we've identified the variables and understood the relationships between them, we can start defining rules to construct the final result based on the available data. This is where the term "systemic" design truly earns its name - it's where we design how the system will work.

Potential solutions based on the data we've been using could include:

If an item has children, present it as an expandable section, possibly with a visual container or background.
If an item has a number, display it in bold, inline, before the description text. This serves as an anchoring element for the user to quickly scan the page.
Display labels above their respective content in a way that clearly indicates they are labels.

The real benefit here is that once these decisions are made and rules are in place, we don't need to design additional interfaces when the content changes. The system automatically produces the desired result.

The Final Product

Now that we've defined the rules of our system, we can test it. The best way to do this is to take samples from several diverse data sets and see what works and what could be improved. Do our assumptions hold up across these data sets? Does the final design make visual and logical sense? Do our individual decisions work together or against each other?

While this process may take longer to produce a final product, the time invested in analyzing, testing, evaluating, and adapting to the results will be worth it. By taking the time to thoroughly understand the system you're creating and how it needs to respond to dynamic inputs, you'll produce a more robust and sustainable end result.

Evaluating Design Success

Sun, 28 Jul 2024 16:00:00 GMT

Design is creativity with a specified purpose. Design always has goals and intention behind it. So how do we know when we’ve achieved those goals? Measuring the success of design can be incredibly simple, it can also be one of the most challenging aspects of a design career. With advertising, measuring the success of a design is simple, if more people purchase the product you’ve done a good job.

What about product design though? If your product is complex, with many interwoven functions, and multiple design teams, how do you know if your design change is successful? Did sales go up because of something you did, or someone else? Did conversion rates increase because of your design, or was it just coincidence? What about the opposite, if a metric tanks was it your design, or did someone else cause the issue?

Measuring Design

When we talk about measuring the success of design it’s important to start with a good understanding of what it is we’re measuring, and why those metrics are important. Anyone familiar with product or business KPIs should know the familiar favorites: click-through-rate, bounce rate, session duration, and NPS.

I’d like to argue however, that these metrics are not as valuable when discussing the success of design, and often times could indicate the opposite of what we’re actually trying to achieve. A specific example can easily be illustrated with bounce rate and session duration. If the goal of a product is to provide the desired information quickly and easily we’d likely see an increate in bounce rate and a decrease in session duration. This does not mean that our product is bad, or that our users are unhappy. What it may actually indicates is that we’ve succeeded in providing exactly what the user needed in order to quickly and easily complete the task, they don’t need to search around or spend excess time in our product.

A few more valuable metrics for evaluating the success of design would be: Task success rate, time on task, error rate, and error recovery rate. I particularly like starting with these 4 metrics because they facilitate conversations around the outcomes we’re trying to achieve with a design, as well as potential tweaks we can make to assist the user in achieving that outcome.

Task Performance Indicators

I’m certainly not the originator of these ideas, Gerry McGovern first wrote about TPIs back in 2016. Task Performance Indicators (TPIs) are a “stable, reliable, repeatable metric to test top tasks over time,” in practice, they’re a repeatable metric that allows you to continually check on the health of specific tasks as you make changes to the design of your product.

The real magic here is that it doesn’t take that much to get usable results. As with all research related work, there’s a bit of up-front planning, you need to identify what you consider success to be, identify representative user segments, and generate your tasks and questions, but you only really need to do that once. Because the intention if TPIs is to check health and progress over time, you should be testing with the same segments, though different users, and asking the same questions every time you run this study.

What TPIs provide is a clear breakdown of how quickly and successfully your users can use your product. You get an indication of time-to-completion of a task, and a solid indicator of whether or not the tasks themselves are easy to complete, if 40% of the testers can not complete a task you’ve got some work to do. Additionally, TPIs provide a sort of health-check on the product. If your scores go down that’s a flag to investigate why. With continuous development things change, get removed, or break all the time. Regularly evaluating your TPIs means you catch these issues, and investigate them proactively, rather than getting news at a quarterly review that our monthly active user count has plummeted, and no one is sure why.

Successful Design, Successful Business

At the end of the day, everything we do is in service of two groups: our users, and the business, or as Marty Cagan puts it were “creating solutions for our users, that work for the business.” Part of knowing if our design changes “work for the business,” is knowing what we’re measuring, why it’s the right right to measure, and how it impacts the business.

Traditional business centric and vanity metrics may not provide the correct information on whether or not we’ve been successful, and may even reflect the opposite. If we want our users to be happy and continue using our products we should focus on metrics like task completion rate, time on task, and error rates to inform our design and product decisions.

If you’re interested learning more about design-related KPIs and measuring the impact of design I suggest checking out these videos by Vitaly Friedman, and his new course Smart Interface Design Patterns.

Chris Coyier - Exposed RSS

Sun, 14 Jan 2024 16:00:00 GMT

import PostLink from "@components/PostLink.astro";

I doubt he was specifically talking about this blog; but after reading Chris' post I checked and realized that I am one of those sites taht does not auto-expose their RSS feed in the HTML. I've since added the relevant line in my head and we should be good to go.

What a week, first I learn how to easily set up import aliases, and now I've got a properly exposed RSS feed. Wondering what I'll learn I'm missing next week.

Fall Vibes

Sun, 01 Sep 2024 16:00:00 GMT

Holy Pumpkin Spice Batman, it’s September! I feel like the last few months have been a bit of a blur.

General Life

Despite the title of this post, it’s distinctly un-fall like in TN right now. With highs in the 100s over the last few days, the brisk 83 we had for a high today felt like a break. Looking back on July and August it’s not surprising that it doesn’t feel like it’s September. We went to Config as a family the last week in June, and came home to start the first few weeks of July with Covid. Thankfully we’re all boosted, but this was the first time any of us had gotten it, so it was a little disheartening and surprising how much it could take out of you.

On a better note, we had a few visits from friends and family in late July and early August that brought some much needed delight to the house. It’s always a pleasure when people come to spend some time with us, since most of our friends and family still live in Illinois. Unfortunately, that also tends to add to the whirlwind of activities, and with our big England/Scotland/Ireland trip on the horizon it’s certainly been a stressful past few weeks.

Scotland Ahoy!

On that note, we’re going to the British Isles in a week! This time Friday we’ll be on a plane crossing the Atlantic. Neither Becca or myself has ever been, so we’re very excited to get to do this first together, and with Gideon too! I’d say we’re most excited to stop in Edinburgh, getting to see some of the beautiful architecture and towns is something we’re both looking forward too.

Work Updates

After coming back from Config it’s unsurprising that work has been busy. Not only were there lots of talks and updates to (and from) Figma that we had to discuss, share, and explore as a team, but UI3 also meant a pretty big change and impact for some people. I’ve mostly adapted at this point, but I’m sure we’ll still be feeling the impact and spend some time on coaching for a bit longer.

Fall also marks back-to-school, which at an edtech company might as well be the holiday season. It’s our busiest time of year when we’re buttoning up final features and ensuring the product is as-good-as-possible for a smooth transition back into learning for both teachers and students.

On top of all of that I also officially stepped into my role as Lead of Product and Design Operations. The last few months have mostly been spent talking with team members about their experience to get a broad understanding of where we have problem areas and what sorts of improvements would make the biggest impact. We’re currently in full-swing for planning out the work our teams will be doing in Q4, and it feels like there’s never enough time for everything I want to get done in a day; but I guess that comes with the role, always looking for improvements.

Around the Web

Some interesting posts that I came across over the last few weeks:

40 thoughts at 40 - I’m a little late to this one, but It was a joy to read through Brad’s thoughts as he crosses this age milestone.
Traveling to technical events: A guide - As someone who is marginally obsessed with bags and travel gear it was super interesting to me to read about how Cassidy travels. I’ve also added the Topo Designs Rover to my “want to buy” list, so thanks for that.
Basic keyboard shortcut support for focused links - I feel like this post from Eric is so incredibly important. So often people don’t understand the vast array of things that come with simply using semantic elements. This sort of clear, explicit

The Blog

I’ve been able to stick to my goal of 1 post a week, though some weeks have definitely been harder than others. I also managed to finalize and push out a new site design. I’m quite happy with the overall feel of the site, although some actual headshots are likely in order.

Some of my personal favorite posts recently are:

Site Redesign Retrospective - I don’t often get to work on or talk about my own design work these days, so writing a post about designing, building, and reviewing my work was a nice change of pace.
Evaluating Design Success - Something that is top-of-mind right now in terms of Design Operations. When talking with my product and design teams, we need to know how we’re measuring the success of our changes.
CSS Architecture Archeology - This started out as a draft about separating structure and style in CSS and morphed into a meandering exploration of the CSS architecture models I’ve used over the years. I still want to write the post about style and structure, but this was a fun trip down memory lane.

Wrapping Up

So far this quarter has been incredibly busy and a little frantic. I’m very much looking forward to getting to unplug and spend some quality time relaxing and hanging out as a family on this trip, even if it’s a bit nerve-wracking being our first big international travel with the kiddo. I’m sure there will be plenty to catch up on when I come back, but that’s a problem for future me.

Implementing Design Feedback

Sun, 22 Sep 2024 16:00:00 GMT

Design feedback is a crucial part of the creative process, allowing designers to refine and improve their work. However, implementing feedback effectively can be challenging. This guide will explore some practices for incorporating design feedback into your workflow.

1. Understand the Feedback

An easy trap to fall into is accepting feedback without properly understanding it. Clarify ambiguous points before deciding what to do, asking for specific examples if needed. When possible, try to understand the reason for the given feedback as well, sometimes suggestions may be given due to confusion or a misunderstanding of a product or feature. Ensuring you understand the feedback fully before moving forward ensures that you’re working on the right things, for the right reasons.

2. Prioritize Feedback

Not all feedback is equally important. Prioritizing the feedback you receive allows your team to focus on the right kinds of feedback at the right stage of the process. Some options for prioritization include:

Project goals and objectives
User needs and preferences
Technical constraints
Time and resource limitations

3. Create an Action Plan

Once the incoming feedback is understood and prioritized it’s time to make a plan on how you’re going to tackle it. Often times input and feedback is can come in large requests, breaking those down into smaller more manageable tasks allows the team to work through changes one at a time.

It’s also important to set realistic deadlines for the work, users and stakeholders both want their changes the moment they request them. If you’ve properly prioritized the work you should be able to provide a general roadmap of how and when the feedback will be addressed.

4. Implement Changes Iteratively

Along with creating smaller tasks, it’s critical to implement these changes iteratively. When working through changes teams should test and review the changes regularly. Implementing one high-priority change may reduce or remove the need for other lower priority changes. Alternatively, changing part of an interface or flow may cause different issues to arise which may need to be reviewed and prioritized ahead of other feedback. A cycle of iteration and review ensures that teams are consistently improving the experience and moving towards user satisfaction.

5. Document Your Process

While it may feel obvious what you’re working on to you and your team, stakeholders and users may not be aware of every direction or decision. Ensure that you note decisions around which feedback has been implemented and why the decision was made, if similar feedback comes up in the future you’ll be able to reference past decisions on how or why you moved in the direction you did.

Any new challenges, issues, or insights gained through iteration and feedback should also be documented for reference later. The team may want to pursue a bit of feedback, but is not equipped with the resources or skills today, documenting these challenges allows conversations to take place around how to best approach these ideas moving forward.

7. Reflect and Learn

Use the feedback process as a learning opportunity:

Analyze what worked well and what didn't
Identify patterns in the feedback received
Apply lessons learned to future design processes

The feedback process does not end when changes have been made or features ship. After work is completed the team should analyze what worked well about the current process and what can be improved in the future.

When collecting and working through feedback the team should also strive to identify any patterns that begin to establish. Common threads can be pulled to dig deeper and get to root problems or opportunities for improvements. If multiple pieces of feedback come through on the same or related issues it may also be a sign that the issue should be shifted up in priority as it’s causing enough of a problem to be reported multiple times.

Implementing design feedback effectively is a skill that improves with practice. By following these steps and maintaining open communication, designers can create more refined, user-centered designs that meet business goals and user needs.

Coding in Public - Import Aliases

Tue, 09 Jan 2024 16:00:00 GMT

import PostLink from "@components/PostLink.astro";

One thing I've struggled with on many iterations of this blog is the constant ../../path/to/file string for references, whether imports, css, or images. I've never really understood how to set up import aliases and always just dealt with the tedious task of updating or changing those strings if I ever moved a file.

Good news! Coding in Public released a new video today that explained exactly how to set them up (and in Astro no less)!

Leading Design Systems

Sun, 21 Jul 2024 16:00:00 GMT

As I look to progress in my career one thing that I’ve had to grapple with over the last few months is the idea that I’d no longer be the one with the hands on the wheel of our design systems. Focusing on larger Design Operations and product leadership initiatives means I’m going to have less time to focus on the specifics of design systems. Having been the leader of this team for the better part of a decade, it feels a bit like leaving a part of myself behind.

When done well, design systems work is some of the most interesting, exciting, and dynamic work I can think of. With core goals of improving team effectiveness, reducing simple repetitive work, and providing a trusted baseline for design, functionality and accessibility, there’s always something new to explore or work on that provides new challenges. In a way, design systems are all about finding the best way to provide premium solutions to the hardest “simple” problems.

In my opinion the most critical “skill” I brought to my team was the fact that I’m a polyglot. I’ve been a designer, a developer, and a product manager, I still excel at many aspects of these roles and I speak each language fluently. It’s always been easy for me to jam on a design collab or hop on a call and pair program with someone. These skills meant that I could understand the entire landscape of design systems.

Understanding Design Systems

Design systems by nature serve (at least) two different user-bases with drastically different needs and expectations. Sure, a simple component library might solve the needs of a developer, but that provides no value to a designer. Similarly, a sticker sheet or Figma library is great for designers, but provides no value to a developer. The magic of design systems is that they live in these spaces, and fill in the space between.

Design Tokens are the perfect example of this idea, they provide a “single source of truth,” for both designers and developers to reference. This means that a designer has a high sense of confidence that if they specify something as color-primary-100 in their design tool, the developer can just pick up that reference in their codebase and the colors will be the same.

This “in-between” is where I’ve always seen the most value for design systems. A component library that is the same in code and in a design tool is critical, and often the foundation of many design systems, it’s a logical place to start. But when you start looking deeper, or dive into the real roadblocks of design/dev collaboration you find that this is often not the issue.

For a dev team, it might be that they’re spending excessive amounts of time inspecting designed components to understand what props they need to fill out to achieve the desired look. For something like this the design systems team may find it valuable to create a plugin for the design software that crawls the component and outputs exactly what props and values are being used.

For a design team, they may feel a need to provide highly detailed specs for developers to reference or follow. A design systems team may look at this issue and come up with a solution that does this automatically (Thankfully Nathan Curtis thought of it first, and has already done a lot of the work for us).

Design Systems Leadership

The promise of the design system is “build once, use everywhere.” To me, in order to fulfill that promise you need someone technical in a leadership position. They need to be able to understand the intricacies of software development. If your system needs to support multiple platforms of frameworks how the team addresses this requirement is going to impact their ability to update, maintain, or publish components. A less technical individual might not see a problem with creating and maintaining multiple unique versions of a component.

Alternatively, having someone who is very well versed in development, but does not understand business principles may not be able to parse that it’s not viable right now to rewrite an entire vue or react codebase into web-components given other business objectives.

Design is right there in the name, the leader also needs to be able to understand and talk to designers. Being able to empathize with design-related issues, and having a firm grasp of how design work gets done is crucial to providing the best experience for the teams using your systems.

Part of the problem with finding someone who checks all of these boxes is the industry push towards highly specialized individuals. Amazing designers and developers often specialize in their role and either don’t have the experience, or desire to pivot into this new kind of work. Plus, we really don’t want to take the best performers and remove them from doing their work either.

Finding the Right Person

It’s 7 years old at this point, but Nathan’s post Design a Systems Team does a great job of breaking down the type of leadership that a design system needs. The “Lead” needs to have many of the skills of others on the team in addition to having product leadership and management competencies.

If the design systems team is large enough, it’s possible to split this role into multiple individuals like a design and development leader working in tandem to create and execute on the system’s roadmap. This type of leadership can be seen working to great success at Github, the Primer team is lead by Diana Mounter on the design side and Neha Batra on the engineering side. They gave a talk at Config this year and shared the story of how they found success with this paradigm.

Overall, I’m not quite sure what the future of design systems will look like for my team right now, I’ve still got an eye on the wheel, and my leads are continuing to provide excellent service to our product teams. With new tools and AI on the horizon the list of “things you need to understand,” isn’t getting any shorter, but our designers and developers deserve that we put our best foot forward and continue to serve their unique needs in compelling ways.

Improving Team Alignment and Understanding

Sun, 14 Apr 2024 16:00:00 GMT

As a part of looking to improve our the efficiency and effectiveness of our product and design teams I’ve been reading Discussing Design by Adam Connor and Aaron Irizarry. I’d like to boost one of the concepts discussed in the book that I think could benefit a lot of teams I’ve worked with in the past, the idea of the Mini Creative Brief.

What is a Mini Creative Brief?

The concept here is actually astonishingly simple given how effective it can end up being. Originally shared by Jared Spool, the idea behind the Mini Creative Brief is to capture the most important foundational elements and objectives for the product on a single page or less.

In it’s most basic form, a mini creative brief is a smaller version of a project’s full creative brief. Rather than containing everything that could possibly relate to a large project or product (goals, personas, principles, etc.) a mini brief only contains information that is relevant to the current discussion. The mini brief should also be understood to be more of an overview than a full reference document; for example, if a persona is included in the brief it should be condensed, the entire reference document for the persona is likely to be found elsewhere within project resources.

An example list of what could be included in a mini creative brief may contain:

A brief summary of the problem statement or purpose of the product
The key users or persona of a solution
The main scenarios in which the solution could be used
Any relevant business goals that have been established for the product
Relevant design principles to be followed.

The key here is that the document should remain brief. It should be something that can be easily read through and understood in no more than 2-5 minutes. We’re not looking to outline every detail with this document, just enough to ensure everyone reading it is in agreement.

How to use a Mini Creative Brief

In the book, and in Jared’s post outlining the concept, the main way to use a mini creative brief is to have it read out at the beginning of a meeting. The point of this activity is to ensure everyone in attendance is in agreement on what is going to be discussed, and the goals of the team working on the product.

Because this is the primary, and intended purpose of the brief it’s easy to see why it needs to be short. We don’t want to spend 15-20 minutes at the top of a meeting reading through a brief before we get into the valuable discussion and reason for calling the meeting in the first place.

In most cases you’re likely to find that everyone on the team is in agreement and the team can move on with the meeting. However, the real value of this ritual begins to reveal itself when someone has a question, of there is misalignment within the team. By taking the time to read through the brief and create space for the team to have this conversation it’s possible that quick discussions and clarifications can be had. Without this sort of ritual teams may be working with the impression that everyone is aligned when the opposite is true. This often results in teams having longer discussions and change requests later in the development cycle, typically when these sorts of issue are far more costly to address.

As Jared outlines in the article on CenterCentre:

[…] things change […] We hit constraints and challenges that make us rethink what we’re trying to do.

Dedicating a moment at the start of each meeting to discuss these changes and get everyone in the room to agree on the project’s current path is a brilliant move. […] Reading this short-form creative brief out loud short circuits those endless debates and lets the team focus on the problem at hand: does this design get us where we’re trying to go?

The simple act of bringing the team together to create and align on the mini creative brief, and the ritual of reading through and referencing the brief before every discussion can have a profound impact on the overall alignment of a team.

Wrapping Up

In my experience the lack of consistent communication about the what, why, and how of the solutions we’re working on is the largest contributor to slow progress. When misalignment occurs, but is not identified until much later in the process teams are likely to find themselves being forced to stop progressing, make costly changes, and compromise on decisions in order to salvage lost time and resources.

Even if a team has to modify the examples shown above, adopting this practice is likely to short-circuit a number of the issues discussed. If you find that your teams are struggling with alignment and communication, it might be worth giving the mini creative brief a try.

Learning through Teaching

Sun, 28 Apr 2024 16:00:00 GMT

Did you know that the DOM (Document Object Model) defines the web as objects? Or that this representation of web pages is object-oriented so that it can be modified by scripting languages? While these may seem like basic ideas it’s always interesting to dig into the details of the web that we work in and understand how and why things are the way they are.

I’ve been collecting resources and doing research over the last few weeks to begin putting together a course for designers looking to build a foundational understanding of the web to enhance their ability to design for it. One thing that is consistently a joy about this process is revisiting basic foundational concepts that have been ingrained into me and trying to look at them from the mindset of someone who doesn’t know these things as intimately.

I knew it was called the DOM, that it stood for Document Object Model, and that we could use JS to manipulate and alter it; but I don’t think I ever thought much past that. I may have been told about the object-oriented nature of it once or twice when learning in school, but that bit of knowledge long since left my brain as it was not necessary to my understanding or day-to-day work.

Having worked across design and development on the web for almost 2 decades, I’m finding the curse of knowledge to be a very real thing. I think this is something that many developers have a hard time with; remembering what it’s like to not know. When we look for mentors, coaches and teachers we want someone who can remember what it’s like not to know, and help guide us along the learning journey.

It’s been a joyful refresher to dive back in, learn and re-learn things, and get a sampling of what it’s like to experience these things for the first time again. I’m excited for the work I’m doing and look forward to getting to share these feelings with people as I help them along on their journey.

Indicating Link Posts

Fri, 16 Feb 2024 16:00:00 GMT

As I read posts or see cool videos on the web I want to be able to write a short post and link to those resources. However, I want to be able to clearly indicate those posts and differentiate them from other blog posts that are primarily content to be read on this site.

Thankfully that's relatively easy to do, and I wanted to share how I went about it using Astro.

The first step was going through my old posts and adding a new tag that I've named link-post. By using a tag I get a couple of things for free. I've already got tags displayed on the bottom of each page, and 'tag' specific routes on this site.

<p class="aside"> One of the other major benefits of using tags is that in the future, if I want to create a nicer page that shows all of the link posts I could just filter my writing collection to find all posts with the link-post tag. Additionally, I could also filter out any post containing that tag from my main writing feed. I don't see a major reason to do that at this time, but it's nice to have the options available. </p>

The next order of business was to indicate what posts are link posts on my post lists, again tags coming in handy for this. I'd been meaning to clean up some of my old migrated site architecture and code so I ended up creating a component for my post previews. While grabbing post data and passing it ot the component I pass a simple .includes check to a boolean prop indicating whether or not the post is a link post based on the tags on the post.

<PostPreview
  link={post.slug}
  title={post.data.title}
  pubDate={post.data.pubDate}
  isLinkPost={post.data.tags.includes("link-post")}
  type="compact"
/>

Then within the component I'm just conditionally rendering the link icon next to the title if the boolean value is true.

<p class="post-preview__title">
  {title}
  {
    isLinkPost && (
      <Icon class="post-preview__link-icon" name="mdi:link-variant" />
    )
  }
</p>

The last link in the chain was create a small astro component that I can use on these posts to create an obvious CTA linking back to the main source.

---
import type { HTMLAttributes } from "astro/types";
import { Icon } from "astro-icon";

interface Props extends HTMLAttributes<"a"> {
  link: string;
  linkText: string;
}

const { link, linkText = "View Link", ...props } = Astro.props;
---

<a href={link} class="post-link" {...props}>
  {linkText}
  <Icon class="post-link__icon" name="mdi:link-variant" />
</a>;

Super basic stuff going on here. I'm just extending the base a element with a couple of props so that I can reuse this bit of code in mdx files without needing to manually copy and pase it. This component outputs a simple button styled link onto the page.

In addition to getting a neat new feature that indicates posts on the site that link out to other content, I was able to componentize a couple areas and clean up some major styling debt. There's still more work to do, but I'm having a blast working in astro and bringing my site into the modern web era.

Managing Change in your Design System: Workflows and Change Control at Enterprise Scale

Sat, 03 Feb 2024 16:00:00 GMT

This past week Knapsack held a session with Nathan Curtis all about managing change in a design system.

I took some notes on things I thought were interesting, figured it be worth sharing them here as well.

How do I make this [Design Systems] a priority for my organization?

Hitching your Wagon

Often times there are other groups or teams within your organization who are beginning to commit, or are already committed to a broader effort. As the design systems team/organization you should look at these efforts as opportunities to shine.

If the design system can enable or ease these efforts that is a clear path to success — “By using the design system, our Infra team was able to spin up this new admin panel in half the time.” Congrats! You’ve now shown the org how investing in; and committing to using, the design system had a direct effect on the organization’s ability to get work done.

Adoption

Along with the concept of hitching your wagon, when we look at adoption numbers, we need to understand that the system itself needs to provide more value than the opportunity cost of implementing and adopting the system. Even if the time/opportunity cost of adopting a design system is net-neutral, the adopting team could have spent that time on other work.

When we look at what the system is providing and how easy it is to adopt, we should ensure we’re focusing on providing maximum value with a quick and easy onboarding process so teams can focus on what they actually care about.

Product Managers

As a member of the PM org within our company this one is especially familiar to me.

A great way to show value and get the company to care about design systems aside from hitching your wagon is enabling other teams to complete their work. If you can meet with a PM; or better still — all the PMs you serve, and talk with them about their roadmaps then you have a map of golden opportunities to show how your team is impacting the company and providing value.

How and when can the design systems team lean in and help product teams deliver on their goals? Find ways to accelerate teams and de-risk other initiatives and design systems will become a clear partner in the creation of products within your organization.

How do I find ways to create success stories?

Before we can create success stories we need to understand what success looks like.

Adoption is often the go-to metric for design systems, but what kind of adoption are you looking for at your current system state and size? Is 100% adoption of all components across all products a true metric of success? Many teams may not need all of your components, or may not be able to adopt at this time due to other priorities.

A great way to begin to accrue and tell success stories is to work with teams and create a snowball of success. Get a smaller team to adopt a portion of your system and show how it improves their processes. Take that success and move onto another team, slowly and tactically growing your successes over time. This will build trust within your organization and allow other teams to see how adopting the system can benefit them as well.

How do you communicate with your audience?

An important factor in the longevity and success of a design system is the partners the system works with. Communication is key to developing strong relationships with the teams and adopters you serve.

Create a Public Roadmap

Creating and distributing a public roadmap is a clear and easy way to indicate the priorities for your team, along with the intentions and direction the system is headed.

A roadmap can also serve as a useful tool for advocates to share the system within their spheres of influence. A team may not have full adoption of a system, but if you or an advocate can show that a feature on their roadmap is also on your roadmap it can allow them to work with the systems team to speed up their process and increase their likelihood of using the system in the future.

Developing beyond a set of components

As a system grows in maturity and the needs of teams evolve you may find that the system needs to shift in priority as well. Once you have a strong baseline of components, patterns, and principles you may feel you’re becoming stagnant or don’t know how else to deliver additional value to the organization.

If the goals of a design system are to improve the overall abilities of product teams, speed up development time, or de-risk new bets, you may find other avenues will be valuable to explore. Can your system provide tooling or processes to help development teams with automated testing and approval of pull requests? Can you set up or develop tooling to test for things like accessibility? Maybe the team develops an API to communicate between Figma and Code to speed up the time it takes to get from a design to a functional prototype or v1 of a product.

Q&A

“Does it make sense to create a ‘universal’ system that caters to all teams?”

Probably not, across different teams is their enough alignment and consistency that makes sense for those teams to share?
Are you going to change at the same rate based on the same priorities and languages?
- If one team is going to change based on different rates or priorities, it may not make sense to adopt the same system as another

Source of truth should be a technology agnostic Specification

The framework or library is a representation of the spec.
There can be a “reference” build that perfectly provides an example of what to expect
If individual teams need a different implementation, they should be able to come to a clear definition within the spec and use that to develop their own implementation
Design → Spec → Production Pipeline (Dev Docs, Framework Component, Figma Component, etc.)

“When is it OK to introduce something completely novel to product without adding it to the design system?”

*ALL THE TIME - Most things are not necessary to be in the system*
Great ideas need time to percolate
Product the pockets of innovation

“When someone comes to the design system team and wants to make a variant of something, how do you have that conversation while balancing consistency with innovation?”

Shared Need
There’s always a greater level of effort to add something to the system. How does adding this to the system solve a shared need across different product teams.
What is the level of quality it needs to reach?
Who is going to work on this feature?
Does this need to be part of the “core system” or can it live within an alternative shared library?
- Central system → Central team created, Everyone uses
- Local system → Local team created, Only used by 1 team
- Shared system → Community created, Optionally available for others to use

Native CSS Nesting

Sun, 05 May 2024 16:00:00 GMT

With the release of Firefox 117 CSS nesting has full browser support coverage. Let’s take a look at how nesting works in CSS, how it compares to pre-processors like Sass, and some tips, tricks, and gotchas to watch out for.

What is Nesting?

In any programming language, when you have a declaration inside of another declaration this is called nesting, typically you can identify nested declarations because they are indented within the parent declaration. CSS nesting works no differently, you can nest one selector inside of another selector, and the browser will now identify that nested selector as if it had been manually declared with the parent selector in front of it.

.some-class {
  /* Styles */

  .some-other-class {
    /* More Styles */
  }
}

The code above will now render within the browser the same as if you had previously written it like this:

.some-class {
  /* Styles */
}

.some-class .some-other-class {
  /* More Styles */
}

This may be familiar if you’ve used any CSS preprocessor in the last decade. The main difference with native CSS nesting is that there is no compile step. Previously, when using a preprocessor your sass/less/stylus code would be run through a build-time compile step that would take the first example and transform it into the second one. With CSS nesting this step is no longer necessary.

So I don’t need a preprocessor any more?

Well, it depends.

If you were only using a preprocessor for nesting, and you’re only nesting complete selectors you’re good to go. Just convert your file to the standard CSS format, remove your build step and you’re off to the races!

However, many people use more features of a preprocessor that just nesting. Variables are another common pattern and use-case for preprocessors, they can now be removed thanks to CSS Custom Properties, but you’ll have to make sure you swap them all over before running straight to no-build-time land. If you have any preprocessor variables like this $some-variable in your code CSS wont know what to do with them, and they’ll ultimately just be an invalid value for the property they’re assigned to.

Another major draw for preprocessor of the ability to add logic to our CSS. Functions and Mixins are the last bastion of preprocessor functionality that hasn’t been added to CSS or handled by another system in a build. There’s currently an open proposal that has been accepted by the CSS Working Group, though it’s still under heavy discussion. So if you’re using functions and mixins, you’re still going to need a preprocessor.

You mentioned “complete selectors” above, what does that mean?

One of the patterns available with preprocessors that was not adopted by CSS is the ability to concatenate strings onto the end of a selector.

In Sass/Less/Stylus you could write the following code:

.some-class {
    // Styles

    &--special {
	    // More Styles
	}
}

And it would compile to:

.some-class {
  /* Styles */
}

.some-class--special {
  /* More Styles */
}

While this pattern has seen some popularity, many people also consider it an anti-pattern. It results in source code that can not easily be searched because the compiled selector does not actually exist within the source.

If you have this sort of nesting within your preprocessor code you would need to refactor all of the selector partials into full, complete selectors in order to use native CSS nesting.

Some helpful nesting patterns

One of my favorite patterns for nesting is co-locating states within their parent. When styling an interactive element, it’s good practice to ensure you’re also proving at least :hover and :focus states, if not also accounting for :active, or other input-specific states. The nested state pattern would look something like this:

a {
  color: var(--link-color);
  text-decoration: none;

  &:hover,
  &:focus {
    text-decoration: underline;
  }

  &:focus-visible {
    outline-width: 2px;
    outline-color: var(--link-color);
    outline-style: solid;
  }
}

You can see that the additional states are nested within the a selector. By nesting the states it’s clear when scanning code that they apply directly to the class or element that they’re nested within, allowing other authors to easily understand the relation.

Another useful pattern is applying additional styles based on the contents of an element using the has() selector.

blockquote {
  --blockquote-background-color: transprent;
  --blockquote-border-color: var(--text-color, var(--text-primary));
  --blockquote-text-color: var(--text-color, var(--text-primary));
  --blockquote-link-color: var(--link-color, var(--gold));

  background: var(--blockquote-background-color);
  border-inline-start: 5px solid var(--blockquote-border-color);
  border-radius: 2px;
  color: var(--blockquote-text-color);
  display: flex;
  flex-direction: column;
  font-size: 0.8em;
  gap: 8px;
  padding: 16px;

  a {
    color: var(--blockquote-link-color);
  }

  * {
    font-size: inherit;
  }

  &:has(cite a[href*="twitter"]) {
    --blockquote-background-color: #000000;
    --blockquote-border-color: rgb(29, 155, 240);
    --blockquote-text-color: #ffffff;
    --blockquote-link-color: rgb(29, 155, 240);
  }

  &:has(cite a[href*="mastodon.social"]) {
    --blockquote-background-color: #282c37;
    --blockquote-border-color: #6364ff;
    --blockquote-text-color: #ffffff;
    --blockquote-link-color: #6364ff;
  }
}

This is the block quote code on this site created in this post. The basic idea here is that we’re using the has() selector to swap the value of custom properties based on the contents within the blockquote element. This pattern is handy when you’re modifying an existing element based on the contents inside; or with the upcoming style() queries, a custom property. This is a useful way to specify a base set of styles, and then only override or modify what is needed without needing to add additional classes or markup to your elements.

I hope you found a couple things interesting, and maybe learned a thing or two about native CSS nesting and how it can be used today to enhance your CSS. Happy coding!

Product Discovery Toolkit

Sun, 02 Jun 2024 16:00:00 GMT

In Product-Led organizations discovery is critical to understanding what users need and determining the right things to build. There are plenty of tools at our disposal to conduct discovery. In this post I want to highlight a few mentioned in Marty Cagan’s Inspired.

What is Product Discovery?

Before diving in to the methods I think it’s important to define what I mean by product discovery. There’s many different types of product discovery that can take place across different organizations and stages of the product development life cycle.

When I talk about product discovery in this post I’m specifically referring to methods and processes that relate to determining what users need, and exploring solutions that we could provide to meet those needs.

MVPs, Prototypes, and Experiments oh my!

Much like product discovery, depending on the organization and team dynamics these words can be used interchangeably. In my experience MVP is one of the most overloaded phrases in tech, it can mean drastically different things to different people, because of this it’s a word I like to avoid.

For my purposes, a prototype is a shallow step into building something in order to provide very specific answers to a very specific set of questions. The methods, depth, and set of questions may differ depending on the prototype being created, but these rules generally apply across the board.

An Experiment on the other hand, is a timeboxed event that is done with real or perspective users. Experiments regularly use a prototype in order to get feedback from users in some form. The distinction is subtle, but i feel it’s important to understand that a prototype is an artifact, where as an experiment is an event or study. The act of simply building the prototype, in many cases, is not enough. We need to put it into the hands of actual users in order to gain useful insights.

Feasibility Prototypes

Starting with this one right out of the gate because I strongly agree with Cagan in that it’s often discounted by Product Managers, or seen as a strong deterrent to going down the path that presents the need for a feasibility prototype.

A Feasibility Prototype is most often created by an engineer when a product team has a solution that treads into unknown territory for the team. Whether it’s a new framework on top of existing architecture, or an entirely new system like Machine Learning or “AI.” A feasibility prototype is designed to validate and assess the performance of the tech itself.

This is likely one of the few prototypes that does not need users. The goal of this prototype is to allow the development teams to gain confidence and reduce the risk of a potential solution. One of the side benefits of a feasibility prototype is that the act of building the solution may present alternative ideas or paths to solve the same problem. This method also helps developers feel invested in the solution, they’re getting to be involved in the process, rather than just coming in at the end to “code monkey” a design across the finish line.

User Prototypes

This is likely the most common understanding of the word “prototype.” A User Prototype is, as Cagan puts it, “a simulation. Smoke and Mirrors. It’s all a facade.” There’s nothing real about a user prototype. While some might consider this description overly ambiguous, it’s about as specific as we can get given the large spectrum of work that falls into this category.

User prototypes can be any level of fidelity, from a barely roughed out interactive wireframe, to a full-featured high-fidelity prototype that appears to function as the “real deal.” The value of a user prototype tends to come in the form of idea validation. It’s great to get feedback on an overall design or to solicit input on the placement of interface elements, as well as communicating how a product may work once developed.

The main drawback to user prototypes is that they rarely have the ability to prove their value. Users may tell you they love an interface design and still end up not using it for one reason or another.

Hybrid Prototypes

The last prototype I want to touch on is the Hybrid Prototype. For me, this is the most interesting of the prototype categories, because it combines different aspects of all the other types in interesting ways.

A common hybrid technique is the Wizard of Oz prototype, as the name implies, the idea behind this technique is to create a “real world” front-end experience that your users interact with, while having an actual human “behind the curtain” completing the tasks that the system would accomplish if built.

One of the major benefits of this type of technique is that it allows you to quickly and relatively easily create a functioning system from the user’s perspective, without having to spend the time or resources to built out the actual tool. This allows product teams to immediately start collecting feedback on “how the system works,” and see if the solution meaningfully impacts a user’s experience with a product.

The counter to the ease and speed of this technique is the abysmal ability to scale this sort of prototype. Because real people are doing the work behind the scenes, any ability to scale this solution requires bringing on more people. This type of prototype is best for small-scale and rapid idea validation and data collection. It’s important to understand these limitations going into this type of prototype and accept that due to the scaling limitations this will need to be converted into a real solution in the long term for success.

Testing with Experiments

If a prototype is the artifact that is created, an experiment is the process of taking that prototype and making it available to real users in order to obtain valuable feedback on the proposed solution.

As with prototypes, there are many types of experiments and tests that can be run. The four main things we often test for are User Value, Usability, Feasibility, and Business Viability. While it’s not required to tackle these concerns in order, it typically makes the most sense. Before doing anything else, it’s important to understand and confirm there is user value in the solution, from there we make sure it’s something they can actually use. Once we have those two problems nailed down it’s time to meet with the development teams and make sure the proposal is actually feasible to build within the timeframe, budget, or other product constraints. Finally, once everyone agrees on those items, we can work with the rest of the organization to understand how the overall business might be impacted by the solution.

Testing for User Value

This might be the most important set of experiments when it comes to product discovery. At the end of the day, if an idea or solution does not provide lasting, meaningful value to our users it doesn’t matter how good everything else is, the wont use or buy it.

Creating and providing user value is at the core or product development, once we know that our users see the value of a solution we know we’re working on the right thing. Three metrics for understanding and determining the user value of an idea are: User Demand, Qualitative Value, and Quantitative Value.

Experiment for User Demand

A common, and relatively low-risk, experiment that teams can run to collect data on and validate the demand for a feature is called the fake door or door to nowhere experiment. The idea behind this experiment is to place a call-to-action in your product and track the people who interact with it. The cta does not take the user to the proposed product or feature when clicked, but instead can direct the user to a message or landing page indicating that your team is collecting data and soliciting feedback on the creation of the feature.

The main reason this type of experiment works is because there should be no indication to the user before-hand that the proposed feature or product does not exist. The act of clicking on the call-to-action is then a true metric of the user wanting to see or use the feature.

If you decide to collect user data and contact information, this type of experiment can also generate a list of users who are ready and willing to engage in conversation with you specific to the proposed feature or product.

Experiment for Determining Qualitative Value

Qualitative Value is the “meat and potatoes” of a product. While demand and quantitative data can let us know if people want, and how they’ll use a product, qualitative value is the why.

A common experiment to determine and understand Qualitative Value for users is the usability test. Sitting down with actual users and having interview style discussions with them where you determine what they’re looking for in a solution, and why they feel like that might meet their needs.

Unlike quantitative value, qualitative value is going to be different for each individual. Collecting meaningful qualitative data is like turning over the pieces of a puzzle, each new piece reveals a little more about the problem and guides you towards the solution.

Experiment for Determining Quantitative Value

Quantitative Value experiments are where product teams can gather large amounts of real evidence on what users are doing, sometimes to the point of statistical significance. Quantitative value is all about collecting data, and using that data to inform product decisions.

The gold standard that most product people are familiar with is A/B Testing. In an A/B test users are shown one of two (or more) different solutions to a user problem. The key is that they are unaware of the test taking place, or which version they are on. In the discovery phase of product development this sort of experiment might look like a relatively small percent of your users (1-3%) receiving the “B” version (typically some form of high-fidelity prototype), while the rest of your users remain on the existing “A” version (your actual product). This type of testing can often provide predictive results of how real-world users would use the new product or feature.

Product Feasibility Experiments

Much like the feasibility prototype, a Feasibility Experiment is working with the engineering team to answer as many potential unknowns as possible. Some of the questions you may look to answer with a feasibility experiment are:

Do we know how to build this?
Do we have enough time to build this?
Do we understand the dependencies involved?
How will this solution scale?

The end-result of a feasibility experiment is the feasibility prototype mentioned above. The process of running a feasibility experiment is just as important as any other. Bringing in the engineers and giving them the time and space to explore and answer these questions saves time and avoids future roadblocks. It also provides ample space for the team to have discussions about specific needs or requirements, and may even provide alternative routes to the solution. Your engineers want to create something they can be proud of just like the design and product teams, giving them opportunities to be involved helps contribute to the overall health of the product team.

Validating Business Viability

When talking about establishing and validating Business Viability the basic idea is to ensure that all of the different parts of the organization are in alignment with how to build, market, sell, and support the solution. Business viability involves contact with all of the departmental stakeholders that have touchpoints with the product, from speaking with legal to determine things like whether or not you can sell in specific regions, or localization and accessibility requirements, to ensuring sales has a path to market for the product and support has the resources to help users who run into issues.

Closing Thoughts

Product Discovery can often be the most daunting and overwhelming part of the product development lifecycle for someone who is new to the process. Everything listed above and more is all done before we’ve decided to commit to building and shipping any potential solution.

The idea behind this rigorous process however, is that when we do finally decide to build something, we’re pretty darn sure it’s the right thing to build. Successful product teams know what methods, techniques, and processes to use at the right moment to get the right data in order to de-risk ideas and inform decisions.

Sometimes you get lucky and strike gold with your first idea, other times you just keep making the best decision you can in the moment and work towards that success over time with careful planning and deliberate decisions. Keep providing value and your users will thank you.

March 31st, Q1 Update

Sun, 31 Mar 2024 16:00:00 GMT

Happy Easter! Can you believe March is over already? With the month coming to a close we’re officially 3 months into the year and Q1 is over, time to do a check in on goals, progress, and life.

Writing

I’ve managed to keep up with my desired 1 post a week. While some weeks are harder than others, I feel like it’s getting easier to write. One of the main drivers for me behind the 1 post a week goal was to improve my writing, and get more comfortable sharing what I know.

I also published my first longer “essay” style post. It’s no Josh W. Comeau interactive deep-dive, but I am proud of The Box Model for Design. I think it does a pretty good job touching on the highlights of what the box model is, and why it’s relevant to designers in their work.

Some other notable writing highlights include:

Config

While Config is still a few months out yet I’ve got my ticket, flights, and hotel booked. They also just announced their speaker line-up, and I’m pretty stoked that it’s being hosted by Cassidy Williams.

In addition to all the new features Figma is sure to announce I’m excited to get to hang out with some amazing people, I’m hopeful a good chunk of the DTCG will be there and we can chat and enjoy some drinks.

Accessibility Work

I haven’t been able to make much progress on the Accessibility Playbook these last few months, but that’s because I’ve been spending a significant amount of time working with my teams to understand and address accessibility issues within some of our products.

There’s been some confusion on a couple teams around a few specific success criteria and I think there’s something worth writing about here. I look forward to taking the time to deep dive these topics and hopefully provide some valuable information, not just for my team, but for anyone else struggling with the same issues.

General Life Updates

Gideon turned 2 this month! It’s been such an incredible journey being a parent. I love watching his little mind at work, it’s so rewarding to see all the little lightbulbs turn on as he makes new connections about the world around him.

Flip side of that coin is that we also have a toddler now, and we got to experience our first “chain of sick” in the house. Over the last few weeks Becca got it first, then Gideon, and I thought I was in the clear. Turns out I’d just not get it until this last week. It’s been a bit of a challenge to keep the house functioning when half the team is sidelined, but we’re all on the mend now and hopefully we’re in the clear.

Media Consumption

Books

I’ve started quite a few books this year, but I’ve only managed to finish a few so far. Some highlights:

Change: Started and enjoying so far. Recommended by Nathan Curtis when he did a webinar with Knapsack on design systems.
Inspired: In Progress. This seems to be the “go to” starting point for a lot of recommended reading lists around Product Management. I picked it up because I’m interested in a couple of the other Silicon Valley Product Group books, and figured I might as well start with this one. So far it’s pretty much what I expected, no complaints.
Subtract: Started, put on hold for now. I really wanted to like this book, and I think the concept is solid. It’s just been a bit of a slow read so I put it down for a bit. Hoping to pick it back up in the next few weeks and finish it.
Escaping the Build Trap: Completed. We picked this as a book-club read for our work Product Management book club. I ended up reading the entire thing in 1-2 sittings. I really like what Melissa Perri talks about in this book, and think it’s a solid read. My biggest complaint is that a lot of the actionable advice feels like it’s directed at Senior Management or higher. There’s not a lot that an individual can do if they’re stuck in a system that rewards the wrong behaviors.

Podcasts

I’ve really been enjoying the last few months of ShopTalk and Syntax. Syntax having started a video podcast has been cool too, I’ve chosen to watch a few specific episodes when the content is likely more visual in nature. The addition of CJ to the team and the standalone videos has also been a great new reference resource.

I get a lot of non-web related tech news from the LTT WAN-show every week. It’s become more common than not for it to become a 3-4 hour show, so it’s a become a great casual listen when working on side projects or doing the dishes. It’s easy to split up into multiple smaller listens.

Movies and Videos

Managed to get through a few movies, and series over the last couple months. Having a dedicated date to commit to a movie help a lot when the hustle of the week makes it easy to want to sit in bed and doom-scroll TikTok. Here are some highlights:

Barbie: I genuinely don’t understand why people got so upset over this movie. I thought it was great.
Damsel: Overall I thought this movie was enjoyable, if not mildly predictable. I don’t think it was trying to be overly bold or new, but it was a fun modern romp through a more classical trope.
The Zone of Interest: This one took a couple of days to get through, not because the content is exceptionally graphic or hard to handle, but because it really is a movie that demands your attention to get the most out of it. Very interesting portrayal of a horrific time in human history and definitely worth a watch.
Yu Yu Hakusho: After hearing pretty good things about the live action adaptation of one of my favorite “late night toonami” anime I decided to give this a watch. I enjoyed it, i feel like they were able to retain a lot of the camp and edge-lord charm that makes the anime so good without feeling like a joke.
Hazbin Hotel: I crushed every episode of this show the day it came out. The overall narrative is great, but the real charm is the characters and their own personal stories and relationships. The music is also phenomenal. Season 2 isn’t expected until 2025, but it’ll be a happy day in hell when it arrives.

Video Games

Most if my free time this past month was dumped directly here. Final Fantasy 7 Rebirth was released on Feb. 29, and I’ve only been able to spend a couple hours a night playing through this gorgeous part 2. It’s been a real joy to get to see all of the characters again and engage in some of the major set pieces from the original in a new way. I’m sure it’ll be a couple more years before we get the conclusion of this story, but I couldn’t be happier with what we got this time around.

Looking Ahead

Overall I think Q1 has been pretty successful; looking at Q2, I’d love to get to spend some more time working on the Accessibility Playbook and writing about accessibility. The DTCG has officially kicked back off in 2024 and I’m excited for the work we’re doing. Hoping to write some more about Design Tokens and the fantastic people working on them.

I’m also hoping to find some more time to dedicate to the rebuild and redesign of this site. I’ve been really enjoying using Astro for some smaller proofs and quick projects, but haven’t been able to carve out dedicated time to focus on this site.

That’s about it for this quarter. Looking forward to seeing where I’m at in the next one.

Site Rededesign is Live

Sun, 04 Aug 2024 16:00:00 GMT

Shorter post today.

After a few months of delays and reworks I finally decided on an overall theme for the site, put together the design, and got it out the door.

I’ll write up a longer overview and breakdown later on, but I’m super happy with the final result and even more so that it’s finally out the door and I could remove the construction banner at the top of the site.

I hope you enjoy it as much as I do, and I look forward to writing about it some more.

Research Beyond Usability Testing

Sun, 19 May 2024 16:00:00 GMT

Often when I hear designers talk about user research they’re specifically referring to one of two things, usability testing, or validation testing. While there two types of testing are important, there’s so much more in the user testing toolkit that we can use.

Usability and validation testing by their very nature take place fairly late in the product development lifecycle. It’s not until you have something built or prototyped that you can partake in these methods. How do you decide what things to pursue building? How do you know you’re focused on the right thing?

What Defines Research?

According to the dictionary research is defined as: “They systematic investigation into and study of materials and sources in order to establish facts and reach new conclusions.”

By this definition, anything from talking with customer support agents, to looking at analytics falls under research. Often times CS is siloed into it’s own department, and has very little communication with design or product management unless there’s a massive issue. Looking at usage data and analytics can be seen as the job of a business analyst.

If we want to understand where are users are hitting pain points that we can resolve, or where users bounce, or spend most of there time, looking at this data and working with these people is imperative.

Just Enough Research

Stealing the title here from Erika Hall’s book. When thinking about what paths to pursue and what features to build we need to know just enough to make a decent bet. Talking to users is always going to be valuable, but it’s not always viable, and you can’t be certain that the people you’re talking to are representative of your larger user base, survey bias is a thing after all.

This is where data comes into play. A user can’t lie about the actions they take within a product or experience. Knowing what data to collect and pay attention to is able to provide near “real-time” information on what your users are doing. Tracking user flows and navigation through an app allows you to look at trends emerging in the data. Is a large quantity of users bouncing from a specific page? Are user’s navigating to, or between, a select group of pages? With this information we can understand and highlight flows that may need to be promoted within navigation, or take some time to explore what about a specific page might cause users to leave.

This same analysis should be used pre-emptively and throughout the product development lifecycle to validate assumptions and reduce risk of proposed work. If you assume that making a change to feature X will improve user behavior Y, run a scale experiment, doing as little work as possible. Did the change you proposed move the needle on user behavior, or did it reveal a different problem that you actually need to solve?

Avoiding Footguns

You just launched a killer new feature! Pop the champaign and pay out the bonuses! A few weeks go by and you notice usage numbers aren’t really increasing. You’re feature is seeing good adoption across the user base, but the overall numbers aren’t really improving.

Turns out that as part of your latest release you unintentionally caused a negative impact on another core part of your app. Without looking at and understanding usage data you might not have caught this issue.

Another great thing about collecting and analyzing usage data across multiple products and flows is that you can see how any new feature or release impacts other parts of your application. Ideally you notice and catch these trends while running testing or experiments, but even post-launch you need to be monitoring and comparing data to understand the impact you’re having.

RSS Renaissance

Wed, 24 Jan 2024 16:00:00 GMT

It sure seems like RSS is having a moment right now, with all the talk around slow social, human curation, etc. I think Chris put it really well in his post, so I wont rehash a lot of what has already been said.

One this I did want to expand on was the experience he describes of RSS being either really lonely or incredibly overwhelming when you first get started. These were both my experience when I first started looking into following people with RSS feeds.

When you first decide to dive into an RSS reader you’re met with a big blank nothing. You need to add RSS feeds in order to have things show up and be able to read them. Many reader apps have a nifty “tell us about your interests and we’ll suggest or add some stuff” feature, but personally when I tried to use these in the past it either was not specific enough, or it suggested content farms which blow up your feed and make it unruly to manage.

Following something like The Verge is a sure fire way to get flooded with content that may or may not interest you. Even someone like John Gruber over at Daring Fireball can be a bit overwhelming with the amount of content he puts out (definitely still worth checking out though!).

I really like the suggestion of starting with the RSS feeds of people you already like and/or follow as well as a few aggregators/curators. When I restarted my RSS journey this past year I made the conscious decision to start small and grow the network of people I follow organically over time. This has produced a steady stream of “content” that I enjoy consuming, and allows me to feel like I am still connected to what is currently happening in the community through people who’s opinions I value and trust.

If you’re interested in getting started here’s a few I think are great:

Chris Coyier - https://chriscoyier.net/feed/
Dave Rupert - https://daverupert.com/atom.xml
Rendezvous with Cassidoo Newsletter - https://buttondown.email/cassidoo/rss
Smashing Magazine (A little busy, but typically topical and relevant) - https://www.smashingmagazine.com/feed/

Shared Lexicon

Sun, 26 May 2024 16:00:00 GMT

Our research team showcased Dovetail to our team this week. I’m looking forward to spending more time with the product, but something mostly unrelated to the product stood out in their demo.

While walking us through the tool they kept having to specify that some of the words they were using meant different things in Dovetail than it might in other contexts. Words like Insights or Reports have a specific meaning in something like Dovetail, that may not directly translate to the initial idea that pops into your head when thinking of those words.

When working with large teams that have varying levels of experience or knowledge with different tools or workflows it becomes more and more important to have a shared vocabular, preferably one that is defined and referenceable, so that everyone on a team or in a meeting understands what they’re discussing in the same way.

Speaking the Same Language

The simplest way to go about creating this shared vocabulary is to take some time to document these words. It may not be the flashy design work that winds up winning awards, or being the star piece of a portfolio, but it’s no less critical to the production of great work.

In the same way that design teams create personas for reference when discussing specific users, this glossary is a reference document that outlines and defines what works mean when used within specific contexts.

A great example of this is the word Report, depending on the team, tools, and processes in use, a report could be any number of things. As stated above, a report in Dovetail is a specific organizational artifact, in an analytics tool like Pendo a report is a detailed summary of a set of queries or actions. When talking to Customer Support or Sales teams a report could be a written document that outlines additional user wants or needs.

Speaking the same language allows us to ensure that everyone is on the same page when having conversations around what is important. When we understand the details at every step of the product development process we can make decisions faster, and avoid rework because of a miscommunication.

Site Redesign Retrospective

Sun, 11 Aug 2024 16:00:00 GMT

When I migrated my site from Eleventy to Astro I was more concerned with making sure everything was functional. The overall design of this site has been something that has bugged me for the last 8 months; the blue and gold didn’t really feel like me, it was more a placeholder than anything else. I wanted a visual language that was clean, but poppy. Something that felt like it spoke to the combined set of skills that I have as a product polyglot.

Additionally, as I’ve been rethinking design systems and CSS architecture in general, I wanted to try my hand at creating and using some newer patterns. The biggest change being a shift away from strict BEM naming, and the adoption of the ideas from CUBE CSS and Every Layout. In it’s time I think BEM served my team and others incredibly well, it gave us a solid framework for thinking about and naming components. However, in today’s component-based ecosystem and with things like scoped styles, the strict structure of BEM isn’t really needed. Components have the ability to encapsulate styles within them, removing the need for the strict block__element--modifier dynamic, if code can’t escape the component, we need not worry about it colliding with another bit of code.

The Design

Originally the scope for the design of this site was significantly larger. I had created a few different themes for the site when it was on 11ty, and had hoped to continue with that idea for the new build. For now I’ve decided to scrap the idea and focus on a single interesting theme that I feel captures my vibe. Thankfully because the entire site is styled using CSS Variables, multiple themes in the future is not off the table, and I’m sure I’ll revisit the idea later, even if just to put out a light mode.

The design language I ended up using is pretty heavily inspired by the Monokai text-editor theme. It’s been my go-to editor theme for the past 2 decades, and has survived the transition from SublimeText, to Atom, to VSCode. I’ve never liked “pure black” sites, so the “almost black” of a text editor felt like the perfect base. From there I grabbed 6 of the syntax highlight colors and applied them as accents, each one relating to a different section of the site.

Writing content is accented with the blue color.
Work content is pink.
Projects are green.
And finally anything related to the About section is orange.

The last two accents are purple and yellow. I haven’t found a major need for these yet; but the home link does turn purple on hover, a nice little surprise if you ask me.

Something that I wanted to make sure to consider with the design refresh was providing a consistent means of wayfinding as you move through the site. Links across the entire experience are highlighted in their respective accent colors. If you’re on a page and all of the links are blue you know you’re on a /writing page, if they’re pink you’re in the /work section. There are a few exceptions (as with all good rules), the homepage for example links to all 4 sections; and is not it’s own, so it uses all 4 colors, depending on where the content takes you.

The Build

Originally when I picked Astro as a new framework I was looking for something that used similar tooling to what my teams use in our day-to-day work. While a few layers deep, Astro uses Vite and Rollup under the hood. This meant that I got a blazing fast local setup, and was familiar with all of the plugins at my disposal.

Something I wasn’t as familiar with, but have come to develop a great appreciation for is Zod. Having the site’s content by type-safe has forced me to get more familiar with typescript, and has provided another layer of consistency. The ability to enforce specific content existing, and then knowing the exact shape that data will take allows components to be a little smarter in how they expect data to be supplied.

Speaking of; refactoring the entire CSS architecture of this site has significantly impacted how I think about components. I’ve been a pretty big fan of separating the structure and style of sites for a while, but I hadn’t had the chance to really test these ideas on a full build until now. This is where CUBE CSS comes in, CUBE (Composition, Utility, Block, Exception) is a methodology for thinking about and writing CSS that emphasizes working with the cascade, rather than running up against it. The majority of your structural and layout styles come from the composition layer. Specific visual treatments are then applied through the block layer. The main benefit here is that because compositions are pure structure you can reuse the them for anything, greatly reducing the duplicate layout code across components.

From a design system standpoint the team working on Polaris over at Shopify has created stand-alone components that provide these compositional utilities to their developers. I’ve already begun talking with my team at Discovery Education to see how we can implement something similar.

Finally, I want to give a few shoutouts to some other amazingly smart people who I’m standing on the shoulders of:

I adapted Lea Verou’s tagging methods for this site, along with the idea of “orphan tags” and having them link directly to the post instead of a listing page with only 1 result.
I’d heard about the bio selector previously, but playing with it on Jason Lengstorf’s site was the motivation I needed to add it to mine. It brings a little bit of on-page interaction and playfulness to an otherwise relatively-boring and static homepage.

Still Todos

Some of the previously existing components still need to be refactored to take advantage of the new CUBE architecture.

Astro has first-class support for view transitions and it’s something I’d like to look into. New web tech is always interesting, and their dynamic nature could bring additional interest to a static site.

As mentioned in the design section, I would like to provide at least a “light mode” for users who prefer that color scheme.

Taking Astro’s Starlight for a spin: Design System Documentation

Sat, 10 Feb 2024 16:00:00 GMT

This past week I spent some time exploring using Starlight as a potential replatform for our design system documentation. The major reason I was drawn to starlight is that because it’s built atop Astro, it has support for all of the major players in the UI framework market. Our current system is built in Vue, but if we want to explore web components (with or without lit), or service another team using react we have the ability to pull all of those components into a single place using Astro’s framework integrations and islands architecture.

Overall I’m pretty happy with the product for the short time I’ve had playing around. It’s a great system for quickly getting a doc site spun up and feels very similar to something like VuePress or VitePress from a general layout and design perspective. I’ve got to spend a bit more time kicking the wheels before we make any major investment in a replatform but I wanted to share my initial thoughts.

The Good

Startup and Performance

Unsurprisingly setting up a Starlight project is just as easy as setting up any other Astro project, because it is an Astro project. Starlight has a few additional configuration options in the Astro config provided through the starlight integration. These options are mostly to set up things like the main sidebar navigation, or to include any external files and resources.

Because starlight is basically just an Astro project you get all of the performance of an Astro project right at the beginning. Builds take practically no time, and everything is rendered SSR by default and served as HTML unless you’re using client-side hydration.

Theme Customization

There’s a fair bit of theme customization out of the box. Working in design systems I am always likely to want more than what any “out-of-the-box” solution can provide, but I was pleasantly surprised that the light and dark themes, as well as many other defining attributes; like page width, are defined as CSS variables and can simply be overridden in a custom CSS file.

The Starlight team has gone so far as to put a full section in their docs about the theme customization as well as a nifty tool that will live-update the docs as you’re viewing them and provide the necessary CSS Custom Properties to you so you can plop them right into your code knowing the result they will provide. Neat!

The Bad

Component Issues

I don’t feel like I can 100% blame Starlight for this but I spent the better part of 2 days trying to get our design system components imported into the project. We export cue components as an NPM package, I’ve got the package installed, and can reference other items and files in the package, but for some reason when trying to import the components, nothing.

My biggest gripe here is the silent failure. There’s no error informing me of what I’m doing wrong. When I don’t use the client directive, I’m at least informed that our components do not have a template or render function embedded into them, but when using client:only=“vue” there is no error indicating that the component isn’t going to work or load. All I get is an empty Astro-island element on the page.

As I said before, I’m not even sure this is Astro or Starlight’s fault. When I grab the code for a component and manually add it to a .vue file within the project itself it works a peach. This makes me believe there is either something wrong with how I am importing the components or how we’re exporting them in the package. My complaint with Astro/Starlight is that I am hitting a brick wall in debugging because I’m not even sure what is going wrong.

Default styling

While I mentioned the customizability and theming options in the good section, I do feel that some of the Starlight team’s styles, or rather selectors, are a little bit of a pain. They’re quite high in specificity, and I’ve noted at least a few times where I need to either construct an oddly specific selector or, even worse, use an !important.

I believe the Starlight team is already aware of this issue and I think they agree, at least somewhat, since they’ve opened an issue to explore using CSS @layer properties to house their base styles so that they’re easier to override. This gives me hope and I look forward to the update.

Features I’d Love To See Added

Templates

I did not love that there are only two templates, no way to create custom templates, and no way to extend the existing templates. First, the existing doc template covers like 90% of my designed use-case, and that is an amazing accomplishment in its own. I just wish I could add a couple things or make a few tweaks.

A simple example of this is the description frontmatter that is optional within doc pages. By default this property is only used for additional page metadata for a browser or social links. I’d love to be able to use this property within the header of a page and place it under the title. There’s no way to do with within the product as it sites now. There’s no way to edit or extend the existing templates, and trying to use a template other than doc or splash results in a type error.

Similarly to the default styling issue there’s already a related issue open on the Starlight GitHub. It does look like it’s only for custom templates right now, but another promising development.

Systemic Improvement is a Snowball

Sun, 07 Jan 2024 16:00:00 GMT

Over the winter break from work I picked up a new game on Steam called Against the Storm. Against the Storm is a rogue-lite city-builder/management sim. Like many other city-builder or management sim games the goal of any specific “game” or “round” is to complete objectives and create a thriving settlement.

The interesting twist in this game is that every settlement takes place on a larger world map which itself exists within a persistent world. You explore the world creating settlements within a single “cycle”. When the cycle is over the world map resets and you start all over at the center of an unexplored map again. This is where the rogue-lite features come into play. When you complete settlements, and other meta-goals you can begin to unlock persistent improvements and perks that make your experience easier, and allow you to try to tackle harder difficulties or new challenges.

The systems in this game feel like an interesting and pertinent allegory for Design Systems. As you continue to work with product teams and make seemingly small improvements you “unlock perks” that make the same work easier for other teams, or allow your teams to begin looking at and tackling harder problems.

Much like in the game, each incremental improvement may not feel incredibly meaningful in a vacuum: 2% less fuel consumption, or a single button component may not feel or look like a huge deal; but when combined 5x over, or with other improvements it means that your settlements and teams do not need to stress over these things and can shift their focus to more meaningful investments and improvements.

The real world is a lot like a rogue-lite game in this sense. Everything you try something; even if it doesn’t pan out, you gain something. That might be experience and knowledge, or even a new pattern or component. All of these “persistent benefits” continue to grow on each other and eventually become a snowball rolling down a hill.

Just an interesting relationship I noticed while playing and thought it might help someone who may be too focused on the small improvements and missing the overall growing improvement that every little win provides.

If you’re interested in city-building or management sim style games I definitely think it’s worth a look and provides some interesting gameplay and challenge mechanics.

Systems of Harm

Sun, 21 Jan 2024 16:00:00 GMT

import PostLink from "@components/PostLink.astro";

I've recently started listening to the Systems of Harm podcast by Amy Hupe. It's a short (6 episodes) series of podcasts discussing design systems and probing into how in addition to speeding up the design process they can also accelerate and perpetuate systemic harm.

Of particular interest to myself is the episode with Fred Warburton where they discuss Accessibility. Fred and Amy talk about their time at Babylon Health and some of their experience's tackling accessibility. One of Fred's comments is that it wasn't like anyone had set out to create an inaccessible experience, or that they wanted to exclude anyone, but if no one is pushing for the work to get done, or if there is not a direct connection within the organization; it's easy for it to be forgotten or overlooked when all other priorities are also jockeying for attention.

As designers, developers, and curators of large-scale systems it is our job to understand and investigate the why behind our decisions and do the hard work of understanding the effects that our decisions can have on all of our users.

One of my team's major goals for 2024 is to establish a cross-functional working group within our organization to not only ensure “Our components are accessible,” (In a vacuum, with no other code around*), but also to document, spearhead, and encourage others to truly experience and understand how our products work for all kinds of users, across multiple disability categories; and work towards constantly improving the experience.

Understanding Outcomes

Sun, 16 Jun 2024 16:00:00 GMT

As we look towards planning for Q3, the product teams I work with have started their quarterly product increment (PI) planning. One thing that came up this week was how to understand or find the outcome for a specific goal or problem.

It’s easy to fall into old projects traps such as “we should add this new feature,” or “I’d like to update the design of this page.” These are common outputs that a lot of teams and individuals new to the product model may be drawn to as it feels like a meaningful step towards “doing something,” but unless these features or design updates are tied to a specific business or user outcome they’re a pitfall back into the build trap.

One PM brought up the following question:

I don’t think “User Enjoyment” is an outcome, in the sense that it is not a measurable human behavior. It's definitely my Goal, but do I still need to come up with a separate measurable Outcome that drives that Goal?

One member of the product management team suggested this might be a good “5 whys” exercise, another pointed out how “enjoyment” is an incredibly subjective metric and as such is difficult to measure.

I love this question, because it showed that the individuals in our product teams are really working to understand how to move to the product model, and digging deep in trying to understand what is important.

Outcomes Defined

My personal preferred definition of an outcome is “A measurable metric of success; often a change in behavior, that is mapped or aligned to a specific business or product objective (OKR).” What this means is practice is that in order to be an outcome, whatever we’re looking at needs to be measurable, and drive towards the success of a stated objective for the business or product.

For the example above, “User Enjoyment” on its own would not qualify as an outcome, what does improving this metric result in? What is the business or product objective?

By forcing alignment with an objective we can begin to understand the framing around how we might build out our outcomes. If our business objective is growth and retention, and our product objective is an increase in the completion rate of a task, what sorts of behaviors can we modify in order to achieve these objectives?

If we increase how engaging or enjoyable the task is we might see an uptick in completion rates, now we’ve got a measurable outcome that ties back to the original question of how to make “User Enjoyment” more concrete.

Outcome-Driven Product Development

When we use the lens of outcomes to examine product decisions we focus more on the why instead of the how and solutions can come from multiple places. No longer is success defined by what or how much we build, but instead by the impact we have on user and business goals. Product teams are empowered to truly understand their users and dig deep into all of the potential avenues that can solve their problems. This collaborative and exploratory process creates the space for novel and robust solutions that often drive companies to greater success and user loyalty.

User-Centered Design Principles

Sun, 08 Sep 2024 16:00:00 GMT

User-Centered Design is a common approach to creating products that truly resonate with users. By focusing on the needs, wants, and limitations of the end-user at each stage of the design process, we can ensure that the final product is not only functional but also enjoyable. In this post, we will explore three core principles to effective User-Centered Design and delve into how these principles can be practically applied to create products people love.

Understanding User Needs

At the core of user-centered design is obtaining a deep understanding of the user's needs. This involves conducting extensive research; including interviews, surveys, and usability tests, to gather detailed insights into what users desire from a product. Understanding user needs goes beyond simply how a product works or what it does. It encompasses emotional responses, pain points, and the context in which the product will be used. By prioritizing these needs, designers can create more intuitive and user-friendly interfaces.

Methods for Understanding User Needs

Background Interviews: Conducting one-on-one interviews with users can provide in-depth insights into their experiences and expectations.
Surveys: Surveys can reach a larger audience and gather quantitative data on user preferences and behaviors.
Usability Tests: Observing users as they interact with a prototype or product can reveal usability issues and areas for improvement.
Contextual Inquiry: This involves studying users in their natural environment to understand the context of use and uncover hidden needs.

This principle emphasizes empathy, as it requires designers to put themselves in the users' shoes and see the product from their perspective. Empathy maps and user personas are valuable tools that can help designers visualize and understand the user's journey.

Iterative Design Process

Another key principle is the iterative design process. User-centered design is not linear; it involves continuous cycles of prototyping, testing, and refining. This iterative process allows designers to make incremental improvements based on user feedback. By repeatedly testing and tweaking the product, designers can identify and fix issues early, ensuring that the final product meets actual user expectations.

Steps in the Iterative Design Process

Prototyping: Create a preliminary version of the product or feature. This can be a low-fidelity sketch or a high-fidelity digital prototype.
User Testing: Conduct usability tests with real users to gather feedback on the prototype.
Analysis: Analyze the feedback to identify patterns and areas for improvement.
Refinement: Make necessary changes to the prototype based on the feedback.
Repeat: Continue this cycle until the product meets the desired level of usability and user satisfaction.

The iterative design process is flexible and adaptive, allowing designers to respond to changing user needs and technological advancements. It fosters a culture of continuous improvement and innovation.

Involving Users Throughout the Design

The third principle is involving users throughout the design process. This means actively seeking user input at every stage, from initial concept development to final implementation. User involvement can take many forms, such as co-design workshops, beta testing, and regular feedback sessions. By collaborating closely with users, designers can ensure that the product evolves in a way that aligns with their expectations and needs.

Techniques for User Involvement

Co-Design Workshops: Engage users in collaborative design sessions to brainstorm ideas and create prototypes together.
Beta Testing: Release a beta version of the product to a select group of users to gather early feedback and identify issues.
Feedback Sessions: Regularly meet with users to discuss their experiences and gather suggestions for improvement.
Online Communities: Create forums or social media groups where users can share their thoughts and interact with the design team.

Involving users throughout the design process builds a sense of ownership and loyalty among users. It ensures that the product remains user-centric and adaptable to changing user needs.

Conclusion

User-Centered Design is a powerful approach that can significantly enhance the usability and appeal of a product. By understanding user needs, adopting an iterative design process, and involving users throughout the process, designers can create products that are not only functional but also delightful to use. Embracing these principles can lead to more successful and user-friendly products in today's competitive market.

User-Centered Design is not just a method; it is a mindset that prioritizes the user at every step, ensuring that the final product is both meaningful and impactful. As the market continues to evolve, those who adopt these principles will be better positioned to create innovative and successful products that stand the test of time.

Exploring Multi-Brand Systems with Tokens and Composability

Fri, 19 Dec 2025 16:00:00 GMT

import PostLink from "@components/PostLink.astro";

Design systems aren't just about keeping everything looking the same; they're about making things flexible enough to handle whatever gets thrown at them.

In this article on the Frontend Masters blog I dive deeper into how tokens, composition, and configuration are used to create flexible and extendable components that allow a design system to handle the diverse needs of modern product teams without breaking.

Nasa's Deleted 'First Woman' Graphic Novels

Tue, 15 Apr 2025 16:00:00 GMT

import PostLink from "@components/PostLink.astro";

In 2021 and 2023 NASA issues two interactive graphic novels under the title “First Woman.” According to their press releases they were about “...the story of Callie Rodriguez, the first woman to explore the Moon,” and “...a diverse crew of astronauts on the Moon's surface who learn and grow as a team, navigate the unexpected, and conduct experiments and technology demonstrations for the benefit of humanity.”

Because our government has seen fit to cleanse the internet of any mention of the accomplishments of women, poc, and queer folk, these books were pulled from their internet platforms. Thankfully they've been saved and archived by the wonderful people of the internet and are available through Wikimedia.

You can download them here: Volume 1: Dream to Reality, Volume 2: Expanding our Universe

In the face of authoritarian overreach, we have to actively resist. The people of the internet never forget. Keep preserving knowledge and sharing stories.

Using composability over inheritance to scale design systems

Tue, 04 Nov 2025 16:00:00 GMT

import PostLink from "@components/PostLink.astro";

Design systems don't scale by locking things down—they scale by opening them up.

I wrote a piece for Zeroheight on why composability wins over inheritance when it comes to building systems that actually work for teams. Instead of bloated libraries and endless one-offs, composability lets you:

Mix and match flexible parts
Move faster without breaking the system
Contribute back patterns that make the whole thing stronger

Building scalable design systems with Figma: 26 tips for 2026

Mon, 19 Jan 2026 16:00:00 GMT

import PostLink from "@components/PostLink.astro";

Kick of 2026 with 26 tips covering:

Figma variables, styles, and components
Design ops
Documentation and onboarding
Partnering with engineering

If you're working on design systems in figma you're going to want to check this one out!