Andrea Buran’s Site ^5.0

Not a single new idea generated in the brainstorms had been built or launched. The best ideas — the solutions that teams actually executed — came from individual work.

[…] duration means something. But video game audiences haven’t incorporated it into their reading of video games, in the same way that we all have a cultural understanding of what time means in a film, even though pacing can carry every bit as much meaning.

The smallest thing you can build to test each hypothesis is your MVP. The MVP doesn’t need to be made of code: it can be an approximation of the end experience […].

The assumption in Lean UX is that the initial product designs will be wrong, so the team’s goal should be to find out what they got wrong as soon as possible.

[…] the MVP strategy has a clear objective prior to engaging with customers and seeks reassurance on that strategy […].

It’s only through having surplus demand that you can let go of mismatched clients without hesitating. And the ability to let go is critical to keeping your team happy.

But once an interaction designer has created a wireframe, it’s hard for many (we’re not saying all) visual designers to think outside the boundaries set by that wireframe and challenge the ideas it contains.

Human language is messy, littered with vagueness and ambiguity. With time, usage and meaning drifts. Humans misunderstand and re-interpret […] but a computer program will never puzzle over how to interpret a particularly complex line of code.

Design is an iterative process. The necessary number of iterations is one more than the number you have currently done. This is true at any point in time.

Too few connections and complex ideas can’t spread. Too many connections and complex ideas get crushed by groupthink.

But, users have learned to accommodate to Google not the other way around. We know what kinds of things we can type into Google and what we can’t and we keep our searches to things that Google is likely to help with.

Start simply. Code defensively. User-test the heck out of it. Recognize the chaos. Embrace it. And build resilient web experiences that will work no matter what the internet throws at them.

Game designer Naomi Clark suggests that this is a third type of game, a game of labor, in which players are rewarded for performing routine tasks, rather than for their skill or for their luck.

[…] My mind spills out questions like, “Is this Tuesday better than the week before?” And “Ooh looks like there’s a link to my website from smashingmagazine.com, that oughta be great for SEO right?” Those seem fair and worthwhile, right?

…until I had a revelation

Those all-important numbers don’t really matter at all.

This is what games do: they promise us that we can repair a personal inadequacy—an inadequacy that they produce in us in the first place.

Research—broad, foundational knowledge-gaining to decide what to spike or give the ability to estimate—indicator: don’t know a potential solution.

Never attribute to malice that which is adequately explained by stupidity.

If your work is not final yet, if you are testing it, you should not convert your elements into symbols, or use nested symbols.

There is no reason for DRY to be goal in itself. DRY is a tool, to achieve some real goal, like smaller file sizes, better maintainability, etc. But I don’t see any real benefits to use it just for the sake of it.

[…] as long as I work on a team with a lot of other remotes, everything will be fine. Working as the only remote on a team of people who are all in person seems like hard mode […].

These days every Google product seems to assume that your internet connection is always on, that you’re close enough to the nearest Google server that your brain won’t notice the speed-of-light delay, and that you have practically unlimited bandwidth. These assumptions are barely true in Mountain View, let alone in most of the rest of the world.

It’s a shame to see a ton of hard work go into static designs only to see all that thinking, detail, and nuance get washed away when it’s translated into code.

Once upon a time I opened a new tab in Firefox on my Android phone to find out that besides a list of my most visited pages to choose from, there also was a list of things “suggested by Pocket”. What the hell was Pocket, why was it suggesting me things and, more importantly, how the hell did it get into my Firefox?

What would you do, or how should the project be run to ensure that kind of failure?

To my fellow maintainers: stay harsh on code and don’t be afraid to say “No” or “Why?”; there really are more bad ideas than good ones […].

[…] significant progress in the solutions of technical problems is frequently made not by a direct approach, but by first setting a goal of high challenge which offers a strong motivation for innovative work, which fires the imagination and spurs men to expend their best efforts, and which acts as a catalyst by including chains of other reactions.

Rather than beginning a fruitless search for such divine proportions to serve a gross simplification of the world, we will instead focus on a more concrete history of how technology long has inspired designers to use geometric constraints to ease the burden of their work.

The more choices technology gives us in nearly every domain of our lives (information, events, places to go, friends, dating, jobs) — the more we assume that our phone is always the most empowering and useful menu to pick from. Is it?

The precision is introduced by the engineer, where it rightfully belongs. After all, our designs are completely useless until they are built—what exists in the users’ hands is the final design, and nothing less.

Herein lies the problem: our current tools encourage me to design the finished product first. They beg me to mess with rounded corners, colors, typefaces and stroke styles. But it’s only when I’m working within a strict design system that I ever need to declare those things.

As a Designer becomes more Senior, they also become more realistic and business-minded, or so the idea goes. These “Senior Designers” understand that a company is a company, and that the money paying your salary has to come from somewhere.

[…] Google’s not going to be selling many ads next to search results that turn them up. So from a business point of view, it’s hard to make a case for Google indexing everything, no matter how old and how obscure.

It’s also worth recognizing how these decisions aren’t, in almost any case, unalloyed pushes for “the future of the web.” They reflect business priorities, just like any other technical prioritization.

Machines are not intelligent, but they already excel at simulating intelligence. They are really good at making us believe that they understand, that they know us, that they comprehend, that they play chess.

This is bonkers, isn’t it? Google is creating data out of data.

For me and for Tony, this clip is extremely reassuring. If Miyazaki — the world’s greatest living animator — can admit defeat after trying his best, then it’s okay for everyone else. If he can let go, then so can we.