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.
If you know you have a meeting in an hour, do you start your deepest, most complex problem solving work? I’d venture to guess most people don’t. I certainly don’t.
Notice how these colors do not seem ‘natural’ per se, but are chosen to convey the taste of the product.
[…] Debt is acquired by building for the short-term. Design debt is made up of an overabundance of non-reusable and inconsistent styles and conventions, and the interest is the impossible task of maintaining them.
I wish I had more comforting words for you, but all I can say is that most things worth doing are a struggle.
Fail fast. Iterate quickly. Prototype. Prototype. Prototype. And cut. Cut scope until it hurts.
Failure is a good thing if you plan for it. Failure can teach you lessons that no success will ever teach you […]
If you’re describing what a function does and you have to use the word “and,” that function is probably too complex. What a function does should be simple enough to explain with only a descriptive function name and descriptive arguments.
Tell everyone you’re working on this project to make sure that there isn’t anything you overlooked.
Values aren’t what’s printed on the wall or in the employee handbook, but the interactions that happen every day. The values stem from the top, are reinforced by each employee, and determine how the company works.
Solutions based on this knowledge can help you to give users what they need, rather than what they say they want.
[…] software patents are actually preventing the adoption of new technology, rather than encouraging it.
Your job is not to stop your mentee from making any mistakes; it’s to stop them from making the same mistakes over and over.
[…] it’s confusing because I don’t think pictorially, I’ve done it grammatically […]
A difficult client who demonstrates trust issues right from the beginning of the business relationship and shows an inability to compromise might be more trouble than they are worth.
Yes, I have regrets, but as soon as you start rewriting your past you realize how your failures and mistakes are what define you.
After reading that, do you still want to include open source work in your project? Will it derail your purpose and goal?
What has changed in the last generation is that companies today view more and more of the labor it takes to produce their goods and services as akin to staplers: something to be procured at the time and place needed for the lowest price possible.
When an organization tries to maximize inputs, rather than outputs, the result is a whole series of bad judgments.
Exhaustion isn’t cured over a weekend (or even a long weekend). It requires a recalibration of priorities, tasks, life goals and even life purpose.
[…] it is important to distinguish between ‘state’ and ‘act.’ The state of something in UX is fundamentally static, like a design comp. The act of something in UX is fundamentally temporal, and motion based.
[…] there are three levels of consistency: individual, collective, and institutional.
If a project calls for SVG and a designer has been tasked with creating illustrations and providing design assets for development, then the designer is no longer handing over a static file, but a snippet of code […].
Being a senior developer doesn’t mean you have to know everything, it means you can help find out anything.
Effective retrospectives require a commitment to maintain an open mind and open communication with your team, as well as a willingness to be vulnerable.
[…] we primarily use animation in three ways—to indicate a state change, to add an emphasis, or to reveal extra information
A common pitfall is to define your goals in terms of your existing metrics—“well, our goal is to increase traffic to our site.” Yes, everyone wants to do that, but how will user-experience improvements help?
Trust keeps a relationship going, but you need the knowledge of possible future repeat interactions before trust can evolve.
When you’ve been set up to fail, your primary goal is to demonstrate that the inevitable failure was not your fault.
Focusing on coding inflates the importance of finding the “right” method to solve a problem rather than the importance of understanding the problem.
What advice does anyone have for me?
I tend to finish a presentation with some questions of my own. I ask whether they feel the project will achieve its desired goals, meet the needs of users and fulfil organisational objectives.
Audrey, you’re missing a really important step. I think you need to just listen to them.