It’s great to see someone write this up. It’s an approach that we made part of our process at Roundbox Global a few years back and continues to serve the team.

Benefits that we saw included:

• Demolish the wall between Design and Development — no more “us” and “them” with its related miscommunications
• Increased teamwork — everyone interested in making the whole team succeed
• Pair designing — make sure the designs will implement cleanly before documenting, developers point to how we can push the tech to meet design needs
• Reciprocal invitation — involve developers in requirements discussions with the client, especially where technical limits are tight

Through this the team enabled itself to move more quickly before changes in requirements and provide software that met the needs of client stakeholders and end users.

What I find especially interesting is the possibility that various CIOs and IT managers are looking at opening their hardware offerings to more end-user choice, especially in mobile devices.

“If you believe demographic studies, the workforce in their 20s and 30s isn’t going to accept black corporate PCs with black corporate mobile phones and not be allowed to run Facebook or Angry Bird apps,” he said.

Loura was among many CIOs and IT managers at SNW who said they’re facing the same issue — employees want to use mobile technology at work, leaving IT with the job of ensuring that the devices and the data on them remain secure.

As a result, Loura refit Clorox’s employees with HP laptops to replace their old Windows 2k desktops and moved all mobile off of Blackberry and to the user’s choice of iOS, Android, or Windows 7 Phone. They provide these various options while maintaining the data security standards required by the enterprise.

I’ve worked in both large and small operations and my experience had always fallen in line with the stereotype: the big boys lock things down and don’t tolerate questions while small companies let their people choose their tools and keep access open when possible.

It looks like there are CIOs challenging that stereotype. What would really blow my mind is seeing full on Devops in larger enterprises.

That would be a world to live in.

What I find most interesting are the reasons she cites for tablets’ fad-dom because they tell more about the reviewer than about tablets. She approaches tablets from an old paradigm, one that fails to recognize some basic realities of why and how many people use computers.

“Limited functionality”

Tablet devices are only limited in their functionality when compared to full PCs, laptops, and some netbooks. Compared to some other devices (like smartphones) they provide richer interface options by virtue of their larger form factor and beefier hardware.

The problem with comparing tablets to PCs is that it bakes in the assumption that what everybody really wants is a traditional PC.

If we take Jef Raskin at his word and to the end user the interface really is the product, there’s room for consumers to perceive tablets as more powerful or more open despite the hardware stats or code licensing.

“Waning excitement”

Noyes founds her claim of waning excitement about tablets on claims that reviews of the iPad 2 were mixed. The false assumption here is that anything short of all positive reviews of iPad 2 means that the masses have lost interest in tablets. Though iPad dominates tablet mindshare it’s not the only device in the space. Even if all reviewers hated the iPad 2 we can’t declare tabletgeddon just yet.

Consumers tell a different story – iPad 2 launch

The assumptions that all people really want a PC and that iPad 2 is a failure are invalidated by the sales statistics for the iPad 2 launch. iPad sold out throughout the US on launch weekend with Fortune quoting a claim that 70% of iPad 2s sold to people that didn’t have a tablet device before.

In speaking with friends that are still trying to purchase the much coveted device the current technique for successfully purchasing one is to find out when the shipment of iPads arrives at the nearest Apple stores and be there when they unload the truck. Within hours of unloading the iPads are once again sold out and unavailable until the next shipment.

Underlying biases

What Noyes is really communicating is her own biases and looking to datapoints convenient to her preconceptions. Per her bio she is a proponent of free (as in freedom) software and tends to cover Linux topics.

Free software is a wonderful thing, but unfortunately free software and open source software are proving to have little place in the tablet space. Apple’s iOS defines itself by its closedness and Google’s take on “open” with Android is proving less than what we might have hoped for.

That said, writing off the currently OSS unfriendly tablet space as a fad is giving personal bias too much sway.

When I first heard that iPad would use iOS rather than OSX I was displeased. It was just gonna be a huge iPhone! This wasn’t the device for me. At launch it looked like it would be difficult at best to code on it and there were few applications available for diagramming, designing, or creating graphics. I also had my concerns about the walled garden and how that might prevent the kind of “seeing the gears turn behind the curtain” moments that inspired some of us that work in software to choose our current vocation.

Here’s what I had to face: most people aren’t interested in computers as en end in themselves.

It’s not the device, it’s what you do with it

There are many people in this world that have a computer (be it a laptop, desktop, or notebook) only because computers help them to use Facebook, go on the web, instant message, tweet, email, watch videos, listen to music, and in some cases make music and videos.

These are people who have computers not because they think computers are awesome, but that the things they want to do are awesome. Computers are only a bridge to that awesome.

These are people that care less about what operating system they work as that it doesn’t confuse them with interfaces or details of the computer’s operation that they don’t understand.

Tablets let these people do what they want to do without imposing the traditional PC baggage on them. No file system asking them where they want to put their files, no taskbar filling up with programs, no drivers to deal with.

To please these users you need to do only this: empower them to do what they want to do and get out of the way.

This is why iPad has captured the imagination of so many people. They see in it the promise of a device that will let them do what they want to do without burying them in all the traditional computer baggage.

While we want a BMW, Ferrari, or Bugati and itch to open it up on the autobahn, they’re cool with a Honda, Toyota, or Hyundai that has a cool look, a sporty feel, and gets them where they want to go.

They don’t need a “real” computer and wouldn’t make full use of one if they had it.

And if we let ourselves believe that our concept of what a “real” computer is matters to them, we do so at our own peril.

I dig the clear hierarchy of the columns and the clean visual quality but I have my questions about how well this approach would play for the majority of Facebook users. (I have a certain affection for MacOS Finder’s column view but I recognize that many people don’t care for it.)

This is one of those interfaces that I’d love to see tested with end users. Interestingly, Facebook is one of those sites (like Amazon) with a large enough user base that an interface like this could get a small scale A-B rollout and remote feedback without causing disruption for the majority of users. Keep the sample small enough and the test might not appear as an article on Mashable until you’ve done a couple rounds.

What do you think of this design approach?

How would your Facebook friends react to it?

It’s not surprising that Lapin’s daughter, who’s already familiar with the iPhone, was able to make a nearly effortless switch from iPhone to iPad. By design the device interfaces are nearly identical. A win for iPad, but a predictable one.

The juicy stuff lives in Lapin’s daughter’s side comments and the areas where she gets stuck in the interaction. In these areas the responses of a young child prove just as useful as those from the most sophisticated participant in a user study.

Has videos?

Indeed it does. I’m guessing that this expectation comes out of her iPhone experience but I have no idea if she watched videos on her Dad’s iPhone or not. It would be especially interesting to hear that she hadn’t but that it was a natural expectation of something of that shape and size. Some kind of “it looks kinda like a small tv I can hold” association. Lapin would have to clarify that question on context.

I want the one with the camera

This echoes one of the most frequent criticisms I hear of iPad.

I’m still undecided on where I sit on that count. On one hand, it seems simple enough to provide. The iPhone has one, why can’t they put one in the iPad. On the other it seems to me that taking photos with iPad would be awkward given its large form factor. I’d love to edit photos I’ve taken on a touch screen that big but I’m not sure how comfortable I’d feel taking them with something so big. What I’d really like to do is connect a professional grade camera to an iPad for editing and quick previews.

Unwanted multitouch issues

Apparently this is proving a common problem. While holding the iPad people’s fingers run out of the “frame” area into the active touch area resulting in an unwanted touch on the edge of the screen. While on the Home screen this means that touches on app icons don’t do anything.

This seems simple enough to fix on the home screen. Ignore touches at the edges of the touch sensitive area. But that leaves the situation unsolved for other apps and this is a problem that asks to be solved at the OS or device level rather than in software on an app to app basis.

The trick will be how to resolve the issue to the satisfaction of multiple genres of applications. The implications of the unwanted edge touches are very different for image editing apps than they are for launchers and both of those differ from game interactions.

Touch the cat’s face

This one I find especially golden. Daughter is clearly having trouble opening the animal word game. When she first enters she touches what looks like a button to start the game. She recognizes a button as clickable more quickly than an image of a cat’s face that says “Play” under it.

It’s a reminder that there are reasons that we have button conventions. There are times to break them and times not to. It appears that for 2.5 year old users, buttons get better visual recognition than an image with an instructional caption. The designers took a gamble and for certain users it doesn’t pay off.

Usability feedback… no degree required

More than anything though I need to point to this sample when clients say that their users are too simple to provide valuable usability feedback. Providing useful feedback on usability issues or site or app structure doesn’t require subject matter expertise or knowledge of the business goals for the site or app. That knowledge often gets in the way. At its heart usability testing is about this: real people that use your site or application providing feedback as they use it.

Something so simple a child can do it.

iPad specific answers to the creation challenge are appearing. This video for iMockups places a nice face on these answers.

I feel rather silly that it didn’t occur to me earlier in the game that wireframing would be low hanging fruit for graphical applications on iPad. Fortunately Omni Group and others have. As OmniGraffle is a central tool to my work I’m especially interested to see it develop. Things seem to be progressing well. From iPad or Bust! to a Two weeks later follow up things seem to be progressing well. Hoping to see a working app close to next month’s iPad release.

Imagining how such tools could be used in quick sessions with clients and developers, let’s say I’m warming to the iPad.

There have been varied reactions to the iPad but those that most interest me are those that go beyond Apple’s marketing message of “the iPad is a new thing that will revolutionize computing” and ask “where will this revolution lead?”

An angle I find especially interesting is expressed in Alex Payne’s On the iPad.

What I find most interesting is how he speaks to the side effects that Apple’s choice to keep the iPad closed may have for future engineers. The closed system may result in the loss of that magic moment when a future engineer sees behind the curtain.

To set up the binary: iPad is for users, personal computers are for inventors.

That magic moment where you see how the machine works and the code invites you.

• Invent a better way to do something
• Invent entirely new things that haven’t been done before

These invitations are the reason that many of us became engineers. The concern is that without that moment we’ll lose some of the innovators of the future.

I remember that moment and the effect it had on me, so I’m partial to the concern. But I don’t see that concern playing out in my children’s lives nor am I entirely convinced it will in yours.

In most households, the iPad won’t be the only device. For the short term, where there’s an iPad there’s a personal computer. Where there’s a personal computer, there’s an opportunity for that magic moment. The future will show whether our digital lifestyle future will keep to the closed system or whether forces for openness will prevail.

Another valuable angle is: the binary is a false one.

• Not all invention comes from engineers
• Not everybody needs to get into how the machine works

My Dad would love to have an iPad. He likes computers but the iPad epitomizes the “just show me what I want” approach that he’s hungered for in a computer for a long time. He doesn’t care about command lines or when abstractions leak. He wants his applications to just work. Email, social networks, office documents. Having a device that lets him do that with minimal thinking about installation or configuration would make him very happy and he wouldn’t feel that he’d missed out on anything.

I have a hard time criticizing that as an experience designer. There’s a device coming that’s what he wanted. My internal dialog about “it looks like a giant iPod Touch,” “you don’t actually create anything on this yet,” “there’s no chance to see the man behind the curtain,” these things don’t matter to many people. They just want the thing to work and work as transparently as possible.

The closed system will provide that for many people.

iPad in various respects isn’t what I’d hoped for. I wanted something more open. At this point in time, the closed system is a feature. It lies on those of us who prefer the open system to provide an answer. How will we provide an open system that offers simple installation of applications that get out of users’ way as much as possible.

Pre-release expectations

Talking with friends about the iPad back when we were all still speculating on the name we came across rumors that dashed our early hopes. The tablet would most likely use iPhone OS and the App store as its sole path for software. A closed system.

From there my thinking went to how Apple would differentiate itself from humdrum tablet pc offerings already out there. iPad isn’t entering an empty category, it’s defining a category that’s been poorly executed and marketed up to now. (Remember Macintosh? Same kind of thing.)

How to do it? You focus on what iPhone OS and App store do best:

• Consume media and data
  • Music
  • Video
  • Social media
  • Web
• Small tasks of creation
  • Email
  • Social media

iPad does this and from what the marketing tells me, does it incredibly well. (Gotta love the gap between announcement and real world launch.) Reading about the product left me a bit flat. My impression seeing video of the email app I think they’ve done some very cool things in customizing the built-in apps to a tablet and leverage options that aren’t available in the smaller iPhone form factor.

Digital lifestyle device

A few years back a key piece of Apple’s marketing message was that the Mac and the iPod were products for your digital lifestyle. The Mac served as the hub for this through the iLife applications. Photo albums, home movies, and garage band recording “for the rest of us.”

iPad is by nature a digital lifestyle device. It’s not for coding. It’s not for heavy duty design or video work. It’s for stuff that I would do on my couch while watching TV. It’s for showing stuff off to my friends when we’re talking in the living room.

Given iPad’s digital lifestyle leaning I’m surprised we didn’t see adaptations of all the iLife apps at launch. I can’t help but think that Apple project teams are currently working on iPad specific versions of iMovie and Garage Band. These are use cases tailor made for something less than a laptop but more than an iPhone. (Add camera and mic to the iPad and iMovie just got even better.)

Until Apple or approved third party apps fill this space iPad will miss a key audience. The current iPad will draw people with cool factor, but as many have noted, it’s a device that’s all about consumption. Many of us want to create on our devices and share those creations off-device (and Microsoft, HP, that’s exactly where you strike back against the iPad).

The most touch-native path to letting people create on the iPad is visual. Leverage the visual and audio-focused digital lifestyle applications that have already proven themselves then expand from there. Let me sync my creations to a computer or hard drive on my wireless network without having to use MobileMe and I’ll lay down the coin right now.

Growing documents

Brown begins by suggesting that designers start documents with a basic nucleus of necessary information then adding detail in layers. He also put forward the idea that ideal documentation should be able to give a bird’s eye view and address the road-level details that developers and quality analysts need.

It seems to me that multiple documents become the best approach to meeting this ideal of providing the bird’s eye view and road level detail. In past work I’ve tended to use site maps or high level flow diagrams to give the high level information then use wireframes or lo-fi prototypes to get into the road level detail. (There is also need for technical documentation of both bird’s eye and road level detail but these tend to fall to the Front End and Back End team leads.)

Concept models

A concept model shows the relationships between the important elements of a web site and provides some initial planning outputs so we can work out what the key elements and key moving pieces are.

The key thing is that it doesn’t box you into a specific approach of how to show the information. You’re not locked into pages or actors. You have the flexibility to represent a specific page or a specific person, but there aren’t rigid rules driving the diagram… the idea is to give the big picture as something to start with. As you move forward documenting it serves as a jumping point to move from into more detailed things like flow diagrams and wireframes.

The concept model paints the relationships between things… it’s a learning tool.

Building this deliverable pushes you to learn about how all the concepts fit together and the resulting deliverable serves as a point of reference for you and teaching tool for communicating the relationships between the concepts to others.

Looking over a current project that’s late in the requirements gathering stages it appears to me that starting from a concept map may have helped to better communicate our understanding of the system with the client and provide easier access to some of the high level information they wanted to share with the higher ups without getting mired in the details.

Flowcharts

While these are possibly the least appreciated documents among designers, flowcharts [or flow diagrams] tend to rate very highly with the stakeholders and team members that consume them. As designers we sometimes see them as unnecessary because we often have the “big picture” that the flowchart communicates in the back of our heads. Other stakeholders don’t tend to have that information at the back of their minds and appreciate the easy communication that flowcharts provide.

This is a wholely unsexy form of documenting, but people understand them and that makes them useful.

Spool cited experiences he’s had with flowcharts and raised the question

How do you determine what level of detail to focus on?

If you get too focused on the details it takes forever, if you go too high the flow isn’t clear.

In my work I tend to put together different flowchart style diagrams for different situations, often a high level flow (more of a site map or application flow diagram) and as needed assembling more specific process flow diagrams that provide more detail.

Brown’s comment on designers neglecting this form of diagramming is well taken, in that when I feel time pressure low level process flows are typically the first thing I drop from my process, occasionally to my regret. Perhaps the clarity of communication that flowcharts provide is part of why we neglect it. We look and say “well, duh” and wonder why we took the time, forgetting the power these diagrams have to quickly communicate the flow to other members of the team and to our customers.

Documents as people

You don’t want to give people too many responsibilities. You shouldn’t assign too many responsibilities to a document either. Like a person they’ve got their limits of what they can deliver.

Establish a purpose for the document. What am I trying to accomplish? What is this document’s role in the design process?

If you have a purpose for the document you can make sure that everything about that document serves the purpose. You can become ruthless in decision making.

I see the ruthless editing this enables as the take-away. Mercilessly slash the cruft that doesn’t serve the doc’s purpose from your deliverables. Is the level of detail I’m using here accomplishing the objective? No? Readjust.

Having a clear purpose can be more difficult the more stakeholders there are working with the document. As different opinions fly about what a document’s purpose is the opportunity to ruthlessly slash closes up.

It’s possible for the responsibilities of a document to change over the life cycle. As you reach different points in the project the purpose of a document may change.

I’ve seen changes over the lifecycle take multiple forms. In some cases I’ve seen document formats change to address a shift in responsibility, such as wiki delivered annotated wireframes getting additional technical annotations from the Front End team. In others the documents themselves have remained unchanged but they’ve been put to different purposes than those they originally served. I’ve seen such changes most frequently in how site maps and high level application flow diagrams have been used by the team and customers over the lifecycle.

User testing your documents

This was an especially interesting question Spool brought up in the interview. We test the software that results from the documents to make sure it meets user needs, are we also testing the documents to make sure they meet user needs?

Brown suggests showing customers past documentation as a sample to get their reaction to it and see if the content and presentation works for them. In a sense it’s like doing a competitive evaluation. Here’s this sample, get reactions to it and adapt.

Iterative process is another option, taking the documentation to the customer, take comments on format and further improve to match customer needs. (This would hold true as well for internal documentation, something we’ve done from time to time with our developers and quality analysts.)

I’ve tended more toward the second option than the first, and done most testing iterations on internal documentation where the cost of entry has typically been very low. Asking questions about document format doesn’t tend to make internal folks nervous where some customers take questions about document format as a sign you’re making things up as you go. I think Brown’s suggestion of how to approach user testing the docs with customers by using old documents does a good job of addressing this potential gotcha.

Books and intervening experience

The interview rounds up with Brown talking about how his thoughts on some of the various deliverables have changed. Some items he considered optional when writing the book are necessary (such as annotations on wireframes) and some things he thought essential he’d now skip over.

As the responsibilities of the various documents he wrote about have shifted, the best practices have shifted as well, making the samples in the book a starting point from which to adapt rather than a template to simply adopt. As always, the designer must take the inputs and decide how to adjust to meet the users’ needs.

I find the rumors circulating about a low-feature iPhone and an Apple netbook interesting in that I don’t understand what drives this speculation. It seems completely inconsistent with the brand experience that Apple maintains through the iPhone and Mac product lines. I also have my doubts as to whether there’s really a market for watered-down versions of Apple’s flagship products.

iPod is the only Apple product line where smaller, less feature rich items have been made available, and portable computers and palmtops/smartphones are not media players. Brand goals and buying habits in those spaces play more to Apple’s traditional brand position.

Apple has positioned itself for years as a maker of premium computing experiences. You pay more than you would for a commodity pc but you get a vertically integrated and carefully controlled experience that (in most cases) “just works.” There are conscious decisions on Apple’s part about how to structure the Mac product line that speak against creating a Mac netbook just to get into another sector of the market. I understand that the netbook market is hot, that doesn’t mean that all computer manufacturers are compelled to join the race.

As the article quotes Steve Jobs: “We don’t know how to build a sub-$500 computer that is not a piece of junk.” A netbook isn’t in the plan because a competitively priced netbook wouldn’t meet Apple’s standards for the end user experience. It wouldn’t perform to the standard, so they won’t do it.

Rather than diluting the brand to enter a market where they’ll be another also ran (albeit likely a strong one) they’ll take a pass. There are other markets they’re entering with varied success from a stronger market position. (AppleTV anyone?) Just because there’s a netbook market to enter doesn’t mean they have to jump in. Apple didn’t release the iPhone or the App store until they meet the standard and they are now reaping the benefits.

As far as a low-feature iPhone… I think the idea comes out of wishful thinking. An iPhone for everyone. Even if Apple took that goal to heart I don’ think a reduced feature handset is the approach they would take. People are buying the current iPhone in huge numbers. The most common reason I’ve heard cited among people that wanted an iPhone didn’t get one is because they’d be saddled with AT&T’s cellular service or the hassle of jailbreaking.

So if Apple decides everyone should have an iPhone I think their strategy would be to open the iPhone to multiple cell carriers. Carriers would then take it upon themselves to price handsets competitively by subsidizing the iPhone price with a new or renewed service plan. This way Apple could continue to draw revenue without creating a new model of handset. They would likely make something close to the current margin (which I doubt would come in on a watered-donw iPhone) and avoid the design and manufacturing costs of a new model of iPhone.

From a brand standpoint they would also maintain the standard of quality they’ve worked so hard to establish for iPhone. (Previous models prepared for release were vetoed by Jobs because they weren’t good enough to go to market.) As the article notes, this would also extend to the experience of software engineers that are such a part of iPhone’s success. “Having different screen sizes, different input methods, and different hardware makes things difficult for developers.“

A watered-down iPhone isn’t an iPhone, and it would be counterproductive for Apple to release such a device. There are already a host of almost-iPhones available from competing cell manufacturers. Just as those looking for an almost-laptop have a host of choices from competing computer manufacturers.