One of my goals for this year is to get a better handle on the financial picture of the business at Button School, so this week, I’ve been working with some spreadsheets and trying to figure out ways to understand and visualize the data better for myself.
I have transaction records for course sales in Airtable and Stripe, as well as bank records, all of which I can download as CSV documents.
At first I tried messing around with the data as spreadsheets, which meant trying to piece back together how pivot tables work, and lots of trial and error with the chart generation settings in Sheets and Numbers. I was able to get some workable charts breaking down revenue by month, for example, but I could really only reasonably do this for one source of records at a time, and started running up against a wall when I wanted to combine data sources and do more advanced filtering.
I had another problem: how many steps was I going to have to either write down or remember to perform in order to get from the raw data to a usable visualization?
This seemed like a situation that called for firing up my text editor and writing some code. But how to start?
This is the point where I often get a bit stuck trying to decide how to proceed, thinking about what would be the best way to build something like this. I tend to prefer light-weight solutions that will be easy to maintain over time, but that I also won’t mind throwing away and starting over from scratch. (For various reasons, I also tend to shy away from low- and no-code solutions, since—well—how is that going to be expressive and precise enough?)
In this case, luckily I remembered that the team at Observable had somewhat recently released Observable Framework, an open source static site generator that seemed like it should give me a lot of what I might otherwise look for from something like a Jupyter notebook, but with the benefit of allowing me to work in JavaScript (which I’m more comfortable with than Python) and first-class support for D3 (which produces visualizations friendlier to my soft-hearted designer sensibilities).
I fired up a new project locally with some suggested examples to start, looked through what was there, and then… crickets.
Reading through the docs and looking at the examples, I could see that there were some nice ways to import data from a local CSV file to work with, but being unfamiliar with the idioms and libraries available1, I found myself playing a bit of whack-a-mole guessing at what did what.
It’s 2024, and I decided to try turning to an LLM2. After giving the LLM some context about what I was attempting to do, and some back and forth sharing code snippets that I knew were working, as well as some intended example inputs and outputs, I managed to cobble things together.
Based on this experience, I have a few observations:
Using an LLM for coding assistance strikes me as the most useful use case I have personally tested for these tools.
In this case, I knew what I was trying to do, could help break things down into smaller tasks, and critically analyze the suggestions the LLM made for me.
In addition to saving me time writing boilerplate code, this process filled in a gap between my higher-level understanding of what needed to be built, and concrete information I didn’t have at my fingertips about how these particular libraries worked.
When something wasn’t working as I expected it to, I found I could give an explanation of what had gone wrong to the LLM, and it was capable of making a good guess about where the problem may have been with suggestions for possible solutions.
This particular LLM seems to have been trained on examples containing, and given explicit instruction to include a fairly significant amount of inline comments in the code it generates. I found this super helpful as I assessed its suggestions, and also to be better-documented than what I would have likely created for a prototype like this on my own.
I think after this experience I can see more clearly why developers seem to be the most optimistic about the possibilities of LLM technology. That said, I am even more convinced that prompting an LLM to do something that you don’t know how to do yourself would likely result in a maddeningly confusing outcome with much less chance of success.
It may be a bit trite, but I hold to the point of view that technology, and especially computing technology, should augment, not substitute, human thought. I’m curious to see if the development and use of LLMs moves more in this direction.
But I’m not holding my breath.
I haven’t used D3 professionally since I worked with its predecessor, Protovis, more than a decade ago. ↩
I am deeply skeptical of the hype around these technologies, and concerned about their usage for all sorts of reasons, including their impact on labor and the environment—not to mention the speculative economic bubble surrounding them that so smacks of the height of blockchain boosterism, and the questionable legality of hoovering up a bunch of human-created content without permission to feed these machines “data”. However, as a teacher I am very aware that my students make use of them within their studies as well as their work, and I would feel remiss if I didn’t try to understand how they may be useful. If nothing else, if or when I field questions about them, I would prefer my criticisms to be grounded in some practical first-hand experience. If you have made or would make a different choice about this than I have, I certainly don’t blame you. ↩
Every year, I watch more movies than I can possibly remember, which, maybe you can relate? 2024 was a tough year with a bit of an upswing to it for me. Overall, I don’t think it was the best year for cinema, but there were still some standouts for me.
Thelma
Give June Squib an award! Thelma is Mission Impossible if Ethan Hunt were a nonagenarian widow, holding things together, and holding space for her grandson struggling to launch in his early 20s. Thelma still proudly lives alone, and the action kicks off when she’s scammed out of some money, and her family starts thinking about curbing her independence.
She’s having none of it, and what unfolds is a charming and wonderfully-paced thriller about two people in their golden years proving they’ve still got it.
My Old Ass
Stop me if you’ve heard this one before. A teenager gets high with her friends in the woods, and is visited by her 40-ish-yo self, who is Aubrey Plaza.
Yes, with its concept alone, this film is silly and hilarious. What surprised me was how much heart it has, and how deeply and slyly the film turns your expectations against you to deliver a series of gut punches.
To top it off, My Old Ass features some of the most beautiful sun-kissed end-of-adolescence photography I’ve seen in a good long while.
Wild Robot
I’m a big old sucker for animation as a form of moving paintings, and whew does this movie deliver. Ostensibly a film about an abandoned android adapting to survive in the wilderness, Wild Robot gives us a much-needed story about the joys and heartbreaks and sacrifices of parenthood.
Since I stopped teaching full time a couple of years ago, I’ve become an unabashed fan of the work coming out of Dropout. These days I watch most of their game shows, as well as their brilliant productions of standup comedy that often verges on performance art. However, I found my way in through their series of live and recorded games of Dungeons & Dragons called Dimension 20, in particular the Fantasy High series.
But conventional wisdom holds that talking about one’s campaign is about as interesting as talking about one’s dreams. Most D&D campaigns are private affairs that leave few traces outside of scribbled notes and fond memories. No description can capture the rush of the game or the general anarchy wrought by the whims of the dice and the spontaneity of the players. For this reason, it is difficult to develop a proper aesthetic account of D&D. It is less like reviewing a book and more like reviewing a book club.
More of my work these days is focused on designing courses than on teaching, which means I’m not always as involved with students personally, and Andrea’s perspective holds something that’s true for me about courses too. In my experience teaching a great course is much more akin to running a book club than offering a book. It’s great to be able to offer a good book to folks, and I don’t kid myself: courses designed for learners to go through at their own pace are texts—even if they involve formats like video explainers or tutorial walk-throughs.
What I admire about Dimension 20’s approach to releasing well-produced live games, is that it feels like an in-between of a text and a club. They’ve prepared things with two audiences in mind: the players in the recording, who interact with the facilitator and drive the action and story forward through their characters; and the audience at home, watching all of this unfold. It’s less engaging than playing the game yourself, but comes closer to capturing the spirit and feeling of a liver interactive space for what is essentially passive consumption.
I’ll be curious to try a format like this for classes in the future as an experiment, to run a live course with a small group of students who can ask real questions and run into real problems in the moment, allowing them to act as student surrogates for others who can enjoy the course on their own time from home, in a different way.
The question on my mind is: how do you bottle up the urgency of the present moment? How can you make that moment re-livable in a future “now” with its own kind of urgency and potency?
A wonderfully nerdy dive into a set of questions about Japanese web design I’ve often asked myself with little satisfactory information to form answers with.
Chat interfaces are having a moment, and Amelia Wattenberger has put together a fantastic essay shedding light onto many well-known and long-standing issues with chat compared to more typical graphical user interfaces:
Good tools make it clear how they should be used. And more importantly, how they should not be used. If we think about a good pair of gloves, it’s immediately obvious how we should use them. They’re hand-shaped! We put them on our hands. And the specific material tells us more: metal mesh gloves are for preventing physical harm, rubber gloves are for preventing chemical harm, and leather gloves are for looking cool on a motorcycle.
Compare that to looking at a typical chat interface. The only clue we receive is that we should type characters into the textbox. The interface looks the same as a Google search box, a login form, and a credit card field.
Of course, users can learn over time what prompts work well and which don’t, but the burden to learn what works still lies with every single user. When it could instead be baked into the interface.
Kirk McElhearn explores and offers thoughtful ciriticism of Apple’s new app for classical music. It’s a great case for deeper information architecture work.
So how can you tell when there’s the right amount of visual hierarchy in a UI design? Just squint. This will blur the design just enough to quickly identify if the important elements stand out. I call this the squint test.
Accessibility in design is a form of empathy: trying to reach beyond your own personal perspective to try to understand other people who, in this case, very literally don’t see the world the same way you do.
Blah blah blah web components. Something something relative color syntax. All I really care about is that they fixed the font-optical-sizing: auto bug. It’s been driving me bonkers for months!
From Maxwell Neely-Cohen’s Letter from the Editor:
The growth at all costs mindset endemic to much of the web’s infrastructure has inevitably led to bait-filled search engine results and thin-skinned billionaires buying entire social media platforms to promote their own egos.
Meanwhile, literary magazines, including many of our favorites, are shuttering at a terrifying rate, often due to the capriciousness of their wealthy patrons or corporate parents. Book publishing is beset with megamergers, dreams of monopoly, the threat of private equity vultures, all while cultural and critical institutions that still overwhelmingly support only a small cohort of the connected.
Kyle Chayka, a writer we love, recently remarked “can we please build a more artisanal internet / media landscape” (in response to a depressing analysis of the future state of the media business in light of AI text generation hype, from Ryan Broderick, another writer we love).
If anyone out there is looking for a great RSS service, I can very happily recommend Feedbin. I’ve been a satisfied customer for 10 years, never had any problems. I mostly catch up on feeds from Reeder on my phone. After messaging, it’s my most used app—a steal for only $5. I also use NetNewsWire on my laptop sometimes, and can definitely recommend it if you’re looking for a free option.
Congratulations to Betina Hsieh, with some thoughtful reflections as she prepares to take on a new role as professor of teacher education at the University of Washington:
I now see myself as a researcher, something I might not have said 10 years ago. I have been able to explore research on teachers and teacher educators in ways that have moved me and have helped me learn so much about myself, about teacher candidates and teachers, about teaching (my own and that of others), and about the ways structures and systems can often act to perpetuate the push up and push out of so many incredibly talented people from classrooms.
I am working on trusting myself and trusting my community, trusting the faith they have in me and that their love and respect are well-placed. I am working on the grace and humility necessary to respond (rather than react) when I am called-in and pushed to grow. I am working on trusting that the right opportunities open up at the right times, and it’s not for me to decide that I’m not good enough.
Foreman makes the case that accessibility in journalism is important for everyone: Making news products more accessible, after all, often means making them more user-friendly and efficient. He hopes to discover and standardize ways of making the Post’s journalism accessible to as many people as possible.
Service designers have to be nimble and able to see the big picture and zoom into the details. As a service is made of up a wide variety of touchpoints (points of interaction between the customer and business — think: website, app, phone call, billing statement, store, shipping notifications, etc.), by nature, we have to be able to zoom into the touchpoint level. But in order to engage the business in orchestrating a multi-touchpoint relationship with the customer (the service experience), we have to be able to engage in strategic discussions and planning to set the conditions for success for the “encounters” with the service.
I feel like something like this could also be helpful for information architecture…
In this article, I’ll focus on the delicate interplay between many of the forces that act on a bicycle and its parts when riding. We’ll witness how forces applied through tires make a bicycle accelerate, brake, and turn, and we’ll also investigate how the wheels and the frame handle those different forces without breaking.
Sheon Han covers the history of blind programmers buiding assistive technologies for blind and partially sighted users:
Nearly three decades have passed since JAWS for Windows was released, during which possibly tens of thousands of blind and partially sighted programmers entered software development. Just as it was in Henter’s time, it’s a field that is relatively inclusive for people who are blind, as the accessibility barriers are lower than in many hands-on jobs. These days, this is in no small part thanks to JAWS, a piece of software pioneered by a blind programmer.
From Devon Govett and the design system team at Adobe:
This includes a full suite of fully featured components and hooks including calendars, date and time fields, and range pickers, all with a focus on internationalization and accessibility. It also includes @internationalized/date, a brand new framework-agnostic library for locale-aware date and time manipulation.
If you’ve ever worked on the design or implementation of components for choosing dates, I’m sure you’ll appreciate the incredible amount of work and attention to detail this represents.
I’ve been teaching design systems and accessibility courses lately, and there’s an amazing amount of overlap these days. This work from Adobe is a great example of why: building out flexible components which can be reused throughout an organization or even beyond suddenly changes the impact of accessibility efforts for those components.
David C. Brock celebrates the legacy of the earliest attempt to commercialize a personal computer with a graphical user interface:
The people who developed the Alto came to Xerox PARC from universities, industrial labs, and commercial ventures, bringing with them diverse experiences and skills. But these engineers and programmers largely shared the same point of view. They conceived and developed the Alto in a remarkable burst of creativity, used it to develop diverse and pathbreaking software, and then moved out of Xerox, taking their achievements, design knowledge, and experiences into the wider world, where they and others built on the foundation they had established.
The photos accompanying this article are a real treat. If you’re interested in going back just a bit further, Doug Engelbart’s “Mother of All Demos” presentation in 1968 was a major source of inspiration for PARC.
Dan Klammer has done the legwork of putting together a comprehensive and highly usable set of system fonts available on all the major platforms, organized by classification. Using system fonts means no font downloading, which means faster web sites and web apps, and no re-rendering when fonts load.
Accessibility is unfortunately still an afterthought on many projects. User interaction and accessibility requirements are poorly documented, at best. Or forgotten, when handing over designs to developer teams. And fixing it later costs a LOT more than building it right to begin with. Great documentation helps teams implement accessibility requirements the right way. I will tell you why, what and how designers can document different aspects of accessibility and user interactions requirements, to build better more inclusive products.
I had the pleasure of meeting Jukay and his team at Pursuit in 2017 before I left New York, and I was very impressed with the work they were doing to lower access barriers for professional tech education. Here Jukay discusses some of how they make that work:
One shining solution is called outcomes-based financing, a model where workforce development programs tie payment to a trainee’s employment trajectory, rather than charging fees up-front like colleges and universities.
Here’s how it works: thanks to funding from social impact investors through “job bonds,” participants don’t incur any cost during their training – not a single dime up-front. Then, after a graduate secures a high-paying job, they pay a percentage of their earnings for a set amount of time to help repay the bond’s debt service. If someone doesn’t immediately get a job or if their salary is below a certain level, they pay nothing. If they stop working for any reason, their payments pause, too.
There are a lot of people who talk big about “the future of education.” I’m not sure whether the ideas Jukay presents here would make sense outside of the space he’s been working in, but I do think it’s worth paying more attention to folks like him who have been doing the legwork to figure things out.
At some point, I personally hope the community college systems in the U.S. will catch up in terms of serving these needs outside of private foundations and companies.
I love reading about nerdy design processes like this one from Alex Hollander:
In other words, Wikipedia — a major, legacy website (top 10 ranked, for 10+ years) — had an interface that hadn’t been changed for 15 years. And then one day the Chief Product Officer came to our team (1 product manager, ~6 engineers, 1 quality assurance person, ½ a scrum master, ½ a data analyst, ½ a community liaison, and myself), and tasked us with making significant improvements. It might honestly be a once-in-the-history-of-the-internet kind of situation. Exciting, but rather difficult.
This is a great example of the power of storytelling, process, and emphasis on data and results in talking about the effectiveness of design work. If you’re working on a portfolio right now, I encourage you to take some notes on this one.
Bite-size selfie video tips from user experience researchers. As I describe it, I realize it doesn’t sound like it would work nearly as well as it does!
Michelle Ngo recently shared this short documentary on designing inclusively that she worked on. Tight and well-edited, with so many great stories. I especially loved the fashion designs for kids, and the efforts to bring young people into the process of designing for their needs. Great stuff!
Mandy advocates for digging deeper when facing burnout:
So how do we approach that repair? I think we have to first name the experience. Acknowledging your burnout (or that of your teammates) is one step, but the next is to unpack what that means. Maybe (probably) you’ve been working for too hard for way too long. Maybe it’s a loss of faith in the work itself—that something that had seemed important or valuable to you no longer does. Maybe you’ve been doing the same work for a while now, and have grown bored with it. Maybe you feel isolated or unsafe or like you can’t influence decisions. Maybe the way you think about your work has changed, and you don’t know where this job fits in anymore. Maybe it’s all of these things. The point is that each of these subjects—overwork, loss of faith, boredom, isolation, lack of autonomy, etc.—are all more readily addressable than burnout is on its own.
Nadyne Richmond makes a great point about keeping decision-making in focus when planning, conducting, and evaluating user research:
Defining the decisions that will be made as a result of the research can be a powerful tool when a team is using research for the wrong reasons. I’ve seen teams become so risk-adverse that they want to test every single thing. I’ve also seen teams become so beholden to a process that they don’t know when or even how to deviate from it. In those cases, defining the decision that will be driven and why that decision matters illuminates the more important problem that needs to be addressed within the team.
This subset of css that these tools use is based on how websites look today. Or on how they looked in the last ten years — which is the same thing. Websites haven’t changed. This means that with these tools we can design websites that look like websites-as-we-know-them, but it is much harder, if not impossible, to come up with new ideas. If we accept that these are the tools we will use from now on, we accept that the web looks like it looks today. And behaves like it behaves today.
I’m not sure I agree with this. As a teacher, I find it empowering for students that they can use tools like Figma with a fuller sense of confidence about the implementability of their designs. I think it’s equally arguable that the convergence of our tools with how we design is a sign of the maturity of the field.
If anything, I find myself wanting design tools to adopt more of the layout technologies available in rendering engines, not less—especially for things like grid-based layouts and tabular data, which most interface tools handle like a minor nightmare.
Maybe I lack the vision or imagination to dream up web designs that expand far beyond what we’ve acheived so far. That said, it’s not hard to find cases where design tools work so much faster to try out ideas that would feel slow or impossible to realize quickly in code:
interactive data visualizations
explorable explanations
contextual information
I want to see our design, production, and content tools improve, but I don’t think building in CSS-like features is inherently holding us back.
Julia Evans posted some comics about CSS last year:
I’ve been writing a tiny bit more CSS recently, and I’ve decided to actually take some time to learn CSS instead of just flailing around and deciding “oh no, this is impossible”.
CSS feels a little like systems programming / Linux to me – there are a lot of counterintuitive facts that you need to learn to be effective with it, but I think once you learn those facts it gets a lot easier.
Julia’s takes are always genial and practical. Have you ever seen a more appealing breakdown of CSS selectors? No, no you have not.
Ink & Switch offer an overview on the history, current state, and possible new approaches to providing end-users with more power over computation through various approaches of extensibility. From the introduction:
This article tackles the question of why this is so. We’ll start by describing three qualities we think are important for end-user programming: embodiment, living systems, and in-place toolchains. We’ll survey the prior art and try to illuminate what has made this problem so immensely difficult. Then we will document the experiments we’ve done at the Ink & Switch research lab in adding automation and customization capabilities to a digital sketchbook application.
We believe in a computing future where programming is within the grasp of everyone and hope this article can inspire and challenge our industry.
Today another class graduated, and I feel a mix of proud, tired, nostalgic, hopeful, and sad. This time, however, I find myself turning my attention to teachers I work with, more than to students.
This week I learned that two of my fellow teachers are stepping away from teaching to work on curriculum. I am happy for them, and excited to see what they will do, but I pause to reflect on my own past.
After I had been teaching full time for a few years, I moved into a non-teaching role, managing and coaching teachers. I jumped at it despite being unprepared: my school trained me in management (which I enjoyed) and teacher coaching (which I was very skeptical about). I was tired of the grind of teaching, and moving into a management role seemed like a good way to support teachers.
Ultimately school management burned me out in a way that teaching never has. I eventually left that school to take an industry job, only to return to teaching after a year. These have easily been the most productive and effective teaching years of my career—thanks to my time spent observing and coaching other teachers; training sessions I partcipated in to prepare for managing teachers; and collaborations with co-teachers and TAs who have taught, challenged, and inspired me.
At my current school, most of the teachers stay for only a year or two. One promising teacher I worked with burned out after six months and moved into an administrative role; most others have left the school and returned to industry practice. The past year I’ve noticed less turnover of teachers. I think many have simply stayed to avoid searching for a job during a pandemic. (The irony that we prepare students for a job search during the same pandemic is not lost on me.) I find myself wishing that the teachers who have stayed may discover that the job gets easier and more rewarding, and stick with it.
I’m hopeful that my colleagues who are moving to work on curriculum will feel challenged, will learn and grow in new and unexpected ways, and that they will find approaches that help our school’s teachers and students.
But in my heart I hope that they will find their way back to teaching.
This tutorial is meant to be accessible to developers of all experience levels. It can be thought of as “CSS transitions 101”. That said, I’ve sprinkled in some interesting and obscure tidbits — no matter your experience level, I bet you’ll learn something!
Nice shallow-to-deep dive into crossword puzzles from Russell Goldberg in The Pudding:
“Cookie that some people eat with mustard.” Before 2020 got crazy, this little clue from a USA Today crossword puzzle captivated a nation.
Have fun.
When you’re ready for something more sobering, and haven’t had your fill of crossword puzzle analysis, Michelle McGhee has an awesome breakdown of how inclusive various crossword puzzles are, Who’s in the Crossword?:
As a puzzle lover, I wanted to better understand who is being referenced in crossword puzzles — an unexplored piece of this puzzle. I teamed up with The Pudding to see if the people in crossword clues and answers represent the people who could be solving them. To measure this, we looked specifically at clues and answers that include the names of real people.
One of my favorite activities to use in class is a short sequence of “do, pair, share.” Some teacher friends introduced me to the idea, and you can find some version of it anywhere teachers congregate, often going by the name “think, pair, share” or “write, pair, share.”1
I first started using this approach in my design classes in 2015. I was skeptical at first. I had tried a couple of strategies before, recommended to me by teachers who were used to working with kids—like cold calling, and keeping a visible timer on the projector—and these seemed condescending to adult learners. I had the same doubt about “do, pair, share,” and I felt uncomfortable the first several times I tried it. But—I could almost immediately see the benefits, and it motivated me to practice and improve my approach.
Now I use it all the time. It’s the first thing I reach for when I have a doubt about what students understand, or when I want to get everyone participating in a brainstorm. I also find it helpful in meetings, workshops, and retrospectives—it’s a flexible tool. Try it with anything that participants could spend a few minutes doing independently, and get the ideas flowing.
Summary
What
Participants perform a short task alone, then compare with a partner, and finally share with the whole group.
Why
To get everyone involved in a discussion; to discover the current level of understanding of the whole group.
Materials Needed
Writing and drawing tools, plus any materials needed for the task
Difficulty
Easy
Time Required
10–20 minutes
How to do it
Steps
Suggested time
Give participants the short activity or question you’d like them to answer, with a time limit for how long they have to work alone.
1–2 minutes
As participants complete the activity, observe what they are writing or drawing to see how everyone is doing.
2–5 minutes
When time is up, ask participants to get together with a partner to discuss what they did and compare notes.
1 minute
Again, observe each pair as they discuss to check how they are doing.
2–5 minutes
Ask for volunteers or call on pairs to share what they came up with with the whole group.
5–10 minutes
Example use
At the beginning of a lesson on planning user interviews, I like to give students a prompt such as, “Imagine that you will be doing research to learn more about people’s movie and series watching habits. Take 2 minutes to write down at least 3 different things you’d be curious to find out.” After the activity, as partners share their questions, I can collect these on a shared board, to use as a starting point for the next part of the lesson.
Considerations for use
Keep the activity small and manageable in scope
Give clear instructions for the activity; consider showing them in writing where everyone can see
Depending on the activity, it may help to provide participants with a template or worksheet
A visible countdown timer can help keep participants on task during the activity
Considerations for use in person
If possible, arrange the room so you can walk around and observe without disturbing participants
Ask participants to find a new partner, or someone they don’t know well, each time you have them pair
Considerations for use in remote
Do the solo part of the activity quietly together in the primary room, then split into randomized breakout rooms for pairing
Use a shared digital canvas for the activity, where everyone can see everyone’s work
Consider creating a template with a space for participants to put their name and work in the shared canvas
At the end, share your screen to drive the focus of the group toward whichever pair is sharing what they came up with
I prefer “do” to “write” or “think”. Thinking is an active process, but as a facilitator, it’s difficult to observe people thinking. Asking participants to write down ideas or explain something in their own words is a great use of this technique, but I find it equally useful to ask people to draw, diagram, pseudo-code, construct… You get the idea. So the generic “do” it is. ↩
I worked most of the day today through the fog of a migraine, so this piece from Olivia Begasse de Dhaem for HBR seemed timely:
While many people think of migraine attacks as little more than bad headaches, migraine is in fact a chronic condition whose symptoms can be far more debilitating than an ordinary headache. Migraine attacks are often accompanied by intense pain, difficulty thinking, changes in vision, dizziness, nausea, and increased sensitivity to light, noise, and smells. Furthermore, research has shown that migraine is among the most disabling disorders in terms of its long-term impact on quality of life, and it is extremely prevalent: 47 million Americans and over a billion people worldwide suffer from migraine, with attacks peaking during the most productive professional years (25-55 years old).
This pair of statistics stood out to me:
While recent research is limited, studies from the last two decades found that productivity lost due to migraine costs U.S. employers at least $13 billion and European employers €27 billion every year — and these costs have likely only increased in the years since the studies were conducted.
Are U.S. workers suffering less migraines? Is this a reflection of differences in work-life balance between Europe and the U.S.?