Prioritize Through Use

Once you design/implement that MVUI and use it, by actual use in the wild you'll come up with a much more informed set of next-most-important-to-you features to implement. - Tantek 11:25, 15 May 2013 (PDT)

Incremental

It's OK (and even often good!) to make incremental improvements to the design, however small or conditional.

For example, every time you reduce the number of situations where the user sees an error and/or has to file a support ticket, the likelihood of an overall better user experience is increased.

And on the contrary, avoid making such incremental improvements depend on other incremental improvements that can be done independently or later. Such dependencies are a milder form of the completeness trap.

UX Before Infrastructure

There is a misdirected priority/desire (often among developers/engineers) for things like:

"a general message producer/consumer so I can implement it once"[1] or similarly

a general parser so I can implement it once

"...and then spend the rest of my time focusing on the UX" (ibid)

This is the kind of reasoning that led people to push for XML over everything else.

It was a misplaced focus on solving infrastructure *before* UX.

It turns out that doesn't actually help you solve the UX, which is the real challenge.

On the contrary, if you have good UX, then the infrastructure/plumbing can be almost anything, and swapped out later too.

This is perhaps a key distinguishing feature/aspect of the indieweb and IndieWeb efforts.

UX Before Protocols

Start with the MVUI/UX that you want on your website and implement accordingly.

When you reach a site-to-site boundary, i.e. an IndieWeb-to-IndieWeb boundary, in whatever feature you're designing, creating, iterating, use the desired UX to drive the design of a minimal protocol.

Never shoehorn upwards, that is from protocol up to UX - as that is the tail wagging the dog.

At the end of the day, the UX is what matters, regardless of attributes, protocols, etc.

And without UX, that is if you don't know what UX you want, you'll overdesign/overengineer your protocols & formats, as nearly all protocols & formats are.

On the IndieWeb, we focus on UX first, and then as we figure that out we build/develop/subset the absolutely simplest most minimal protocols sufficient to support that UX, and nothing more.[2]