Tags: product

The Imperfectionist: Seventy per cent

If you’re roughly 70% happy with a piece of writing you’ve produced, you should publish it.

Works for me!

You’re also expanding your ability to act in the presence of feelings of displeasure, worry and uncertainty, so that you can take more actions, and more ambitious actions, later on.

Crucially, you’ll also be creating a body of evidence to prove to yourself that when you move forward at 70%, the sky stubbornly fails to fall in. People don’t heap scorn on you or punish you.

I’ve been reading lots of modern takes on Greek classics. So when I saw that there was going to be a short of run of Sophocles’s Electra at Brighton’s Theatre Royal, I grabbed some tickets for the opening night.

With Brie Larson taking on the title role in this production, it’s bound to be popular.

I didn’t know anything about this staging of the play—other than it was using the Anne Carson translation—which is how I like it. I didn’t know if it was going to be modern, retro, classical or experimental.

It turned out to be kind of arty, but not in a good way. Arty like art school with all the clichés.

The production somehow managed to feel packed with gimmicks but also seriously underbaked at the same time. There must have a been a lot of “yes, and…”s during the workshopping, but no subsequent round of “no, but…”s. So we got lots of ideas thrown at the wall like spaghetti. Very few of them stuck.

Instead of enhancing the core text—which is, thankfully, indestructable—most of the gimmicks lessened it. It’s like they were afraid to let the play speak for itself and felt like they had to do stuff to it. Most of it ended up creating an emotional distance from the story and the characters.

It wasn’t bad, per se, but it definitely wasn’t good. It was distinctly mediocre.

Now, take all of this with a big pinch of salt because this is just my opinion. The very things that turned me off might tickle your fancy. Like the way it was half way to being a musical, with characters singing their dialogue in that monotone way that they do in Les Mis (but this is like Les really Mis). And the vocal effects that did nothing for me might be quite effective for you.

Even as I was watching it, I was thinking to myself, “Well, this isn’t really for me, but I can kind of appreciate that they’re trying to experiment.”

But then towards the end of the play, it went too far. Over the PA came samples of reporting of recent news stories; graphic, grisly, and crucially, real. If you’re going to attempt something like that, you need to earn it. Otherwise you’re just cheapening the real-world suffering. This play absolutely did not earn it.

Elektra has finished its run in Brighton and is now heading to London where it’s supposed to play until April. I’m curious to see how it goes.

Durable products | Brad Frost

Wherein Brad says some kind words about The Session. And slippers.

Slippers are cool.

Prescriptive and Descriptive Information Architectures | Jorge Arango

Interesting—this is exactly the same framing I used to talk about design systems a few years ago.

Hixie’s Natural Log: When complaints are a good sign

This is a very smart way to handle feedback about a product.

Trains are offices | hidde.blog

This tracks (ahem) with my experience of coding on trains.

Hidde lists the potentially flaky connectivity as a downside, but for many kinds of deep work I’d say it’s very much a feature, not a bug.

Generative AI Is Not Going To Build Your Engineering Team For You - Stack Overflow

People act like writing code is the hard part of software. It is not. It never has been, it never will be. Writing code is the easiest part of software engineering, and it’s getting easier by the day. The hard parts are what you do with that code—operating it, understanding it, extending it, and governing it over its entire lifecycle.

The present wave of generative AI tools has done a lot to help us generate lots of code, very fast. The easy parts are becoming even easier, at a truly remarkable pace. But it has not done a thing to aid in the work of managing, understanding, or operating that code. If anything, it has only made the hard jobs harder.

AI-free products

Develop a simple, focused app that does what it says on the tin — not one where the tin talks back at you.

If you can’t make it to all three days of this year’s UX London, there’s always the option to attend a single day.

Day two is focused on product design. You know, the real meat’n’potatoes of working at the design coalface (to horribly mix my metaphors).

The day begins with four back-to-back practical talks.

1. John V Willshire gets the ball rolling with a big-picture talk on the product of design. John will show you how to think about futures rather than features.
2. Tshili Ndou follows on with her talk aboutvalidating features. Tschili will show you how to create high value products and avoid wasting money.
3. Wioleta Maj is up after the break with a talk on understanding the impact of design choices. Wioleta will show you how to identify who we are creating our designs for (and who we are not).
4. Harry Brignull closes out the morning with his call to action, Do Not Pass Go. Harry will show you how to get to grips with our industry’s failure to self-regulate when it comes to harmful design patterns.

After lunch, it’s decision time. Whereas the morning talks are sequential, the afternoon’s workshops run in parallel. You’ve got four excellent workshops to choose from.

1. Ben Sauer will be giving a workshop on the storytelling bridge . Ben will show you how to find your inner storyteller to turn your insights into narratives your stakeholders can understand quickly and easily.
2. Tom Kerwin will be giving a workshop on multiverse mapping. Tom will show you how to pin down your product strategy and to align your team around the stuff that matters.
3. Serena Verdenicci will be giving a workshop on behavioural intentions . Serena will show you how to apply a behavioural mindset to your work so you can create behaviour-change interventions.
4. Brad Frost will be giving a workshop on the design system ecosystem. Brad will show you how to unpack the many layers of the design system layer cake so you can deliver sturdy user interfaces and help teams work better together.

Finally there’s one last keynote talk at the end of the day. All will be revealed very soon, but believe me, it’s going to be a perfect finisher.

If a day of outstanding talks and workshops on product design sounds good to you, get your ticket now.

And just between you and me, here’s a discount code to get 20% of the ticket price: JOINJEREMY.

Prototypes, production & fidelity layers | Trys Mudford

I’ve always maintained that prototyping and production require different mindsets. Trys suggests it’s not as simple as that.

I agree with much of what he says about back-end decisions (make it manual ‘till it hurts—avoid premature optimisation), but as soon as you’re delivering HTML, CSS, and JavaScript to real people, I think you need to meet certain standards when it comes to accessibility, performance, etc.

Jessica and I spent last week working remotely. We always work remotely in the sense of not being in an office, but I mean we were remote from home too.

We’ve done this twice before. Once in Ortigia, Sicily and once in Cáceres, Spain. This time we were in Turin.

We had one day at the start of the trip to explore the city and do touristy things, checking out museums and such. After that we hunkered down in a very lovely and cosy AirBnB working each day.

I found it very productive. Maybe it’s a similar effect to going to a coffee shop to write—something about the change of scene encourages more of a flow state. The apartment was nice and quiet too so it wasn’t a problem when I needed to be on a call.

Best of all was what awaited at the end of each working day. We were staying in the Quadrilatero neighbourhood, famed for its aperitivo scene. Heck, there was a wonderful Vermouth bar literally across the street.

And after an aperitivo? Time to sample some Piedmontese cuisine. Bagna càuda! Vitello tonnato! Agnolotti! Panna cotta! We had some wonderful meals at restaurants like Consorzio, L’Acino, and Pautasso (a neighbourhood spot we went to on our last night that had the most perfectly convivial atmosphere you could imagine).

They say a change is as good as a rest. I certainly enjoyed this change of scene.

There’s something about going somewhere for a working week that feels very different to going somewhere primarily as a tourist. You get a different flavour of a place.

Pluralistic: The (open) web is good, actually (13 Nov 2023) – Pluralistic: Daily links from Cory Doctorow

The web wasn’t inevitable – indeed, it was wildly improbable. Tim Berners Lee’s decision to make a new platform that was patent-free, open and transparent was a complete opposite approach to the strategy of the media companies of the day. They were building walled gardens and silos – the dialup equivalent to apps – organized as “branded communities.” The way I experienced it, the web succeeded because it was so antithetical to the dominant vision for the future of the internet that the big companies couldn’t even be bothered to try to kill it until it was too late.

Companies have been trying to correct that mistake ever since.

A great round-up from Cory, featuring heavy dollops of Anil and Aaron.

No Taste | Scratching the Surface

Designers can’t help but participate in these displays and debates of taste. It’s part of the job. There’s an irony in the predominantly liberal and inclusive political leanings of most creatives that often become unbending and exclusionary in their work and everyday lives. Comic Sans, Thomas Kinkade, New Urbanism, clutter—there are too many heretical acts to count. Natalia Ilyin writes in Chasing the Perfect, “For people who want their straight lines to be straight, life itself is the problem. The modern urge is the urge to get away from organic existence in general.” No wonder most movie villains live in spartan homes of concrete, glass, and steel. The often humor-free designer is not so different, if not in evildoing, then at least in temperament.

How do build tools break backwards compatibility? | Go Make Things

If you have a project that uses just plain HTML, CSS, and JavaScript, you can just open up the files and start working on them at any time. A project from 20 years ago will still work just fine, and can be easily modified.

Projects that use build tools? Well… to work with them, you need your build tools to actually build. And that’s not always guaranteed.

Also, it me:

One of my least favorite things as a developer is wanting to do a quick patch fix on an older project—I’m talking a simple one-line of CSS kind of fix—but first having to spend 30 minutes patching my build tools to get them running again.

Ship Faster by Building Design Systems Slower | Big Medium

Josh mashes up design systems and pace layers, like Mark did a few years back. With this mindset, if your product interface are in sync, that’s not good—either your product is moving too slow or your design system is moving too fast.

The job of the design system team is not to innovate, but to curate. The system should provide answers only for settled solutions: the components and patterns that don’t require innovation because they’ve been solved and now standardized. Answers go into the design system when the questions are no longer interesting—proven out in product. The most exciting design systems are boring.

The Illusion Of Developer “Productivity” Opens The Door To Snake Oil – Codemanship’s Blog

There are a lot of astute observations in here.

We’re still not innovating with AI-generated UI.

Prototypes and production:

It looks like it will be a great tool for prototyping. A tool to help developers that don’t have experience with CSS and layout to have a starting point. As someone who spent some time building smoke and mirrors prototypes for UX research, I welcome tools like this.

What concerns me is the assertion that this is production-grade code when it simply is not.

We do quite a bit of prototyping at Clearleft. There’s no better way to reduce risk than to get something in front of users as quickly as possible to test whether you’re on the right track or not.

As Benjamin said in the podcast episode on prototyping:

It’s something to look at, something to prod. And ideally you’re trying to work out what works and what doesn’t.

Sometimes the prototype is mocked up in Figma. Preferably it’s built in code—HTML, CSS, and JavaScript. Having a prototype built in the materials of the medium helps establish a plausible suspension of disbelief during testing.

Also, as Trys said in that same podcast episode:

Prototypical code isn’t production code. It’s quick and it’s often a little bit dirty and it’s not really fit for purpose in that final deliverable. But it’s also there to be inspiring and to gather a team and show that something is possible.

I can’t reiterate that enough: prototype code isn’t production code.

I’ve written about the two different mindsets before:

So these two kinds of work require very different attitudes. For production work, quality is key. For prototyping, making something quickly is what matters.

Addy recently wrote an excellent blog post on the topic of prototyping. The value of a prototype is in the insight it imparts, not the code.

It’s crucial to remember that in a prototype, the code serves merely as a medium—a way to facilitate understanding. It’s a means to an end, not the end itself. The code of a prototype is disposable and mutable. In contrast, the lessons learned from a prototype, the insights gained from user interaction and feedback, are far more durable and impactful.

This!

It can be tempting to re-use code from a prototype. I get it. It seems like a waste to throw away code and build something from scratch. But trust me—and I speak from experience here—it will take more time to wrangle prototype code into something that’s production-ready.

The problem is that quality is often invisible. Think about semantics, performance, security, privacy, and accessibility. Those matter—for production code—but they’re under the surface. For someone who doesn’t understand the importance of those hidden qualities a prototype that looks like it works seems ready to ship. It’s understandable that they’d balk at the idea of just throwing that code away and writing new code. Sometimes the suspension of disbelief that a prototype is aiming for works too well.

As is so often the case, this isn’t a technical problem. It’s a communication issue.

How Google Reader died — and why the web misses it more than ever - The Verge

Wanna get angry all over again?

(Now do Geocities!)

Privacy in the product design lifecycle | ICO

A very handy guide to considering privacy at all stages of digital product design:

This guidance is written for technology professionals such as product and UX designers, software engineers, QA testers, and product managers.

1. The case for privacy
2. Privacy in the kick-off stage
3. Privacy in the research stage
4. Privacy in the design stage
5. Privacy in the development stage
6. Privacy in the launch phase
7. Privacy in the post-launch phase