Design for Every Screen

8 Nov 2011 - 8:58am
4 years ago
10 replies
2318 reads

I've worked out what I really think about trends like Mobile First, and have made sense of the way I have been working for years. Read up on my user centric approach to finding the right design, and the right channel, input, and interface, for your product.

In summary, design a target IA to guide all interactive and interface designs, and follow design processes to tell you what channels, inputs and outputs you need to design for. Don't assume web, mobile app, or anything else. Desing for every screen, context, channel, etc.

I am not just pushing for more links to my blog; it's just a long explanation so didn't seem it would all fit here. Anyway, do tell me what you think. I am very comfortable with it, but like the pragmatic parts of the design philosophy, want it to work for everyone. I'll evolve it with useful feedback. 


8 Nov 2011 - 9:50am
Tarun Gangwani
This post reminded me of one from Don Norman (through a design listserv):
Today, it is about to get  better for the user and far worse for the= designer. The development of gesture-based phones and tablets has caused every vendor -- Google, Apple, and Microsoft -- to bring out entirely new ways of displaying material, changing the rules. Google just brought out "Ice Cream Sandwich," their new OS that is quite different from what is now on the market. Apple has  iOS5. Microsoft is bringing out Windows 8, again a major, rather revolutionary departure from existing systems.  Although Android and iPhone displays look similar, Microsoft's new system looks very different.
All companies said "the very same application can run on a Computer, a smart phone or a tablet."  (Google does not (yet?) make a computer. They do make "Chrome," a cloud-based computer, but it uses their Chrome browser to display everything, so one could think of it as a tablet with bit in keyboard, that may or may not have a touch-sensitive screen.)
Touch sensitive screens: suddenly the rule for targets -- the things you click - change. Fingers are not a precise as a mouse pointer or a stylus. So the screen design has to accommodate the fact that any display might now be controlled by touch. So you can't have touchable items close to one another -- and they must be big enough.   This means, for example that you can't have a list, where someone just points to the list item of interest: the finger point is not accurate enough to select one word or one line out of normally-spaced type.
Each company's system is different than the others. So web developers have to encode differently for the different OSs, and the different browsers.
And although it is nice that the same apps might run on everything, where everything uses touch and gesture (yes, even computers -- although they will still have a keyboard and mouse, except for Apple where the mouse, I predict will be replaced by their touchpad).
And now the same information will have to be read on a tiny phone screen (and the phone screens vary a lot in size), on tablets (where they already come in many sizes. Apple has its touch and iPad. Android tablets are made in 5", 7" and 10" (and others). Microsoft has yet to enter the game but they are coming on strong: their new Windows 8 system for smart phones (think Nokia reborn), tablets, and computers is very exciting: it is the best one out, I believe. (well, it isn't quite out yet).
Getting legible type -- form size, contrast, and line length -- is a real challenge.  But it can be done. Designers have some control, but the design must figure out the size of the browser, the brand and release of the browser and OS, and even the screen resolution and size and display accordingly.   Lots of conditional statement.
Yes, a lot of this is automated. But when you see the results of the automated systems you will cringe even more.
It is about to get far worse in the attempt to make the end results
far more exciting and powerful.
 In the startup companies i advise, if the people are not careful al
their resources are being used simply to keep their systems running on
the many varieties of Blackberries, iPhones, and Android phones out
there. So don't do it, i say. Design for just one phone: whichever is
 your customer base. It used to be that this meant Blackberry for
business people and Android or iPhone for the others. iPhone used to
be the obvious choice, but now Android is used by more people than 
iPhone, but it is much more difficult to design for because of the
variety of models.
 So too with websites. And remember, people more and more view websites 
on phones.
 And people less and less print web pages.  Tablet viewing has replaced printing.
Just to go along with this thinking, I think that because Apple has chosen to not design for every screen is what makes their products so appealing -- they take advantage and exploit the medium, rather than try and create a unified experience. The unification of experience leads to many tradeoffs, as this post tries to pin down. 
15 Nov 2011 - 6:31pm

Sorry I didn't respond to this one. I wasn't reading the actual page till now, but using the email notifier/response. Missed it. 

Anyway, I tend to read this and then see the last section (It's about to get far worse...") with all the caveats. It seems to make a good case for the past, then peters off into statements like, "And remember, people more and more view websites 
on phones" which I tend to say proves my point: truly bespoke, craftsmanlike execution is great. I can even believe that you can be close to that in classic Apple days (but note the care everyone likes to point out they take with even packaging, or stores...) 

But interactions with any service in a connected world is inherently multi-channel. My point is not a pro-fragmentation screed, per se. Even if you decide to ignore many other steps of what I find an ideal process, and just make an iPhone app, you need to distribute it, tweet about it, accept user feedback, market it, send password reset emails, and maybe do a lot of other stuff. It's hard to believe you don't have a desktop and mobile website just so people can buy the app (you can, I've seen it, but I sure wouldn't). If you don't think about all these, at once, early on, you are missing opportunities for creating* great experiences.

*If you insist: fostering, enabling, etc. I can live with that side of that argument.

8 Nov 2011 - 10:42am

Seems to me that mobile first is at a different level of abstraction. What you seem to be advocating is general good design practice of focusing on the human experience, goals, needs, etc. at the highest level.  At some point, though, you have to get more specific, and the contexts of use vary enough to call for specialized attention and design.

My take on the value add of mobile first is that it comes into play at a lower level, after you nail down the high-level human experiential stuff, and you have to start designing interfaces, if you start with mobile, it will 1) potentially reach more people (just based on # of devices/usage) and 2) potentially make your other interfaces (especially desktop) better precisely because mobile design tends to make you think about UI design in a more lean and story/goal-focused way.

My main concern with your suggestions is that they sound an awful lot like the developer mindset that wants "write once run everywhere" or the ever-elusive master domain model that can be reused in all contexts, which tends to end up marginalizing the particular experiences with all screens due to maintaining a lowest common denominator approach and too many trade-offs for reuse over optimized use.  One IA to rull them all sounds like it would tend towards this, but I suppose without concrete examples of such an IA, it is hard to say.

For instance, what people want or need to do (and are willing to do!) while on their phone may vary considerably from what they might sitting focused at their desktop at work. It seems unlikely that anything other than high-level, domain-oriented goals could be shared between these two contexts. But I would love to see examples that show otherwise--because it seems like an appealing goal, especially from a stakeholder perspective. :)


P.S. I love the term "gap of execution." That is a serious challenge in environments where specializations are more prominent.

8 Nov 2011 - 2:26pm

Good points. Let me take on the write-once thing most of all. It wa getting to be a long discussions so I left out some details; plus, it's a post about self-discovery, so I forgot what else I was assuming. Maybe I'll jsut pitch this as my next book. I could easily write a couple hundred pages on it. Anyone want to pay me for this? 


Instead of more theory, let me use a real example (a bit sanitized in case no one wants me to share it… so also therefore, I won't share the actual diagram, which is sadly pretty cool and explains it real well).


I worked a couple years back on an eReader project. Requirements from the corporate masters were more than a bit vague, so we me up a target audience, and requirements, and so on. But a few key things is that it was going to be hardware (and actual eReader) and a platform so it worked on all sorts of other devices, and could be ported to other dedicated hardware, maybe. 


So, in this case, I made a single IA for everything. Which took a couple iterations to get right, but I am very pleased with where it ended up. It was a platform/technogy/input/output/context-agnostic IA for the product. But when executed it was one the SAME IA for every channel. The web portal had a portal landing page. Which did not even exist on the eReader, which was centered around the reading experience so landed on the last page of the book you were reading. And the eReader had device settings, which were the same place, architecturally, as the preferences for every other channel, but had device-specific hardware settings, and was accessed in a device-like manner (via a conditionally-present control bar), whereas settings on the desktop app were under File > Settings. 


So the single IA was implemented for each interface individually still, even at the design level. From a write-once POV, there were absolutely common APIs, and a lot of pseudocode that was shared. The requirements were basically identical for each platform, to the point that the IA diagram included the common widgets that are used for each screen or state. But one guy built the iOS version. A team of three guys built the eReader. Another team built the website. Etc. One IxD, one IA, one VizD team for the whole project, but implementation was unique and custom per platform. And in the end each one looks the same, so is clearly the same brand and structure, but also works well, and works like the specific platform. 


And, this is example is also good because in the end the hardware was never launched. The product exists, but is only the website, app and mobile app. Which is fine, as there was no core device, with branches. The core design was the core /design/, and every branch was a branch. No refactoring to implement it this way. 



And, I just used Mobile First as one example. I didn't want to get past "contrary" to "naysaying," but it's a good example of why I disapprove of a lot of these pithy phrases. They are overheard, learned from someone who didn't get it, and then get misused. I am seeing Mobile First interpreted as "whatever I want to build, that is mobile, first and only." So, I know teams making an iOS (or Android) app, ONLY. And they are so laser focused because this is their mantra, they don't just ignore fallback mobile web access (or: Usablenet is good enough!), they ignore the other OSs, and do a terrible job making the appstore (or marketplace) look like the same brand, or sell the app particularly well.


But again, I see everything misused. If DFES gets any traction, it will keep me up at night how it's being used for evil. 

8 Nov 2011 - 12:18pm
anna banana

The idea of developing one set of IA for all the platforms is very seducive. However I've found that the user experience can vary greatly depending on the platform.  There are apps that are designed specificaly as utilities and thus can exist on say desktop/web as a full blown client and then have a mobile subset, which is still a utility but with a much more narrow, focused scope. Then you have desktop apps and their mobile companions which are just teasers, fun apps to play with.  Different platforms also to an extent dictate the kind of functionality you need/can deliver to your users since not all platforms are good at doing everything. Therefore I personally see UX as something that drives IA, rather then the other way around.


8 Nov 2011 - 4:36pm

Okay, thanks for the additional thoughts.

I suppose that in your example, it works better because the context of use is, more or less, the same. An eReader is, more or less, an eReader regardless of the device it runs on. People more or less have the same needs and desires of it.

I totally agree that design within a context of use should be reusable across platforms with only minor modifications to make it feel native/comfortable based on, e.g., input methods, display size/orientation, and platform design language.

On the other hand, if you were to consider, say, an ERP solution. It seems not unreasonable that people would need/desire different interfaces based on if they are sitting at a desk focused on approving a stack of invoice payments versus getting a notification to approve an invoice payment via a mobile device while on the road or at the beach.

Yes, there are shared goals (reviewing and approving invoices), but on the one hand, you might want to optimize the interface for, say, a batch review and approval versus a quick in and out single approval.  If you tried to share the interface, especially the desktop/batch optimized one for the mobile context, it could very easily suck (and possibly vice-versa, though maybe less so--hence mobile first being not a bad principle).

Or a CRM, where when you get back from a conference, you want to quickly bang in all your new contacts from their cards, look for duplicates, and possibly reach out to some, versus a one-off meeting while on the road, where you just want to quickly add some basic info about one person. The mobile app might leverage taking a pick with some OCR and that's it, while the desktop CRM app serves both batch and other related needs you'd probably be more likely to do in that context.

Or a university Web site vs. being able to check the status of your application from your phone. The IA of the mobile app will typically be very shallow and lean, while the Web site may have everything and the kitchen sink, including checking application status.

I'm just rambling off a few ideas, but it seems to me that unless you really do mobile first, your chances at a shared IA are limited at best, and even so, the needs/desires in the office/desktop context can far outstrip those of the mobile (at least in breadth).  And while you might get away with a "add on" approach for the desktop (i.e., the mobile is a subset, but the same as far as the subset is concerned), that could easily break at some point and require a more suitable IA (and corresponding UI) than what makes sense for the mobile context.  Not to mention the differences in input methods, which could require more work on, e.g., a mobile touch device (where keyboard is the enemy).

I'm not saying that you're not on to something--just that perhaps it has to be scoped a bit more, e.g., design for many screens (in the same context of use) instead of all.


P.S. You should reach out to MK if you're serious about the book thing.

9 Nov 2011 - 11:42am

First, MK? I had been thinking of talking to my O'Reilly people after they see sales numbers, and I met Lou Rosenfeld a little while back who said I should call him up for my next project. So, keep telling me what is wrong with this, so I can make it more sensible. 

Second, I'd never advocate "add on" approaches. I do feel that tacking on desktop is as much a half measure as tacking on a limited mobile version always was. I hope I didn't imply that. 

And to the key point, I think I agree, and for simplicity and relative ease  -- or just that I am terrible at describing what I meant --  shortened the description of what a single IA is. The eReader, briefly, did have to have fairly different core needs for each channel. The device (or the mobiles) were focused on reading, but the desktop web was about discovery and management (and for licensing reasons, you could /not/ read through the web). But we solved this by slicing off the the unavailable parts, and having different parts of the shared IA serve as landing pages/portals for those experiences. 

Another example I have worked on, not dissimilar from the examples you posited, is a series of account management portals I worked on. Consumer (pre and post-paid), several types of business, government. Used by end users, account managers, telecom managers, purchasing agents and customer care reps. And, used on desktop web, via a call center interface and on mobile handsets (as well as having to think about what printed bills, emails, etc. look like). These are interesting as they didn't all come up at the same time, but over a period of years. Of course, they had quite different behaviors, functions and information for each experience. But they shared a common underlying structure, such that I was able to bang out a basic IA for the All New Government Portal in like three days; because it wasn't new, it was just using the common IA themes.

Maybe I need different terms for this common IA concept. For the account management example, it occurs to me that sometimes it is more like the grid and templates of an interface design (or even patterns and principles); not the actual individual state wires or comps, so maybe it's not The IA, but an underling, guiding structure instead that informs the creation of the IA for each channel or user. I'll have to re-read my design process philosophy and see if I can work that out better. 

Keep it up. I'll take all advice. 

9 Nov 2011 - 4:55pm

I agree that terminology shifting might help get your ideas across. At least for me, the terms seem to be engendering unnecessary confusion. But more than that, having a fully fleshed out concrete example (including diagrams and such) would be essential, IMO. If you do a book, I'd suggest that would be a core part of it--showing what you explain at each step of the way. (I know you can't really do that here.) And while you build out maybe one core example, you could mention how the same concepts could apply in other contexts as well, with less-fleshed out examples/explanations.

MK = Morgan Kaufmann:


10 Nov 2011 - 12:59pm

This is all good stuff. I do a lot of theory for starters, and have to be reminded to put in pictures to explain. I am gonna present this at MoDevEast in a few weeks, so will start working on a diagram or two I can show off. 

Process also. Modifying the lists in my old process book (where I used an Information Design mentality):

  1. Gather (collect info)
  2. Define (set design objectives, etc.)
  3. List Features (agnostically; every feature you might need)
  4. Filter (cut those not needed, duplicative, etc. - maybe some are flagged, but left in, and will appear in certain channels?)
  5. Group 
  6. Prioritize
  7. Re-Filter (iterative: can always slice off unnecessary or duplicate items. More pop up after these steps, though)
  8. Arrange (In an info design or IA sense; arrangement by box model on a notional interface)
  9. Branch (split features per channel - I have a few tactics for this, like shadow masking)
  10. Optimize (The "Arrange" step, but now a bit more specific, per channel, input, output, etc.)

Exiting this process you have IA, and a sort of Hi-Level wire (words and boxes, only) for each interface. As well as "something superordinate to both." Maybe it's a "feature matrix," or "-map" or something. Concept works for me (maps to my theory and successful experiences), but needs a good label. 

No need to respond unless you want to. Just putting it down, so I can think about it later in the context of the discussion. 

1 Dec 2011 - 4:00pm

As promised, I made it a presentation. Will be talking about it at MoDevEast tomorrow (look it up if you are in DC, and not already going or otherwise engaged), but have posted it to Slideshare today. Enjoy:

Syndicate content Get the feed