Tim Urban has a similar post on this called “The Tail End”, noting that by the time we get to adulthood we often have used up the vast majority of time spent with loved ones - particularly with parents and siblings.

https://waitbutwhy.com/2015/12/the-tail-end.html

My brother and I read this and were touched by it; we lived on opposite coasts and since we were kids always loved hanging out with one another. The idea that in our current arrangement we had already depleted MOST of our time together was a bitter pill to swallow.

For years we batted around the idea of living closer to each other. One day we just pulled the trigger and did it. It was enormously inconvenient, took a ton of logistical planning for our respective families, jobs and so on; but we ended up with houses within walking distance of one another and went from seeing each other and our immediate families maybe 10 days a year to 300+. We have accepted going forward it may limit our career options relative to when we lived in top tier American cities but the happiness we gained in the process is more than worth it.

I’m still not 100% sure the experiment will work out, but making the adjustment to live closer to family has substantially increased my mental health and emotional well-being. If you have close friendships and have ever talked about this seriously, I’d encourage you to consider what you might be gaining or losing in your current setup. It’s not for everyone but worth exploring!

Iconography is hard! Interesting to see the criteria the biohazard symbol was developed against and how that informed the result. It reminds me of the complexities explored in a localization firm’s proposal for McDonalds as they explored creating a universal visual language for nutritional information. The archived pdf is here:

https://web.archive.org/web/20170719080459/http://www.enlaso...

The reactions from testing varied quite widely based on geography, as they were trying to create a system that worked in 109 countries. For example, the original orange icon for sugar was said to resemble Scottish subway signs, Canadian road signs, and Danish danger signs. An early symbol for calcium showed a milk carton, but was scrapped because some regions mistook it for a building, portable toilet, phallic symbol, or tombstone. They had to take into consideration cultural and religious connotations for certain shapes as well.

For folks wondering "when would I use this?" I have used tools like these early in the design process for broad, net-new features or redesigns in apps where driving alignment early on is crucial to success. In a more buttoned-up Agency process you might see something like:

General Idea > White Board Session > High Level Screen Flows (this) > Individual Wireframes > High-Fidelity UI > Coding.

These are useful tools to step back from individual screens and think of the broader ecosystem of the feature the team is trying to build. If actions on one page affect another page further down a flow, it's easy to reference that in a meeting by having it all laid out in a lower-fidelity, non-distracting way. For example: "if I add a user to this group, where will that user and her derivative information pop up across the experience?" becomes an easier discussion with an artifact like this.

I find when working early on with multi-stakeholder or multi-department initiatives, some high-level UX documentation can be helpful in ensuring when everyone goes back to their desks, each group has the same, general picture in their head.

From the article: “McKinsey started as a business that sold candid, dispassionate advice to corporate managers, but selling advice and building a brand around it also sets up a mechanism for diffusing responsibility. The managers can say they’re just following the best available advice, and the consultants can say they’re just trying to help their clients boost profits and efficiency.“

I spent some time with an Engagement Manager at McKinsey a few years ago, and he noted one function that they provide to executives is a seemingly neutral arbiter for tough decisions that may be politically untenable inside an organization. A CEO may know exactly what drastic steps they need to take, but will face internal executive strife, board pressure, or lack of buy-in from the business to execute. McKinsey provides credibility in cases of extreme actions (layoffs, re-orgs, shutting down business functions, etc), which is why the final deliverable of an engagement will often times simply state what was already known across the organization, but in a more packaged, compelling format. The same Engagement Manager then noted that if management doesn’t know exactly the “answer” is to the question they are asking, often times the McKinsey Partner supervising the case has seen the problem enough times to generally know the solution they will recommend out of the gate, as they specialize in industries. Their team arrives and then spends the cycles putting together justification for their upcoming recommendation.

It seemed to me similar to the old adage “nobody gets fired for buying IBM,” executives can lean on the good will of the McKinsey brand to justify and expedite certain tricky decisions. In many cases this is about providing confidence to move in a certain direction. This has two benefits: the broader organization can be told an outside firm was able to arrive at said battle plan - ideally increasing buy-in since the “experts” recommended it, and if things go awry the executive can point to the deliverable handed off by the consultants as the sanctioned playbook. So this “diffusing responsibility” is a feature, not a bug.

I’ve seen two solutions to some of the implicit problems described above, neither or which are cheap or easy: either A) the management team is solid enough and garnered enough goodwill that they can navigate such troubled waters (hard to do as the business scales) or B) An organization gets large enough they can fund their own internal management consulting team to tackle tough problems on a case by case basis - Samsung has used this across their business lines.

I feel Earthbound, the classic SNES RPG where Ness debuted, is a masterclass on NPC dialogue. The dialogue is so well crafted it makes you eager to talk to each NPC you come by, knowing even if they don't give you relevant information they will give you a silly hot take on the world they occupy. It makes everything so much more rich. The Rabbit Girl referenced in the article is from Undertale by Toby Fox, who cut his teeth in gamemaking creating Earthbound mods. I suspect this is why his characters in Undertale follow a similar whimsical nature to this early influence of his. Undertale borrowed a lot from Earthbound's character construction.

I've been playing through Earthbound over the last few weeks and consistently find the writers and localization team put in just the right extra 10% to turn a "bleh" interaction into one you think about for days to come. For example, in a nod to the greedy, one character grumbles about the loan he gave to your family and now he "lives in poverty" - all while standing in the biggest house in the game.

Later on, a key item with key information gets shipped to your character via the equivalent of Fedex "Neglected Class." A rumpled delivery man eventually shows up and tells you "Anyway, he said... well... uh... I forgot. Yep, I forgot... actually I forgot the stuff I was supposed to deliver, too. I think it was some weird machine to make trout-flavored yogurt. Yeah, I forgot it at the desert... I'm not going back that way, so don't ask me to get the package... I mean, it's your package, right? So YOU go get it! Go on, get out of here." You then have to schlep to another part of the game to recover the package the delivery man decided just wasn't worth his time [0]

If you've played the game and want to figure out why some of the quirkiness just WORKS, I would recommend the later parts of Tim Roger's piece from a decade or so ago [1].

[0] https://youtu.be/EIoLcNLyd0g?t=27902

[1] http://archive.is/fMD7F (edit - huh, yeah this article has NOT aged well at all I should have taken a closer look since it first was released long ago, but I'll leave it here for the sake of discussion & derivative comments).

I stood up a data science operation at my company over the last few years, and have noticed a key difference in data-science projects that have been successful and those that have failed. It hits on a number of points brought up in the article, namely where does data science "fit" in an organization delivering software and how is the value realized by the business.

The worst cases I have seen is when executives take a problem and ask data scientists to "do some of that data science" on the problem, looking for trends, patterns, automating workflows, making recommendations, etc. This is high-level pie in the sky stuff that works well in pitch meetings and client meetings, but when it comes down to brass tacks this leaves very little vision of what is trying to be achieved and even less on a viable execution path.

More successful deployments have had a few items in common

1. A reasonably solid understanding of what the data could and couldn't do. What can we actually expect our data to achieve? What does it do well? What does it do poorly? Will we need to add other data sets? Propagate new data? How will we get or generate that data?

2. The business case or user problem was understood up front. In our most successful project, we saw users continuously miscategorized items on input and built a model to make recommendations. It greatly improved the efficacy of our ingested user data.

3. Break it into small chunks and wins. Promising a mega-model that will do all the things is never a good way to deliver aspirational data goals. Little model wins were celebrated regularly and we found homes and utility for those wins in our codebase along the way.

4. Make is accessible to other members of the company. We always ensure our models have an API that can be accessed by any other services in our ecosystem, so other feature teams can tap into data science work. There's a big difference between "I can run this model on my computer, let me output the results" and "this model can be called anywhere at any time."

While not exhaustive, a few solid fundamentals like the above I think align data science capabilities to business objectives and let the organization get "smarter" as time goes on as to what is possible and not possible.

My heart really goes out to employees who are about to be put through the wringer, I've heard horror stories of coffee shops and restaurants laying off 90% of staff on a day's notice - I'm sure it will quickly expand.

I work at a DC startup LiveSafe and we are still hiring. We offer a communications platform for students and employees focused around safety & security - we were founded out of the need for communities to have a quicker, more direct line to campus security following our founder being shot in the Virginia Tech shooting. I have been helping lead the expansion of our offerings into Fortune 500 corporate clients.

Many of our clients have been using our software to push outbound information to their students / employees about policies around COVID-19, as well as triage and respond to employee needs, so we are fortunate in that our product fits into the response effort for most companies who purchased us. I think we will be fine for the foreseeable future - sound financials and a generous credit line secured during good times just in case.

We are hiring for a much needed Data Science position focusing on building and deploying NLP models & products to analyze the data that travels through our platforms - plus our production stack is a dream to build and deploy on. It's a small, fun, mission-driven team granted a lot of autonomy and responsibility - I'm on phone screens just about everyday and we have not slowed down filling this position. Would love to hear from any Data Science / Engineering talent may need a soft landing in all of this - very interesting text-heavy data set.

https://apply.workable.com/livesafe/j/DA0FCE14D5/

For what it's worth - I saw the value of Tailwind UI as its connection to the Refactoring UI product from Adam Wathan (tailwind) + Steve Schoger - https://refactoringui.com/ The tips, screencasts, and eventual book they offered gives a superb, distilled, crash course on making stuff "look good" when to the untrained eye it can all seem arbitrary. They take a lot of guess work out of adding polish to your product.

Taking a look at Tailwind UI, it's clear they have baked in all of the tips and tricks into the components offered, adhering to preached principles like good visual hierarchy, layout and spacing, color theory, and typography. Therefore, while TailwindUI may seem like just a bunch of utility classes, the components they have constructed tap into a lot of solid design principles that a large community has bought into and studied. I'll for sure be buying and trying it out in future projects of mine.

Previous discussion on Adam and Steve's book here: https://news.ycombinator.com/item?id=18655224