There’s no absolute definition of “the best” solution. The best is relative to your constraints. Without a time limit, there’s always a better version. The ultimate meal might be a ten course dinner. But when you’re hungry and in a hurry, a hot dog is perfect.
When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth.
Willing to admit when they’re wrong, and aren’t afraid to say “I don’t know”.
Translation is not a science; it is an art. One must take liberties with the text to capture the essence of the words, in an attempt to recreate the feeling of the original for a very different audience with a very different cultural background.
All AR experiences have, at their core, some notion of planes and anchors. Planes are flat surfaces on which content sits, and anchors are spatial markers relative to which content distance is measured.
Then it hit me—a content object is defined by two things: (1) its format (the properties it exposes), and (2) where it is located relative to other content.
The first step was to understand how consultants used and interacted with this data in its native web-based form. The different ways that users consumed the data determined the design of its mobile counterpart.
Humans inherit convictions mimetically from each other—we learn what to value by imitating our peers. As my desire to excel academically grew, I spent greater amounts of time in and around the physics department. The more time I spent there, the greater my desire to excel.
Some of the most worst missteps have involved training data that is faulty or simply used with no recognition of the serious biases that influenced its collection and analysis.
Once you’ve identified your key output metrics, build out the constellation by breaking those outputs down into their input metrics. Drill down until you’ve got a set of actionable input metrics that you can impact directly, and then build your experiments to move those.
If you feel like you’re getting hung up on components too early at an exploratory stage of your project, worry about them later—don’t let it hinder the fluidity of your design process.
Siesta naps, rich in NREM sleep, result in a significant increase in alertness that will be highly appreciated by people in creative professions. By various measures that boost may be as high as 50%!
Programming by nature is functional, reusable, extensible, and version controlled. Modern design systems aim to accomplish much of the same and more, and therefore can take direction from how programming already functions.
Unfortunately, at some point we start to fear failure, but that fear is just holding us back. Failure is really the learning process. Every loss at chess, every falling down when we’re learning a backflip… those are lessons.
The good side of having a learning plan is focus. I’m not searching for information and I have a plan to follow. All the hard work of planning and research is done.
On the other hand, telling someone to never give up is terrible advice. Successful people give up all the time. If something is not working, smart people don’t repeat it endlessly. They revise. They adjust. They pivot. They quit.
Confined by the limited space on a page, we are often tempted to force all the data we have into a slot that’s way too small. Although this saves valuable space on the page, it has consequences […].
We have three states for new features. Now, next, and probably never. Whatever we’re working on now is the most valuable thing we can think of. Whatever’s next is the next most valuable thing.
Like proto-personas, a proto-journey can help bootstrap empathy and team alignment.
He wasn’t a bad person (he was a lovely person, in fact.) But having him as a boss showed me exactly the kind of boss I didn’t want to become. I took his template of leadership and whittled my own—a relief carving in opposition to his.
De Bono’s “hat” represents a certain way of perceiving reality. Different people are used to “wearing” one favorite “hat” most of the time, which limits creativity and breeds stereotypes.
The benefits are strong. You understand the big architectural choices before sinking money into building them. You empower designers by giving them space to explore multiple options and do rapid iterations. This leads to huge progress, quickly.
So it’s often better to encourage the behavior you want, than discourage the behavior you don’t. Instead of punishing a player that is too slow, reward a player that finishes the level quickly.
There’s an extremely successful Netflix documentation about decluttering your house—this is directly applicable to software as well. The main essence is that if we did not use something for e.g. three months, it’s not worth keeping it.
But I think there’s a lot of value in actively questioning the need for complexity. Sometimes the smarter way to build things is to try and take some pieces away, rather than add more to it.
Critically missing from the core scrum team, and necessary for the integration of UX design, is a full-time designer on the team. The only way the tactics in #3 can happen in parallel collaboration with developers, product managers, and scrum masters is if there is a full-time designer on the team.
Jeff P advocates for 2 types of work, not 2 teams. The type of work the team is doing fluctuates over time. In some parts of the initiative more discovery is needed. In others, more delivery is needed.
This meant analyzing search trends in order to generate key phrases—everything from “What time is the convention” and “Watch Trump’s speech live” to “How to pick up women”—and assigning those key phrases to a staff of SEO writers, who then reverse-engineered stories around them.
Facebook is such a big distributor of traffic that no news operation can afford to ignore it, but it is not a neutral distributor. It’s a bit like if the paperboy went rogue, decided to put a gun to the temple of a newspaper editor and barked that unless he gets a cut of the sales he’ll pull the trigger.
In other words, clickbait, personalized to my psychological profile, as determined chiefly by an analysis of my online behavior. Anyone who has followed the recommendation engine on YouTube knows that after delivering one or two innocuous videos, the “Up Next” cue serves up increasingly extreme content. The algorithms push us to become caricatures of ourselves. They don’t merely predict our behavior; they shape it.
Facebook et al. became the primary sources of news and the primary destroyers of news. And they refused to deal with it because their business is predicated on the fallacy that technology is neutral—Silicon Valley’s version of “guns don’t kill people”.
As you can see, an important rule of thumb is to personalize around the main content, not the entire page. There are a variety of reasons for this, including the risk of getting the audience wrong, effects on search indexing, and what’s known as the infinite content problem, i.e., can you realistically create content for every single audience on every single component? (Hint: no.)
In order to successfully model content, we must create content environments that stand up to the pressures of production.
Another exercise is asking the question, “What is the evil version of this feature?” Ask it during the ideation phase. Ask it as part of acceptance criteria. Heck, ask it over lunch. I honestly don’t care when, so long as the question is actually raised.
Error rates climb with hours worked and especially with loss of sleep. Eventually the odds catch up with you, and catastrophe occurs. When schedules are tight and budgets are big, is this a risk you can really afford to take?
So, people tend to underestimate two crucial things about content: how much content they need, and how long content takes to write.
The starting point is realizing that working long hours makes you a much less productive employee, to the point that your total output will actually decrease […].
If there is a should, there is a way to get out of it. It is an excuse for missing commitment. Real change starts with the burden that I am indeed responsible for the change. If I only believe that I should do it, is not important enough for me. If it would be I would do it. If it would be important for all of us, we would all do it together.
[…] we look at best practices, analyze the competition, and then, often, we take a copycat approach to building our product. We think that if it’s working for them, it’s got to work for us too. The problem? It frequently doesn’t—at least not the way we think it will.
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.