Andrea Buran’s Site ^5.0

I love how David Allen says that you can do anything you want but you can’t do everything you want. And that is an extremely liberating mindset.

Every programmer occasionally, when nobody’s home, turns off the lights, pours a glass of scotch, puts on some light German electronica, and opens up a file on their computer. It’s a different file for every programmer. Sometimes they wrote it, sometimes they found it and knew they had to save it. They read over the lines, and weep at their beauty, then the tears turn bitter as they remember the rest of the files and the inevitable collapse of all that is good and true in the world.

Metrics are a horrible way to understand customer intent. Great way: customer interviews.

But: we bias our people, when we ask them. Even if we try not to.

Reason: we believe our own bullshit.

Being the one poor soul remote in a co-located team is hard… you have “5x” the process needs… People will continuously forget to involve you in discussions or decisions, you will be the person not knowing what is happening why—you will suffer.

Like many modern workers, I find that only a small percentage of my job is now actually doing my job. The rest is performing a million acts of unpaid micro-labor that can easily add up to a full-time job in itself. Tweeting and sharing and schmoozing and blogging.

When companies just build it, just ship it, iterate on it, and build and ship again, this means that customers are seeing a variety of versions. They are seeing the work in progress and watching the sausage being made. This is often a frustrating and confusing experience requiring customers to keep relearning a system that’s evolving.

One of the most common questions I get from people is why I use [some older technique or tool] over [some newer technique or tool] […]. The technologies, tools, and techniques don’t matter. The answer is always the same.

Because it does what I need and I already know how to use it.

Don’t commit to features. Features are solutions to problems, but they’re seldom the only solution. Instead, commit to solving the underlying problem; if the “not-quite-perfect” result (fewer new features, or none at all) solves the problem, you’ve still succeeded.

I Google how to do things—sometimes really basic things—every single day.

When a prototype is successful, works great, and tests well, there’s a real temptation to use the prototype code as the basis for the final product. Don’t do this! […] Build prototypes to test ideas, designs, interactions, and interfaces …and then throw the code away.

Perhaps if accessibility was considered at the very start of the project, the process of creating, editing and moving blocks would be a lot simpler and thus, not a cognitive overload. The problem now is that accessibility is a fix rather than a core feature.

[…] He and Steve Jobs would often disagree about things, but the way he eventually won Steve over was through dogged persistence in bringing up the topics he cared, not through saying things loudly or dramatically.

Analogical thinking lends itself to incremental product iterations rather than groundbreaking advancements because it promotes a habit of following the footsteps of history.

So, I nearly didn’t apply to become a sonar operator since I failed the proxy requirement “has perfect score on generic hearing test”. However, the real requirement was “can learn to classify boats by their sound under water”, and it turns out I was pretty good at that!

A good rule of thumb is: if a problem seems simple to you, you probably don’t fully understand it. You certainly might, but you probably don’t, and therefore, you should treat your critiques as investigations or explorations and not conclusions.

Tournaments are a playground for people who practice for growth […]. Once I made that realization, I finally started making continued growth my goal, rather than winning.

Trust is not a renewable resource.

The café and the space are great, but something’s missing—something you can barely remember now…. Oh, right! It’s you. You are missing. This amazing space that everyone in the community holds so dear is for everyone but you.

There are certainly many caveats to the above idea of setting a goal around a single metric. A notable one is that you may need to have a counter-metric to help balance short term and long-term trade-offs.

One of the biggest culprits of unclear user flow is basing the user experience on your company’s understanding of the problem. Companies have their own internal terminology and organizational structures to address these problems internally. Users likely won’t understand any of this and shouldn’t require a glossary of industry terms or internal structures in order to use your website or app.

Unnecessary motion […] are nothing but a barrier for these users. If the motion is actually accomplishing something, you have to ask if what you’re drawing attention to is worth sacrificing other content on the page in return.

[…] because essentially, it is a character saying: “Whatever you do, don’t do that”. It tells the audience to associate a certain value with a certain action: crossing the streams = bad.

That means that complexity in design can lead to complexity in code.

One of the first things you learn as a UX designer is to not let ego drive your decisions regarding design; one of the hardest thing to do as a UX designer is to pass on that knowledge to your client.

When you travel for extended periods of time, you lose your social circle, your sense of belonging, and the everyday routines that keep you grounded and healthy.

You also quickly discover that meeting new people is easy, but making new friends—real friends—is hard, especially if you’re starting from zero.

If you succeed, if you ship your code, if you release your product, will you be happy? Will all your time and effort be worth it?

And you realize the answer is “no”. And suddenly your work is worthless, your goals are meaningless. You just can’t force yourself to work on something that doesn’t matter.

The grid example is of two-dimensional layout. Layout in rows and columns at the same time. The Flexbox example is one-dimensional layout.

The point is that qualitative and quantitative research serve different purposes. Qualitative is mostly useful for creating hypotheses, while quantitative is great for verifying your hypotheses and solutions.

The earliest decisions of the digital product design process are, at best, based on guesswork. Until a product is in the hands of actual users, everything is theoretical.

You have needs and your family has needs and the bills have to be paid. There’s dignity in taking care of those things, but that doesn’t mean that you shouldn’t have any creative aspect to your life whatsoever. Set your alarm a half hour early every day and work on that book or that new business idea.

I think people perceive the process of creation from the outside to be instantaneous and free and wonderful. In fact, it is work.

To paint a picture, Jobs-to-be-Done, or JTBD for short, follows the idea that customers purchase products or services to get jobs done, not for the products or services themselves.

I can’t recall an example of groundbreaking work coming from an environment of stress, anxiety, and fear of failure.

If you’re here to help others, be patient and welcoming.

[…] Nintendo said, “pay us a royalty not on sales, but on manufacturing.” Nintendo said, “we will decide what games we’ll allow you to publish,” ostensibly to prevent another crash like that of 1983, but in reality to quash any innovation but their own. Iwata-san said he has the heart of the gamer, and my question is what poor bastard’s chest did he carve it from?

The main thing I want to know is, Larry: you do realize […] that when you keep our husbands and wives and children in the office for ninety hours a week, sending them home exhausted and numb and frustrated with their lives, it’s not just them you’re hurting, but everyone around them, everyone who loves them?