Andrea Buran’s Site ^5.0

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.”

In the React era, we have embraced the extremely useful approach of modular, component-based development […]. But I think it’s equally important to acknowledge that CSS is not 100% modular, nor should it be.

You can think of willpower like a battery that starts the morning charged but loses a sip with every decision (a phenomenon called “decision fatigue”). As Facilitator, you’ve got to make sure that charge lasts till 5 p.m.

Building a façade may be uncomfortable for you and your team. To prototype your solution, you’ll need a temporary change of philosophy: from perfect to just enough, from long-term quality to temporary simulation.

Indeed, many designers and developers I speak with would rather dance naked in public than admit to posting a site built with hand-coded, progressively enhanced HTML, CSS, and JavaScript they understand and wrote themselves.

How about we just call “dark patterns” what they truly are—bad design and bad ethics. It’s dishonest and it’s short sighted.

Protect the talents of your team by making firm agreements in advance about approach, method, and ideas. Ground rules help others to play the game and help guard against foul play.

If your company is at the hostility stage, you can forget about promoting user experience. People have to want to change before there’s any chance of helping them do so. Once the company’s been sufficiently hurt by its Neanderthal attitudes, management will be ready to consider usability and enter the next stage.

I’m not confident that average people could have so little time in their schedule to spare that a minute to call for an appointment. Instead Google could actually be aiming this product at people that simply don’t want to talk to another person […].

I always find it helps to do some exploratory research prior to running stakeholder workshops. This ensures you go into the room with a baseline understanding of the organization its users and some common pain points.

A salesperson with little understanding of technical implementation, or of the teams delivering the work, sells the client a fantastic vision, on a knowingly impossible timeline, scope and budget. In doing so, they not only sell the project but also sell their own people, upon whose shoulders the problem will sit, down the river in the process.

Remember that users rarely need “features.” What they need is to attain some kind of goal.

[…] we’ve managed to improve the performance for those stuck on old technology while also opening the possibility of using the latest standards on browsers that support them.

The biggest lie in software is Phase Two.

Sprints on the other hand are a lot better for making major pivots which really require you to go broad before you converge to a few ideas worth trying out.

In a sprint, decisions are made by one person: the Decider. […] With the Decider in the room making all the calls, the winning solutions stay opinionated.

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?