Dancing about architecture
Opinions model's own; don't shoot.
The usual thing where I try to type sentences rather than just groan into Twitter. I have no idea if there are 3 axes. Or 4. Or what axes might be. But here goes.
Axis 1: Not every bit of your "page" makes it to users. Not every "user" cares
Delivering all the bits that go to make up your web page is complex. In the sense that's it not predictable. There's a standard web stack that goes (from the top down) something like:
- Decorative CSS - the fonts and background colour and background images and "branding".
- Layout CSS - the floats and positions and margins and paddings that scatter bits of content around screens.
- Document design - how your HTML gets structured with semantics (or at least document semantics). Headings, paragraphs, lists etc.
- Resource design - all the information required to create the assorted documents you may want to present the resource as. Which might be HTML or might be vCards or might be iCal documents or might be JSON or XML or whatever.
None of this is new. It's progressive enhancement. It's just modern web design. It's what everyone does. Except sometimes it doesn't appear to be.
Axis 2: There is no <screen-size> first
Mobile first does make a lot of sense. You're starting with the minimum necessary description of a resource and building up / decorating / transcluding as the screen size increases. Given no sane person would use a watch for computing, a phone is a pretty good starting point. Except not every user has or needs a screen. Again google bots and screen readers. Maybe you should start with screen readers first. Maybe you should re-learn HTML document design.
Or maybe say that first just means first. The spectrum from wrist-watch to mobile to tablet to laptop to telly screen is analogue not digital. People do resize windows. "Break points" are just the new "below the fold".
The painful point is all this works by design on a standard web page. Layouts are designed to flex to whatever width the user decides to choose. It only fell apart because designers couldn't bear to live without columns. So back in the day developers had to somehow infer how the columns should collapse into one as the window width shrunk. And now they have to infer how they should pop out as the window width increases. If you really can't stand life without columns at least spend some time explaining how they should behave.
Maybe one day all general purpose computing will be wrapped up in a mobile "form factor". But we're not there yet. If you're publishing specialist information for professional users they're probably going to be sat in an office using a laptop. Do do mobile first, don't do mobile only, don't do anything because it's a popular slogan and don't assume all your users have screens. Or just spend more time thinking and less time following fashion.
Axis 3: There is no idealised end-state in a complex domain
This one is harder to type about without examples but feels similar to the progressive enhancement stuff. But for content. And the real-world things the content is about. And the ways those things are connected in real life and in the minds of users. Or what does the domain model look like? How do the things you're describing connect to the other things you're describing? How do the things you're describing extend the other things you're describing?
Another example from work... We're making pages to describe people. They have all the attributes of people: given names, family names, dates of birth, dates of death. Some of those people happen to be or have been Members of Parliament. Some of those members happen to be current members. Some of those current members happen to be contactable:
The natural approach is to work out from the general (people) to the specific (contactable members) but it goes wrong if you get too focused on delivering a single end state. It's almost exactly analogous to the progressive enhancement arguments except for content. Design thinking seems unable to escape from the idealised end state where all the assets have loaded and the resource being described has a full suite of attributes and connections. To use an old work analogy, everyone wants to see a Doctor Who mock-up, no-one's that bothered about seeing a Bells on Sunday.
To resurrect a very old work memory - at one point the BBC brought in Neville Brody to give their website a revamp. He appeared to believe that news would be massively improved if only it could be made to look like a 1980s style magazine. Lots of strange type running at strange angles over massive "hero" images. The mock-ups took up whole walls in the Broadcast Centre, every one designed for a perfect news day. Usain Bolt crashed through finishing lines, the chancellor (any chancellor) stood in Downing Street with his red box. The mock-ups looked super. I guess. On the day it launched one of the top stories was about British people eating more processed cheese than any other nation. And the "hero image" was a badly photoshopped packet of Kraft cheese slices.
And the moral of the story is: design is nonsense if it fails to deal with reality. Going further, until your design involves real content wrapped in real data, interplaying with the rest of the real web, heading to real devices, over real connections to real users, all design is artificial. And until all of that's true and you're A/B testing and making tweaks and changes in response to real usage by real people, you've barely even started to design.
Taking the misunderstandings of progressive enhancement and combining with the misunderstandings of the domain model you end up with something roughly like:
Interpretations of user stories, user requirements and the whole user experience industry often force design backwards and down from idealised end state, with not enough thought given about how the whole experience degrades as connections drop and the content doesn't quite match the idealised patterns.
And all the time they're doing this they're doing design. They're making decisions about how things work, not how they look. And every one of those decisions is about user experience for at least some set of users.
I don't have a handy name for the bottom left to top right approach. Maybe it was once just Information Architecture but those words got tainted on route. For a little while it looked like the Content Strategy people were getting there but they seemed to slip on the final step. If I had to choose a label I'd go with something like Resource Driven Design. Though not in a formal RDF sense. It's about understanding resources and how they relate to other resources and how that gets expressed as hypertext at each level of the web stack. Maybe that's just called "Web Design".
I don't think this is an approach that feels natural to most people working in web design. It requires a degree of patience, a more zen like acceptance of how design happens (gradually) and a suspension of disbelief that when you've finally made all the things addressable and linked them all together, somehow all of that will make sense to users. But design should be emergent from content, content should be emergent from descriptions of real-world things and navigation should be emergent from the real-world links between those things. That takes time and it takes domain knowledge but it certainly saves on Photoshop licences and printer cartridges.
Axis 4: Yes, the web is stateless
I was planning to stop at three and given I've already done this rant on numerous other occasions it's probably redundant. But you still see designs that seem to suggest HTTP cares who you are or where you've come from and that user journeys are a limited and controllable set. The problem only seems to get worse with the rise of "service design" and its obsession with prescribed paths through complex systems and the accompanying desire to keep trying to tell the user where they came from. Actually, they probably came from Google like most of the other users.