Design for Every Screen

Ever since mobile became really, really cool when the iPhone came out and every designer could happily show off their mobile credentials by having the latest one, there has been an influx of great new ideas accompanied by pithy little catchphrases. I've been somewhere between suspicious and dismissive of many of them, sometimes fairly publicly.

For all the good it does. Here I am mentioned being perceived as agreeing with Mobile First alongside Luke Wroblewski and Scott Jenson, up on stage no less. I never really did.

But lately I've been presenting a bit, and otherwise talking to folks all over the place, and therefore thinking more about many of these topics. First is that I promise I've never just been deliberately contrary, but none of my specific arguments ever stuck that well. And second you should know that I do not just make assumptions, but try to get to root meanings in order to act on information and do my job better. Just check out my work or how long the book is for proof. You can't shut me up when I get on a topic.

I also get tangential. Back on topic, I think that I'm suspicious and not embracing of a lot of these catchprases largely because I have gotten into this field differently than some others. I did art and graphic design from the time I could pick up a pencil, but was engineering-focused from Jr. High onward. I did grant-funded aerospace research in High School. I was the first researcher in the water tunnel at Wichita State University. But when I got to college I sucked at statics & dynamics, and some of the math, so eventually had to leave the program and fell back to art. Learned a lot of good stuff about competitiveness, criticism and understanding design reasoning there, so it was good in the end. I did graphic design work before I even graduated, which immediately (1995) was followed by "can we make a website also" requests from clients. Over a couple jobs I moved from my previous understanding of holistic design to true interaction, human factors, HCI and the emerging fields of UX. I formed teams and we taught ourselves how to be good designers of interactive systems.

So, despite pretty much getting into mobile from the web design side, it always involved data being fed from old systems, terminals for customer care reps, or email, or mailers or magazines. Or often, several of these.

I've been designing for multiple devices forever, since at least the late 1990s. The same stuff in print, CD, TV, web. Envelopes to put the brochure into. Etc. For another currently-cool example, I've been doing little hacks to dynamically resize and reflow content to different browser windows for years – so much so I keep forgetting that it's now called "responsive design."

If you think any one screen, size or channel solves your problems, think again. Netflix has to have a TV UI, sure. But have you noticed the Wii has a browser? Or what if Google TV stops being terrible, or Apple does break into TV in a big way after all? You'll need a 10-foot UI version of your website, and it's no longer just a real big PC monitor; just Monday, a report that console games are the #1 way to get online content to the TV. You might need a TV UI version today. Or yet another app for yet another audience. Technology isn't done growing, and sticking to any one technology is as bad as any other.

I've started calling this – at first somewhat by accident – "design for every screen." As you read on you'll notice it's not quite true, so I admit it's my own clever phrase. But it's closer than a lot of others, so I'll stick with it.

Devices and Channels

Another one of those marketable bits of phrasing from the past year or so was deciding that mobile context is no longer interesting. So I'll admit right off we're closing in on what I always called context. But "mobile context" has itself become saddled with improper assumptions of its meaning. Instead of throwing it away, I think we need to resurrect it.

Partly, because I cannot think of a better word. But also because I've been using the phrase for at least a decade. I went and looked a few weeks ago, and indeed have design documents from 2001 talking about the context of use. These were about the difference between consumers, several types of account managers, and call center employees, each of which had different levels of knowledge, training, etc. For a desktop web interfaces. And some had different use contexts, on the road, in an office, on specific hardware we knew about.

Mobile just added one more context when (around this same timeframe) I started tacking on mobile interfaces to the account management portals. But the then it added dozens. Doctors are not financial analysts, even if they both live by SMS and BBM. The growing variability in use of mobiles made them just like the desktop web. Meaning, lots of them.

Sure, there are some special contexts, because you use them wherever you are, instead of at a workstation of any sort.

And, the variability is bigger than you think. How many touchpoints do you have with a typical service, or company? Paper and ebills, other mailers, websites, and that's all supporting, before I get to the actual service which might be on the web or an app or a set top box. And more all the time: I watch TV on the website for my satellite provider more (when traveling at least) than through the set-top DVR.

Let me get back to some specifics, so we can talk about real products instead pure philosophical arguments. In the mid-2000s, I spent a long time doing a series of billing and account management projects, basically centered around some web portals. But only centered there; lots of other access points existed:

• Desktop consumer web
• Mobile web
• Mobile app
• Store terminals
• Call center terminals
• Call center logging
• Call center voice communication to the customer (scripts, etc.)
• Kiosks
• Printed bills
• Bill inserts
• Envelope printing
• Emails
• SMS
• IVR
• And probably a couple more I forgot.

When I look back at my project files, it turns out most projects I work on are multi-channel, even if not multi-device. If you are just making an app, it's hard to not have a website, optimized for both desktop and mobile. And you better think of how it will look in app store, and how it installs. And... so on.

Design for Every Input

How about design for every input? I spend a lot of time reminding everyone that it's not just touchscreen, but also scroll & select; even lots of touch devices have keyboards and the very large category of messagephones are just 10-key scroll-and-select devices when folded. If you pretend everything is touch only, then your app looks stupid when it won't work right with the keyboard out.

But did you remember other inputs? Take a video sharing service (like some I have worked on). Why make users go to the desktop web or download an app, just to upload? We added MMS and Email services. Send to a specific address, and it goes into your account. And, this worked great. These are popular services. Do I need to remind everyone that Twitter is an SMS-based service? How can you leverage other channels to allow user input?

If you are not following my logic here, it's just an extension of the previous thoughts that everything is slightly more complex than it appears at first. Even if you stick to the desktop, web is just one input/output channel. You send customers emails, and then they can respond. They can call you. They send back bills in paper, no matter how much you wish they wouldn't. This is all part of the experience and you better address it all at the same time.

Design for Every Screen

Generally, when I talk about these principles, everyone agrees. I come away from client meetings with a task to show some multi-channel scenarios, or permission to architect the system with device agnosticism, so we can discover the right channels organically. And that works fine.

But like a lot of my processes, it doesn't work so well when I task others to do the same thing in my stead. I'll even make those basic deliverables, and then move on to another project while just supervising further design development. And it still falls down. So, we need to come up with some methods by which design for every screen can be carried out.

Well, not really. Because they already exist. Pretty much every design methodology will work just fine. Process I have published work fine, but let's go more generic. How about some basic tenents of UCD. If you can find a definition that doesn't get all hung up on a channel (really, Usability.gov only websites need to be designed?) you will find some of the same principles I've been talking about:

• Audience – Personas, and anything else you can use to determine
• Purpose – Use scenarios and use cases to understand how the product will be used, what tasks and goals exist, and what features will be helpful to get there.
• Context – Yup, we're back to contexts of use again. And, you'll see again that context is a fundamental to understanding the use of using any system, not just mobile.

The difference between a lot of practice with these processes, and what I want you to do is two-fold:

1. All answers are valid – Do not set constraints, or make false assumptions. Let the process lead you to audiences, purposes and contexts you might not have thought of.
2. Actually follow a design process – This is key. No one does a design process anymore. Even people who gather at monthly meetings to talk about how great process is, read books and chat about it, end up just sketching ideas immediately. And the sketches are in their domain; if you are a web designer you make a desktop website, if you are a mobile designer, you make an iPhone app. Always.

To reiterate: cut it out. Pop open books if you need to, but gather information, answer your basic questions and develop whatever else will help you. Even if quick and dirty I say you should always be putting problem statements, principles of design and personas up on the wall. At the least. And you can do this in about two hours if you need to. It's not something that has to take six weeks, or six months.

Design for Target Experiences:

There's a third facet you'll need to stick to also, but it's less about principles than communicating to clients, so I didn't include it in the list. You may have already figured it out, and are sneering at my rainbows-and-unicorns world where everything we want gets built. In reality, of course, there are time/people/money budgets, and only a few things get built. So, you are still only getting a website

At first. You, as the designer, need to keep saying "the first release will..." and then keep putting up IA diagrams of the target experience. This is a great phrase. Unlike "problem statement" or some other things that cause grief and need euphemisms, "target experience" goes over great for all levels of IT and business folks. We want to be here, but we also know that pragmatically, we can only go this far... today. Keep saying it like that. Be and act realistic about the whole thing and you'll be surprised how much you get snuck in.

And not in an evil sneaky way. "Sneak in" would be one of those phrases you do not use in front of the clients. What I mean is, go back and look at some of those inputs and channels above. Your product will have email, SMS, printed bills, customer care. Or at least a few of these. Nothing is a pure website. So when you design for every screen, you are not surprised by a sudden request to make the email messages not terrible, 3 months after launch. You designed that, along with all the right error messages, and an easy upload scheme, right from the start. If it's getting built anyway (like outbound email), then your design goes in on the first phase.

That is because this also works very well with a lot of product development and software development processes. They like plans. Agile, for example, actually has a backlog of features. You can simply fill up the next 18 months with features, immediately. You are not perceived as annoying and overbearing, but as a go-getter, trying to make the product as good as it can be. The first person to show up with a list of functional requirements (or Stories, or Features, or whatever) has more influence over the final output than is immediately obvious.

Design for Change

Of course, you will learn as you go along. And you will learn you were wrong. User tests, analytics, customer-satisfaction scores, close rates, will all tell the real picture. Your second phase will become less important, and something else pops up, for example. But you will look okay, as you've got a target experience. Which is just a target, you must be willing to shift to the data, and say that out loud.

And, you will not be surprised by this – at least not entirely. Because your multi-channel, IA-based target experience looked at everything. You've at least got a sketch and a set of bullet points. When research comes back with a recommendation that you are years behind the times, and you better do something better than Usable.net for your mobile site, you can pull that out and be helpful and speedy.

As long as you are not "told you" and all arrogant about that. There's a limit to how much you can trust my client-relationship advice.

Implement for Every Screen:

A key gap to getting a good, holistic experience still exists: the gulf of execution. No, not Don Norman’s gap between stimulus and understanding, but the difference between what you give design and what comes out of the development team. I'll come up with a good phrase to replace that, someday.

I know some of you develop their own code, already has a terrific relationship with their developers, or believes your process solves all. I’ve been there and say: Some day it won’t. Even if everything is wonderful, can it be better? Usually. Even if not enough to mess with, find out why it works so you can fix your next company.

For everyone else, there's hope. And not the passive hope that this next development process or corporate reorg fixes everything. They will embrace your principles, which for this stage we can define as:

• Design holistically – Systems, not pages, not widgets, not buttons. Just like I've been saying, design extensible, system-agnostic architectures, and end-to-end experiences.
• Develop good objectives – Tie to the enterprise, and the product owner, but develop objectives for the team to embrace, and which can be achieved by them, and by the product you are building today, and tomorrow.
• Own your design – You can't just put a target design on the wall. You have to believe in what you give to them (without changing your mind halfway through the release), and you have to keep reminding everyone to implement the existing plan with each future release.
• Get everyone to buy into it – You can't do it alone. Even if it means adjusting or even collaborating get a plan and design everyone can get behind. Not just live with, but actually believe in.

I've developed a few tactics over the years to help with this. Actually, a lot more than this, but these are the key ones. And they aren't a trick or a stretch. The design process I've been talking about, the process you have worked through to get the the implementation stage is very much in line with good software development. All this makes sense to implementation teams.

• Don’t walk away – Always stick with the project through development, at least making yourself available for questions, rework, changes and testing. Ideally, become integrated into the team, and attend daily meetings, test planning, and so on. Plan on this from the start so your schedule and budget accounts for it.
• Set goals for everyone – Those business and user goals you should have developed at the beginning of the project must be translated into actual, measurable metrics. Then, try to make sure they get measured. Push for these to be the project level measure of success for the whole organization, instead of cost savings, efficiency of developers, or other internal measures.
• Make object-oriented designs – Sometimes this is just called “modular re-use,” or other things, as “object oriented” is a larger set of principles (it all originated in development) and might confuse development. But I like the sound of it. The core concept is the same: Instead of designing every detail for every state, and building by state or building hundreds of items to bolt together, a few dozen modules are built and re-used over and over in common templates. Easier on you, and easier on development if they work that way.
• Practice polymorphism – Sorry, it's another of my troublesome words; this time, not bad, just meaningless to many people. But developers tend to love it. Essentially, variations of objects are still the same object. If there are several variations of an on-screen module you design, make sure you express them as variations of each other so these are clear. This is a polymorphic item. Of course, if there is only one variant (omnimorphism) then that should be explicitly stated as well. Always keep in mind efficiency and re-use.
• One IA for all – As discussed at great length above, a single IA diagram will give everyone a single, simple concept to hang onto. Enough, that developers will stick it on the wall of their cube. This is the best you can hope for; most developers won't put design objectives or personas on the wall, but this isn't bad.

As I said, there are other tactics and facets to remember, but they start getting pretty detailed again, so are almost a side conversation. Don't forget branding, and to communicate in a single voice. Good design will automatically be accessible, multi-platform and easier to manage and implement. And so on. I suspect if you have a design/implementation tactic, I believe in it also, and just say: don't forget to add it to your checklist, and start thinking about it as early as possible.

I have used a lot of my own experiences above. But those, and the long time I have been in mobile (or doing these other things) is not even important. I have worked with others who had their first mobile experience while I watched, well into the everything-is-a-smartphone era. And if they have a similarly technical background, or a systems-thinking approach, they do just fine approaching the design not as mobile first, but appropriately, bottom-up, and with every interface and interaction the end user needs.

Anyone can, and should be designing for every screen, every input, every device, and every context.

Sample page from Designing Mobile Interfaces

We're all the way to QC1, which means Quality Check, as I get it. I think there's a QC2 in a couple more weeks. It's tedious work, but also thrilling to see it not in Word, or on the web, but actually in a book format. Enjoy: And don't forget to pre-order before it comes out in November. Now 560 pages, but Amazon shows much less than that. I suspect you will not be able to get it for $30 when it comes out.

The most interesting thing about the Kindle announcements

I found Amazon's announcement Wednesday to be very interesting. Almost unexpected. And I don't mean the Fire or Silk parts. Or the pricing of the Fire. What I found really interesting was this: Yeah, just the line of new products. But that's it. A whole line of products. A new low-end, improvements to the e-Ink, removal of the keyboard (more on that later). Not just retaining the old models, and maybe lowering the price, just to appeal to cheapskates. You'd think that based on rumor, and pretty much every other review or comment coming up to this, or today.
A key reason I like seeing stuff like this is that it continues to vindicate the scope of Designing Mobile Interfaces. A year ago, when Eric and I started writing it, there was lots of discussion about how much we'd focus on iOS. "Um, not really at all." So, also Android... And Blackberry? No, there are plenty of those sorts of books. We made a mobile design book. For all of mobile. Check out this pattern on Keyboards & Keypads for one example. In there we talk not just about the best way to make a touchscreen keyboard (and we don't just say "do what iOS does" but also hardware keyboards, also keypads and triple tap, and even scroll-and-select virtual keyboards. Wait, why does that sound familiar? Not just because my PVR does it, or my GPS, or I examined a lot of products and it's just a way to do it, not that... Oh, yeah. Because the new low-end Kindle uses that exact system. And why? Hell if I know. I don't work there. I'd guess that they found people don't type as much as expected. And it helps make the price point, and so on. They don't do this stuff randomly.
And that brings up the point you actually care about. If your mobile strategy is to make an iOS app, or you are updating your product to have a color touchscreen, and you abandoned the old way, you are probably doing it wrong. Amazon is not good at everything, but they are pretty good at some stuff. And selling eReaders is one of those. I am not the sort of designer who takes everything Amazon (or Apple) does, and slavishly copies it. But Amazon is a mass-market success story, and with the Kindle they had amazing success with a pretty new class of product, which they are clearly trying to make available to everyone possible. New technology doesn't always have to be expensive, new versions don't have to be cutting edge, and the low-end is a huge market. Are you focusing on the bigger market, or just what you think is cool? If you like everything I said, and think your product needs some thinking like this, maybe we can work together. Go ahead and contact me about it.

Tiles, Widgets and Icons

Ever since I read Itai Vonshak's tweet about John Dvorak's article on "the serious flaw" with Windows 8, I've been vaguely annoyed by this misunderstanding of how an interface should or could work. Windows 8 is, conceptually, at the presentation level, an offshoot of concepts we've first seen in Windows Phone. And Windows Phone (like everything else in the world) has been evaluated (by tech columnists) as a straight-up iPhone competitor. I gather that Dvorak thinks some people sat in a room in Redmond and went "I've got it! We'll make all our icons square, and blue! That'll differentiate it from that darned iPhone. We'll show those meddling kids!" I don't work for Microsoft, and didn't do any work on any of this UI. In fact, before we go further, I don't own one of these, and don't particularly have a warm place in my heart for Microsoft. But fair is fair, and I'm judging this on it's merits, as I see them. As soon as Windows Phone was announced (as I recall, even before we saw images) it was pretty clear that they were taking a quite different, not just putting their spin or skin on the "compete with Apple." I think it's a rather good approach. If you design the system (any system, of any size) to be entirely about running applications, then your application discovery method better be solid. When Dvorak talks about how he recognizes icons, or accuses Microsoft of all but switching to a DOS CLI, this reveals his misunderstanding of how mobile (and some other clever systems) can work. Instead of finding and running apps, you can be served information immediately and contextually. Skipping the bigger discussions of push messaging and contextual surfacing, Windows Phone (and I presume from the images, Windows 8) tiles are widgets (ask me later why this links to "icon"). Widgets, in this context, present little snippets of data, or even useful bits of data next to other bits of data. Immediately. Without having to explicitly launch them. Aside from generally observing everything I can about mobile, I have a Windows Phone user right next to me at work. I asked him today to demonstrate, and he demonstrated exactly this use of it.

I can just open it up, and look at it, and scroll to get more information. If I need to know who did that, I look to the side and there they are.

And no, he's not a designer, or particularly a mobile guy, and I didn't set his phone up for him. I've never even touched it. Based on many other observations I have made of all sorts of mobile users, a lot of them use their devices this way. You don't drill into the app, or even launch it. You just un-sleep the screen and glance at it. Maybe, just maybe, you have to scroll a little ways. Or, I claim from all these, they want to. I still feel the same way I did about Widgets in 2007 , and increasingly think they are not just a good thing to have available, but a key attribute, and may become (like Windows is now pushing towards) the one best way to get to information. There are other platforms that have widgets. My Android handset is almost entirely widgets, using icons only when there is no good widget. There are related ways to work in this sort of mentality, like WebOS which leaves the application as a sort of widget/tile on the desktop; the set of them changes moment to moment, but they aren't just launched and then disappear when you go to launch another application. Not perfect (or even much alive) but another approach, certainly. I'd talk about Symbian, but that would stretch my "near-death OS examples" to the breaking point. Forcing users to scan a grid of icons is, to me, not just a failure on mobile, but is a demonstrably secondary action in desktop systems. Think of the Applications folder on OSX, or the All Programs link in Windows. This is not the high use case, and is a simple fallback for when you need to get to something obscure, or which you cannot find otherwise. And how to get around this? Search, launch bars, recently-used application lists, and other methods to allow the user to find the most likely applications. With a distinct move towards doing this automatically for users, instead of assuming they will set it up for themselves (because they won't). Someone will probably see this as an assault on iOS. And I am fine with that. Aside from being comfortable with fanbois interpreting everything non-glowing as villainous, this is behavior I have observed; satisfaction does not always correspond to task completion, much less efficiency. And it's not evolutionary. This is a twisting path. A lot of stuff much older than this let you prioritize better than just "what is on the first page of the app listing," like say S60: Darn it, I did mention Symbian after all. Oh, well. But since we're comparing to Apple, let's talk about another common refrain against Windows Phone – that it's over-designed. In the sense that it's designed to look good to executives approving it, to focus groups, or is just a misguided visual designer's wet dream. There are a number of ways in which I disagree with this, and find it to clearly have been well thought out by some pretty clever UX designers and IxDs. The first has even been pointed out by some who dislike it. The device has pretty notable, integrated teasers of additional function or content. Tiles are partly displayed on the edges, animations help communicate what the interface can do. Even that big dead space to the side is about leading you to change panels to the right. Another key one (there is lots of hate) is about the density of information. Those big words bug everyone, because they are not efficient. Compare the number of characters, lines of info or anything else you want to almost any other device and it comes out behind. Or does it? When I think of a lot of the use of mobile, even though context doesn't matter anymore, I see a lot of glanceable use. My co-worker, for example, will regularly use his phone on the way to a meeting. Large text and images as iconic representations helps him use this on the go. I have noted, a lot more than any of the devices I am using. I sometimes have to stop to read where the room is, on my high-density information display. While we're at it, those giant, wasteful black gutters between tiles, they seem to help reduce click errors (and improve confidence of clicking) in all environments. I have seen the design of Windows Phone disparagingly described as being like poster art. Which I say is a good thing. Posters work.
A question I assume many of you will ask is: Why isn't Windows Phone the market share winner? Well, lots of the usual reasons. Marketing, price, distribution, hardware, networks and operators, and so on. By no means does the best device win. Everyone seems to now be comfortable with OSX devices selling in their non-dominant market, so think about that. I'll tell you that a lot of these relatively niche devices (like WebOS or Windows Phone) are beloved by most users of them that I know, or have interviewed for research. They give them up due to unavailability, or lack of key apps or some other aspect outside the core interactive design paradigm. But also, we may be getting there. Android is doing rather well, and if you were inclined to, you could say it's because they support widgets, and this flexibility of layout is at least part of the success. I actually cannot find a useful "reason I chose Android" study to say that, and it's possibly untrue, but everyone else lies about statistics to prove their point. So I say that Android wins because the idle screen is more flexible and can be more mobile-optimized (I actually /do/ talk to end users who say this is why they chose it). And even more importantly, tomorrow is the future. Mobile, more than other technologies, changes all the time. And often in unexpected ways. On Thursday, a new head for HP. Is WebOS on the way back? Or this recent InfoWeek survey of mobile OSs (available at their site, but thru a subscription wall so the link may or may not be good) that shows Windows Phone perceived as just a tidge less useful to the IT professional than iOS. The future doesn't even have to be a variation on what we have today. There are OSs on the market off in other corners of the world you might not have heard of. Speaking of Itai, his Else phone prototype was a shockingly amazing piece of design in every way; I see no reason something that radical cannot make it to market sometime and surprise us all. Or maybe the web will take over, and the device OS won't matter. Or… something else. I have no idea what tomorrow will really bring. But it won't be more grids of icons.
For more on designing widgets, or just making those bog-standard lists and grids the best they can be, check out our forthcoming book Designing Mobile Interfaces. Pre-order from Amazon for a significant discount, or read the content online right now.

Interactive Criticism and the Cult of Clean Design

This discussion of minimalist posters got me thinking of some of the design problems I have been encountering lately. And that got me to thinking that I have been seeing a variation of this for years and years.

 Unlike much of the graphic arts scene, it seems that interactive design hasn't gotten over it's trend of simplicity and whitespace for their own sake. If anything it seems to get worse year after year. While I won't quite blame Apple – and everyone else who follows that design ethos of spartan minimalism in everything – this is the design I am talking about.

 But the problem isn't really that we're stuck in a design rut. We are, but it's much more that not everyone evaluates everything the same way, with the same depth. People use a cool new product (on their iPad), then come to work the next day and say we should make a product as clean and easy to use as this.

 But "clean" and "easy to use" are different things. In the same way that "look and feel" are two different phrases (hence the "and"). "Clean" rapidly becomes misinterpreted as "low-featured." "Easy to use" becomes misinterpreted as "easy for every single person in the world to use." "Simple" turns into "simplistic," and we cut features not to get to core principles, but because they are visible.

We cut features not with a knife, but with an axe. And rapidly, any feature is worthy of being assailed not on it's merits, but on it's immediate visual appeal in a wireframe, or comp. But it's a false argument. Anything, – anything – can be assailed as cluttered, complex, or any number of adjectives that are, really, meaningless. There is no way to argue against "you don't want to confuse the user..." on it's merits, because there is no internal logic to this argument; it has no merits, really.

I routinely want to challenge such arguments and bring us back to principles, or to the scientific underpinnings of the practice. "Hard for which users?" or "But this feature is required to meet objective 2…" or "But the research proved that 100% of the participants prefer…" So maybe we can win the argument by counter-attacking their premise, and getting to the core of the issue like this. At least on the face of it.

Because really, we're missing a key point by calling it a design issue. It's a communications issue, or maybe (as Alexandra Lange responded in the comments on that Design Obsever article), an issue of design criticism. I admit that I would not have made any of these connections without her article. As practitioners of IxD, UI and UX, we try to make decisions based on provable knowledge. You could even characterize it as a scientific approach to design.

But it's not always true. Opinions still abound in discussions amongst ourselves. About interpreting what actually happened in a test, or what situation we are really looking at, so what heuristic should be applied. If you were to watch a design (or art) critique session, you might think it's just a conversation, but really this is a fairly formal construct, with rules that make it work to everyone's advantage.

You cannot complain about a work without merit; "I don't like it" doesn't fly. You better have a good, reasoned argument as to what you don't like, in what manner you don't like it, and maybe even suggest a solution. It better address the intended audience, or the purpose of the object. Assuming use outside of this may be irrelevant.

 As the creator, you better accept all criticism, and I don't mean passively; you have to engage in the conversation, to make sure everyone understands each other, and so group discussions can help reach consensus on the best course of action. Note that I didn't say "solution." One individual still ends up cutting the wood, or painting the line, or placing the pixel. Iterative critique gets it closer to the intended goals. Mostly, you cannot perform design criticism alone, or as the only proper practitioner of it; everyone has to participate and follow the rules. 

 Interactive design doesn't have any of this. Sure, your studio might work fine. And I have absolutely been on teams – or led teams – that worked exactly like this and had terrific group design critiques (and terrific products came out the other end). But as a whole discipline we do not have a method of critique. We argue, cajole, express opinion, refer to previous solutions, and our favorite products. We make deals, and end up splitting the difference so we can stop arguing and get to the next point. We decry ornament (especially when we bow to the altar of Clean Design) and insist we evaluate based on interactivity and process.

All while we draw comps and complain about crowding objects, and demand white space be added or everything align to the grid. We carry out common practice, and build what is easy, instead of finding and defining what is truly, demonstrably best practice. We do not share, or tell anyone else about our design solutions. Maybe not even the guy in the next pod, but almost never to the design community as a whole. We design in isolation, take criticism as insults to our work, and believe there is design that cannot be improved upon. We perceive openness to opinion, fuzzy concepts or acceptance of change as weakness. We are simply confused (and maybe assume it's a trick or insult) when a designer offers to change to an alternative design when a good point is raised by others. And we cannot fathom why our clients do not respect interactive design and user experience as evidence-based, consistently-applied, professional fields, and express sorrow every time they insist we change something based on whim.

 We need an ethos of design criticism. Not a process. The existing ones for fine art and design work fine. And we must not stop disagreeing with each other. We must not stifle creativity, or reduce iteration, or work more in isolation from fear or as a res Of course you know that arguing with the client never really works. I said that up above because that's what I want to do, but another approach is needed.

 So, if you agree, what next? Well, it's simple. Do this. Tomorrow. Okay, it's the end of the week. So, Monday. The next time you bring the team together, lay out the ground rules and tell everyone this is how we're going to talk to each other. In several ways – but especially in becoming a seasoned practitioner of art and design criticism – going to art school was maybe the best education I could have gotten. I've been thinking for a long time we need to teach not just what you should know, but how to do it and how to do it with a team. Not every field of study or school does this. You can make sure to teach your junior designers the skills they need, and not just assume they will pick it up on the way. And you can try to get the right feedback from everyone.

When you walk to someone's desk, and they give feedback, ask them to justify it, very precisely. Nicely, but get to the heart of it. Anyone can answer these questions if pushed to it. Not naturally, but they can. Even your clients. If you are told "why not more like how Amazon does it?" then pull up that part of Amazon, and ask in what manner this solves the need. Ask how this meets the goals of the product, ask questions you know that there are answers to, or which they will enjoy answering. As much as it's been talked about, there is no certifying organization for IxD.

As much as some people get to write books (now me!) and get followed by thousands of people every day, there is no one guru who can change the whole field. We all do it, every day, as we work with each other and improve interactive products. If you like this idea, do it. If you have a better one, do that. But if anything ever bothers you about how our field works, talk about it, find a solution, and put it into practice. This is how we improve ourselves, and our little part of the world.

This has all happened before, and it will all happen again

Pretty regularly, I read or read a discussion of how technology is forging new ground, either for good or ill. But either way, it's all new and therefore we have no idea how it will turn out, etc. Except far too often that's not true. Maybe I look at things too broadly (e.g. I think bound paper things are relatively interactive), but I see lots and lots and lots of parallels throughout history. One example that has stuck with me is the development of the spreadsheet (like Excel, but it very much wasn't the first one). There are a number of pundits that say not just that VisiCalc was the first killer app, but that it was developed from whole cloth. Nothing existed like it before. Except it did. Go look up how to use a ledger book. They're not even like slide rules or abacuses (abacaii?) and are still sold at, based on the variety, a pretty good clip. Another is the ongoing discussion of the future of news media. The old-school reporting staff and well-curated model is, well, old and traditional. What ever will happen to us when this all new world of information gathered from anyone who wants to write up their version of events, from eyewitnesses, and so on? Well, maybe the same thing that happened in the early days of papers, when that's just where the content came from. They'd just print letters on the front page, and often multiple conflicting accounts with no overview or attempt to rectify it. What will the whole world be like when it's nothing but aggregators of individual articles like this?
And I'm not even just being a naysayer here. You can learn valuable lessons from these history lessons. Spreadsheets were designed to be computerized ledgers, adding a few shortcuts to increase accuracy and efficiency like calculation. But that has empowered them to be even more capable, in ways that could not have been predicted. News in the old days More recently, I've been reading this history of the development of the Mac and considering how they came to these decisions on UI which we now see as being fundamental truths. And I often like to re-visit the early history of computing (later chapters are not as good) to remind myself of the difficulties they had in creating computers in the face of tabulating machines. You did know tabulating machines were not computers, right? If not, get out and read some more. There's all sorts of good history out there, that tells you why things are the way they are, and which you can put to use when making design decisions about contemporary interactive products.
Now, back to writing my own -- hopefully sufficiently short and comprehendible -- history and explanation of the basics of mobile telephony as an appendix to the forthcoming book on Designing Mobile Interfaces.

This is what I sound like griping about pixels vs. boxes

For those few who have forgotten to remove me from your feed list, the absence has been totally worth it. Writing (half of) a 460 page book on mobile design was very interesting, and hopefully will be something important and helpful to you all. Buy a copy when it comes out, presumably in a few months. Last year I was on a panel with, among other people, Luke Wroblewski. He was "defending" his then-new concept of mobile first. I was supposed to be the naysayer. But it takes me a while to warm up to people and be abrasive, harsh and disagreeable, so I ended up looking like I agreed with him. Everyone else did, so it was a rather boring panel. We're sorry it wasn't exciting. I did agree with the principles – which I'll get to eventually – but I didn't fully understand how much, or even really why I disagreed with the practice at the time. At the time, I thought I had a nice cynicism baked in, but in fact I'd worked in or with organizations that more or less bought into the concept of UX practitioners and let us do our jobs. Some encouraged it. Since then, I've had to leave that job, and as it turns out that whole world. Not the design world, but the happy design world. Before I go further, I should mention to anyone who works with me, you may or may not know what I am talking about. I have a day job which is separate from my freelance clients, who don't know each other. Though it probably decreases my ability to network and sell, I respect client wishes and do not generally even imply who I am working for. I also have friends, and keep track of former co-workers, and talk to others about their new jobs. And with the writing I have been very much keeping up on the world of mobile (and other interactive) design. So if this sounds like you, and you are offended, there's probably someone worse, or at least it's a composite. Don't get in a huff about it.

It's like I never left

I'll hope we can all agree that the end goal is good, useful design for the end-user, and the way they work. But from there it all falls apart. Let's get right to the heart of the matter. A lot of people use this as the basic unit of design, for all interactive work: I see it used by those who distribute involved raster PSD templates for designing on a specific device, or write up long explanations of how to use Fireworks for mobile design, or who push or promulgate pithy catchphrases like "mobile first," (or "CLI first") really. They often routinely conflate interaction and interface design, or just call themselves "designers" without distinction. Many work at companies who hire designer/developers, or cannot fathom what a designer does if not also writing code, or at least prototyping everything, as soon as possible. Yes, I am enough of a taxonomist to know that generalizing results in generalizations. I don't much care about individual cases. But if you want to talk specifics, I have seen at least three well-meaning, otherwise mostly-useful repositories of information refer to 44 px as the right touch target size this year. If you are not horrified by that, turn in your HCI credentials. You may have noticed that people cannot be measured in pixels. So it was dumb a couple years ago when there were too many Apple fanboi designers. But now even iOS has multiple resolutions. Saying "44 px" without caveat, in 2011, should be tried in the International Criminal Courts at the Hague. It all reminds me of 1999. That's when I started seriously – in front of clients – rejecting the concept of the "page fold" in web design. By way back then even the desktop was becoming too fluid or fragmented to pick a screen size for everyone that was the same. Anyone who starts with a single resolution for mobile is fooling themselves, and wasting opportunities. Without over-emphasizing the point, designing in pixels is dumb. Anything that reinforces or just trys to improve designing in pixels is also dumb. Note that I didn't say we don't need Photoshop. It's open alongside InDesign all day, every day. And I in no way said we don't need visual or graphic designers; I have an art degree, and have won awards for digital art and illustration, but it's not my day job today, and I need that sort of designer to collaborate with. I said "designing in pixels" is bad. Don't over-reach and miss the point.

So, what's your point?

My basic element of design is this: I like words also. If I can get them, well-formatted bullet lists are nice, but if I have to just boxes and words will do nicely. Two pixels together are two pixels. But two boxes together are nested. or adjacent, or overlapping. They interact. They can move. One can conditionally disappear. Don't even get me started on the possibilities offer up by three boxes. The mind boggles. What size are they? It doesn't matter. Or: it depends. On rules we don't just assume, or constrain by declaring a resolution, but by determining some what size and what items stay on each page in which position as the design progresses into addressing different platforms, different devices, and different aspect ratios. This is all based on every other type of design or drawing or illustration I have done or learned. You start with basics and move into details. You start with sketches and settle on aspect ratios, orientations and sizes. Details get filled in as it evolves. So few artists start their work at full detail in one corner that it's generally studied as a condition. Whereas I have seen an awful lot of interface designers start by laying down a gradient bar at the top of the page, pick the color and type the title in, then proceed from there.

What catchy phrase can I use to remember this?

My mantra would be something like "do your job first." Yeah. I am not that great at catchphrases. But I still believe in it. Don't jump to final designs, and don't jump to even wireframing of any one platform and resolution. Let the process unfold. Analyze existing products. Ask clients and customers, then build goals and objectives. Put Post-Its on the wall, then start drawing. With whiteboard markers, and sharpies. Eventually you get to make boxes and they evolve, and branch to the needed interfaces. Doing it all like this might even help you identify which devices and modes in which it should operate. And remember to design for people first. I once was in a meeting at a Fortune 50, who had hired a respected and well-known design firm to do some interactive design. They brought some "mood boards." That's what they called them, but they were single images just ripped from magazines and blown up. Starting your design by copying the last thing you did, the standard OS template, or the coolest new thing, locks you into that first pretty picture in the same way, and everything will be a variant of it, instead of your own design. Let IAs do IA, let Information Designers design the information, let IxDs design the interaction, and yes let the VizDs do everything they do to assure it's all tied together as a cohesive interface. Respect all the jobs, and don't fall for shortcuts, but do your job first, last, and always.

I wish we had a manifesto

If this strikes you as totally the opposite of the way you work, rest assured I am not just some nutjob screaming in the wilderness. I've worked with or for plenty of others who believe in this. There are whole, large, respected organizations who work like this. Ones you've heard of, and who are too cool to hire me. But we all spend more time doing our work, or arguing with each other to get together and realize our similarities and write up a public, non-proprietary process to get noticed. You, no matter who you are, probably believe at some level also. Ever done a whole design session with just sharpies and Post-Its? Ha! I caught you. Try that for a few more layers of design and see what happens.

You probably shouldn't listen to me

I mentioned up front that I can be abrasive and disagreeable. If you don't think so now, you haven't been reading closely enough. I get along with a lot of people well, but (I have been recently told) not always, not with everyone. Don Draper (and his ilk on every TV show) gets away with a lot more than I can, or you probably can either when selling to the client/patient/judge/etc. The right idea doesn't always win out in the real world, so even if you are ready to join the revolution and start that manifesto, you need your day job still. Be ready to lie to keep the clients. I do this all the time. They want to see the home page, so we make one up, with gradients and icons and banner ads that are better integrated than they'll ever be in reality. Then we ignore it (rarely does anyone keep them around) and get back to developing the design the right way. I am sure some people are bugged by the morality of this, but I certainly think the end user and the end deliverable is still more important than a short-term deliverable. I am willing to stretch the truth a little bit. It's in everyone's best interest.

Anchors & Curators

Curated content on the internet is all too much like the employee-picks shelf at the local bookstore (or video store). A selection, maybe even an interestingly thematic one, but just a collection of existing items. And presented with no other information to help you decide, but what you would find if simply searching on your own. Consider instead what people with Curator on their business card actually do. They collect, investigate, verify, and organize. They then build exhibits of some items from the collection, in a manner that tells a story. They add their own content. Maps, brochures, labels. Often, it all works together to make the point, to reveal deeper truths about the collection, and to encourage the viewer to explore further on their own. Compare these two paintings, though 20 years apart, the similarities help point out how the artist has grown in the intervening time. Or, consider the classic format of the national nightly news. Behind the scenes, the anchor is the Head of News. He sets the tone for the whole department, and makes key decisions about what and how it will be presented. Then as the on-air anchor he gives an intro to the story, frames not just the basic facts but the reason we care. If there's a graphic over his shoulder, it may well be a map, so you know where this is taking place. And then he hands off to a reporter who was on site, or at least pretends to be based on footage retrieved otherwise. And maybe, if it's a multi-faceted story, then you go to another reporter who gives another point of view; after the on-the-spot report, the reaction in Washington.
All this is all in relation to a number of posts* and discussions I've read and had with people about the point of online media. And it's coming up since I am being paid during the day to actually develop an IA for a very large product catalog, and integrate existing (magazine and other) content and personal details into one experience. I have seen at least a little of most of the available experiences. I don't subscribe to them because I am un-thrilled with the consumable media available. I still read paper magazines, because even cut down to save on costs, They do a much better job than pretty much any digital version. Web and tablet versions seem to have lost the key point of sidebars or related stories, and just use paper paradigms instead of developing their own; or learning from education, museum information design and broadcast radio/TV media even.
If this seems like a subtle change, it's not. Go back to the examples, and look at how much internet content is served. I call most of that a subset of "portal theory." An article is reduced to a smaller version, on a category page. It can be reduced to a smaller-yet version, even a title-only for a higher level category, for cross-linking or for the (portal) home page. Instead, I am starting to think that I want to break that whole model, and use the intelligence of humans, not just to tag and categorize and group things, but to differently re-order, to choose what is presented and not just sort, and to not just crop but actually rewrite content to present it most relevantly to the context. No, I don't have diagrams, or mockups for you. Yet. Maybe later. The only impediment, as I see it, is people. Good, smart, dedicated people who can write have to be found, persuaded and paid. And too much focus is on technology solutions, and paying for software. We have the software and interaction nailed enough. Now it's time to bring people back into the job of presenting information. Give me a news aggregator with the voice of an anchor, and I'll listen. But it could also be a great opportunity. To give a new type of voice -- or a reason to hope for the future -- to writers, and to the whole profession of journalism. If not this, then something like it simply must happen. Not to preserve a dying business, not just to make money in a new market, but to keep the public informed so we can all make decisions about the way we live.
* Now that I look for the links, way too many seem to be centered around Khoi Vinh. And he's a good voice in design and interactive publishing. But I swear others are talking about it also. And some rather interesting ones I can't quote.

** When searching for the links I ran across this, which I swear I didn't read before. It also has good points about curated computing. Very different ones, but the over use (or I say, mis-use) of the term "curated" is covered pretty well in there, if circuituously.