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?
[…] The designers are the pegboard though. They set up where everything has a space and how it is going to work together.
There is this huge library, this huge vocabulary of actions built up over the years that people you know don’t really do, but which happened so often in TV and movies that they’re familiar enough to an audience that they become, well, passable for human motivations.
Not making it clear from the start that I have a process, and clients taking control of the design process […].
As the landslide of bullshit surges down the mountain, people will increasingly gravitate toward genuinely useful, well-crafted products, services, and experiences that respect them and their time. So we as creators have a decision to make: do we want to be part of the 90% of noise out there, or do we want to be part of the 10% of signal?
[…] Conversely, don’t link to outside sites that are not credible. Your site becomes less credible by association.
With all that at play, how can any tool give us a truly accurate picture of unused CSS, to the point that actually removing that CSS isn’t just as dangerous as leaving it alone?
[…] Then management decided that it would “look better” if we went to circular desks where several of us would be sitting with our backs to the hallway, so everyone walking past would be looking at our screen as they passed. It took a minor rebellion that lasted several weeks before management backed down from that horrendous idea.
[…] if you’re investing time and budget to make a prototype and put it in front of people, you’ll want to do some preliminary research first. Only then will you have an informed hypothesis worth testing.
Above all, when designing a web page we should design the body text first, usually before anything else in the layout. It’s the most common element and its appearance will have an evident effect on the rest of the composition.
We initially tried to create these components as symbols in Sketch, which resulted in a mess. Even now, our Sketch files are sometimes challenging to maintain.
The more context we have for the situation, the better I can design a solution.
If someone wanted to segment them by market or customer, these segments couldn’t be more separate. Yet, if you thought of them in situational segments, you’d find these segments to be tangent—maybe even the same.
Disagree and commit is a management technique for handling conflict. There are two parts to it. First, expecting and demanding teammates to voice their disgreement. Second, no matter their point of view, once a decision has been made, everyone commits to its success.
Artifacts can force clarity of the complexities of the wicked problem space.
Continually look for opportunities to test the direction you are going in. If people disagree, test. If you aren’t sure about your approach, check it.
Always having at least two people look over the code also curtails ideas of “my” code and “your” code. It’s our code.
Remember that there is an appropriate time for different types of feedback. Cheerlead early, and critique more thoroughly later.
Be comfortable letting things go, and remember that your teammates are smart people with expertise.
Underlying these concerns is the predominant business model for platforms on the Web—user-targeted advertising. Advertising based business models encourage the consolidation and the hoarding of user views and data, driving platforms to become ever larger.
“One of the things we’ve realized is that it’s hard to separate motivation from sustained attention,” he says. “If we’re not looking at motivation, then we’re really missing the boat in terms of attention.”
“There are no right or wrong answers. Since I didn’t design this, you won’t hurt my feelings or flatter me. In fact, frank, candid feedback is the most helpful.”