Link tags: iteration

Build for the Web, Build on the Web, Build with the Web – Web Performance and Site Speed Consultant

If I was only able to give one bit of advice to any company: iterate quickly on a slow-moving platform.

Excellent advice from Harry (who first cast his pearls before the swine of LinkedIn but I talked him ‘round to posting this on his own site).

1. Opt into web platform features incrementally
2. Embrace progressive enhancement to build fast, reliable applications that adapt to your customers’ context
3. Write code that leans into the browser, not away from it

I’m not against front-end frameworks, and, believe me, I’m not naive enough to believe that the only thing a front-end framework provides is soft navigations, but if you’re going to use one, I shouldn’t be able to smell it.

Benjamin Parry~ Writing ~ Marking the homework of a twelve year old ~ @benjaminparry

Don’t get me wrong, there are some features under the mislabeled bracket of AI that have made a huge impact and improvement to my process. Audio transcription has been an absolute game-changer to research analysis, reimbursing me hours of time to focus on the deep thinking work. This is a perfect example of a problem seeking a solution, not the other way around. The latest wave of features feel a lot like because we can rather than we should, because.

Vibe Driven Development

This describes how I iterate on The Session:

It comes down to this annoying, upsetting, stupid fact: the only way to build a great product is to use it every day, to stare at it, to hold it in your hands to feel its lumps. The data and customers will lie to you but the product never will.

This whole post reminded of the episode of the Clearleft podcast on measuring design.

The problem underlying all this is that when it comes to building a product, all data is garbage, a lie, or measuring the wrong thing. Folks will be obsessed with clicks and charts and NPS scores—the NFTs of product management—and in this sea of noise they believe they can see the product clearly. There are courses and books and talks all about measuring happiness and growth—surveys! surveys! surveys!—with everyone in the field believing that they’ve built a science when they’ve really built a cult.

Why Do We Interface?

A short web book on the past, present and future of interfaces, written in a snappy, chatty style.

From oral communication and storytelling 500,000 years ago to virtual reality today, the purpose of information interfaces has always been to communicate more quickly, more deeply, to foster relationships, to explore, to measure, to learn, to build knowledge, to entertain, and to create.

We interface precisely because we are human. Because we are intelligent, because we are social, because we are inquisitive and creative.

We design our interfaces and they in turn redefine what it means to be human.

How can designers get better at learning from their mistakes?

Jon has seven answers:

1. Build a culture to learn from mistakes
2. Embrace healthy critique
3. Fail little and often
4. Listen to users
5. Design. Learn. Repeat
6. Create a shared understanding
7. Always be accountable

It’s gratifying to see how much of this was informed by the culture of critique at Clearleft.

What walls are for – disambiguity

Digital things look ‘finished’ too soon. When something is a work in progress on a wall, it looks unfinished, so you keep working on it. moving things around, reshaping things, connecting things, erasing things, and making them again. Walls make it easier to iterate. Iteration, in my opinion, is massively correlated with quality.

Architecting the uncertain - Getting started with Agile Software Architecture

Some ideas on the best of use of time in sprint zero of an agile project.

• Understand your context
• Identify risks
• Understand the business process
• Get testing infrastructure
• Understand quality attributes
• Get to know the people
• Prepare an initial product backlog
• Build a walking skeleton/spike
• Build a learning backlog

How to prototype in the browser | GDS design notes

This is a clever quick’n’dirty way of prototyping iterations on an existing site using dev tools and screenshots.

A Code Review, Or Yet Another Reason to Love the Web | Brad Frost

I love this back and forth between Brad and Jonathon. I think they’ve both got some good ideas:

• I agree with Brad that you can start marking up these kind of patterns before you’ve got visual designs.
• I agree with Jonathon that it’s often better to have a generic wrapper element to avoid making assumptions about which elements will be used.

Reflections on An Event Apart DC 2013

Jason pulls together some of the themes that emerged at An Event Apart DC this week.

Throw away Photoshop and be true to your medium | Government Digital Service

How designing in the browser works for rapid iteration.

theunbook.com

An approach to releasing community-driven books that is more like software than traditional book publishing. Think versions instead of editions.

Designing for hyper-connectivity - SlideShare

This talk that James gave in Bristol last week is chock full of great stuff. Well worth a read/look.