Recent Blog Posts

I am a designer, so like I guess a lot of people become accustomed to their job, I take the role of design for granted. When challenged, it's often a bit hard to figure out what it really means and say that clearly, without self-referential language.

Sometimes it's easy to use analogies, or quotes. Some years ago, as low-end clones took over the laptop market, some tech writer or other said, approximately, "Apple (and to a lesser degree Sony) design laptops, all others just assemble them."

I always liked that one, and even just said it the other day while trying to explain our role in a particularly large and high-speed process. But that is a bit overstated. Probably in ways that aren't helpful. Among other things, I think it leaves out some key job functions between design and assembly.

While there are many, many facets and phases to bringing any particular technical product to market, it might be best to consider three:

Design > Specify > Execute

I think we all know what is involved in specifying. Lists of materials, business rules, functional requirements, pricing models, data structures, storage, network access, and so on.

But already there is a problem. Specifying is not defined by these goals or documents. It can be generally defined as detailing what specific things (behaviors, features, buttons and materials) will go into the product, in what manner, based on known preconditions, and desired end states. Specifying involves finding an acceptable way for a system to work, and documenting it.

Designing also has tasks, and often the exact same tasks as specifying. But when you get to the core definition of how design works, the overriding principle is that design does not assume anything about the pre- and post-conditions of any one feature. Design considers, ... well, actually still the pre- and post-conditions, but those desired for the whole experience, from packaging to product to use, and how those are related to the needs of the expected users.

[Ed. Note] And "design thinking" is the practice of brainstorming many many options for the system, collecting concepts, and assembling the ideas into a small number of concepts to explore. Amusingly, in my design education there were two classes on this, called "ideation", and the rest was the sort of problem solving and communication described here. — Barbara

Design for Marketing, and People

Consider for a minute something that a lot of people tend to confuse with the type of design I do, marketing and segmentation. A lot of folks seem to think that design for products (and usability research even more so) is some sort of glorified version of deciding which market segment to appeal to. But that marketing – without design input at least – simply creates those assumptions, and the result is marketing-driven specifications. "Colorful and fun, for children" or "Language to appeal to the teen market" or "Must meet $129.99 price point" are all things I have seen result from marketing-driven specification.

These may be fine to kick off a project concept and get funding, but they are not design goals because they do not drive the overall approach to the product. As one example, talking in a teen manner – even when executed well, which is difficult and rare – is always a failure if nothing else changes about the product. And I don't mean "cool teen graphics," but the tasks available, the manner in which they are approached, the integration with other products and services which engage the audience already, and really the entire experience. Design (at least design for user experience) focuses on behaviors more than demographics and fads.

Design for Processes

Design is not in opposition to marketing, nor does it supersede marketing. And neither does design override or disagree with the specification people or processes. Instead, it works hand in hand with all of these phases.

Design, at least the way I do it and write about it at great length, supports marketing, by looking at the perceived needs, the competition, and the users, then creating personas, design goals and other deliverables to help everyone understand the true needs and limits of the product.

Design supports specification by, first, the creation of these goals and understandings; the key assumptions about the product become more clear, consistent, unambiguous and defined. But we also typically perform the traditional task of design and draw things. Rough, conceptual things, that can often be turned directly into specifications.

Just the other day yet another analyst came to me, shocked that the annotations to the side of my drawings were in his language. He simply copied many of them into the requirements document. This is not fortuitous or incidental, but entirely intentional; it is what we do to best support the process, and the specification people to get the product built on time.

Design for Execution

To the last phase of the miniature chart we started with, "execute" in traditional models accepts specifications, and builds (whether with CNC mills or code) the product. But even here well-run design processes can add value and reduce troubles.

Execution-phase people – developers, architects, tool and die makers, QA, etc. – are not robots. We're not talking about the assembly line, or the webserver, but about the people who build that. And they are people. And products are complex, so pretty much cannot be specified perfectly (or, alternatively, cannot be held in a human's brain when sufficiently specified). An absolute, rules-based system does not work, and there are gaps, cost over-runs, errors and rework.

If you are lucky. If not, there are missed deadlines and angry customers. Or no customers. Design can hold a role in documentation, even. A simple way is to carry those early goals created with marketing through the rest of the process. But the documents can be designed as well, to appeal to the needs of the execution teams. And to express the broad vision, and core needs of the product as something inherent to the specification and design documentation.

Aside from creating all my own design documents like this, at Little Springs we even get work on projects that are about nothing but re-designing and re-writing complex, reusable specifications documents.

Design and You

While this is what I do, it doesn't mean pretty much everyone can't do it. One of the biggest drivers to being a good designer of technical systems, aside from the usual good-work-ethic stuff, is internalizing the process and having enough knowledge of the domain. I am better at designing mobile interfaces and account management systems, because that is where my design experience lies.

You could get there also and empower your processes with a design mentality, but I do think "Design Thinking" with capital letters, as espoused by management process types, misses the mark rather widely. Not sure where that came from, but as an art school graduate, designer for years and process-oriented guy, it makes not a damned bit of sense to me.

[Ed. Note] I think design thinking is about "getting the right design" and Steven's discussion is about "getting the design right." Both are necessary. — Barbara

Among other things, design does not have to be "designy." It's not clean lines and pretty colors. Good factories have well-designed processes, but (at first glance) looks like pretty much all other factories, and not like utopian Sci-Fi future factories.

Design can be informed by creativity and aesthetic and even opinion, but I believe this is not what it is at its heart. Design is about looking at problems, or the world, Holistically (other keywords, like Systems Thinking also lead useful places). If your project seems bogged down in minutiae, hire a designer who thinks like this, or back up and try looking at the problem anew, without its initial assumptions.

Consider how your product lives in its world, and how it changes the lives of the users, and how it changes their interaction with the world.

For a while there, designers and developers could ignore screen and pixel size, at least for "high end" devices. Let's be honest here, "high end" meant iPhone-like: touch or multi-touch screens, high end Webkit browsers, and 320 x 480 pixels.

That time is now over. To our mind, it really wasn't here in the first place.

Why is the time now over?

1. Android has matured a bit, and manufacturers are putting it on everything. Consider this ARCHOS Internet Tablet (800 x 480 pixels, 4.8 inches), this Vega Picture Frame (1366 x 768 pixels, 15.6 inches), this 7 inch tablet, or the nook's 3.5 inch screen with what looks like a 5:2 aspect ratio
2. Even Palm's WebOS devices will not be consistent, with Pre's pixel dimensions matching the iPhone's, but Pixi's are at 320 x 400 pixels (80 pixels shorter).
3. Normal Android phones, such as the Motorola Droid at 480 x 854 pixels, no longer have a predictable size. Who knows what the next devices screens will be like?
4. The Motorola Droid's pixels, like the ARCHOS pixels, are much smaller than the iPhone's; bitmaps that work well on one may not on the other.

We wrote Photoshop layout is not your friend in March; this new array of high-end devices forces a choice: design for iPhone only, or start designing for multiple screen sizes.

If you're designing Android applications, you have some tools available to you. The Android Developers' Supporting Multiple Screens gives designers and developers a way to deliver the correct layouts and graphics to the correct devices.

For now, however, Android doesn't really support the full array of screens upon which Android is found. Here is what the document's Range of Screens Supported section says about device support:

The Droid is there, as a high-density, normal screen. The iPhone (were it an Android) and early Android phones are medium-density normal screens. The ARCHOS is a medium-density large screen. The nook and the Vega are ... not in the table at all.

Android's support of screen issues is incomplete, but many steps better than previous cross-device platforms like browsers and Java ME. Despite this, many developers have simply ignored the possibility of different screen types. My favorite example is the Fuzzy Clock widget, which is supposed to take up 25% of the screen with a single line of text. Apparently they used a single-sized bitmap font because on the Droid, the "glanceable" clock has the equivalent of about 8 point font. Not at all readable.

And frankly, I don't expect Apple to keep to the current screen dimensions. I don't have any inside information, but they will make a smaller screen or a bigger screen, or a higher-density screen, or probably all three. So even those of you focusing just on the iPhone may want to look at your process in the next few months.

The hardest type of applications to design for multiple screen types are games, as many create mazes, game boards, and levels for a specific aspect ratio. If your application uses scrolling or other pagination techniques, however, you can probably design it to comfortably manage a wide variety of screen sizes. (But all bets are off for supporting the Nook's screen, which will really want to scroll laterally, not vertically). How? Go read the resources linked above in this article. Or hire us.

My father is a geek like me, though has been budget-conscious for my whole life. A few months ago, he started asking me a wide variety of questions of different types of devices he could use to fill his various needs, including bicycling and genealogical research in an area with highly spotty coverage. Numerous email exchanges later, we both decided on getting a Motorola Droid. He sent over this commentary on how it works for bicycling, partially to help another person in his device decision. I find the analysis fascinating. I hope you do, too.

I’ve experimented with using the various GPS Receiver functions of my new Motorola Droid toy. In short the Droid functions about as well as my Garmin eTrex in determining location but the Droid has limited navigation functionality when it is outside 3G coverage. Additionally the battery drain rate is high.

It appears that the Droid uses GPS satellites to determine its location for navigation type functions although it uses cell tower and WiFi data in conjunction with some apps.

Satellite acquisition and initial location determination

When I first turn on my Garmin it takes a couple of minutes to acquire satellites and calculate the current location. The unit “knows” where it was when it was turned off and has a catalog of satellites that it should see but it takes time to acquire those satellites and gather enough information to calculate location.

At home when I turn on Google Maps on the Droid it first shows a location based on cell tower data (I’m away from any known WiFi hotspots). It then quickly (less than 30 sec) zeros in on my house location. The impression is that the Maps App is much quicker in getting to the initial location than the eTrex. Ed. note: This is most likely due to the cell tower assistance.

I turned on the satellite view mode on Google Maps which shows aerial photography of my area. The blue dot showing my calculated location indicated that I was in the guest/sewing room rather than at my computer in the living room.

Tracking a bicycle ride

One of the apps tracks your movements. I assume that this uses GPS data and is not dependent on being connected to the network. I used this on a short ride that I believe includes areas that are out of coverage. I had the Droid in a handlebar bag and the Garmin mounted on the handlebar. On a 20 mile ride both units calculated the same moving time, distance and differed slightly on the altitude and total climb calculations.

I put the calculated tracks into Google Earth so that I could compare them side by side. Both tracks had errors. When compared to the rectified aerial photo I was all over the road and off the road for much of my ride. The Garmin seems to do a little better but that might be because it is set in a mode to attempt to follow the road. The errors were worse when I was in the trees. During one part of the ride the Droid seemed to have a consistent bias to the north of the road.

If I really cared about the accuracy I’d do some more tests with the Garmin set to ignore map information.

Navigating

I turned the navigation mode on for a 70 mile car trip home yesterday. The trip included a significant amount of time out of 3G coverage. I didn’t observe the navigation continuously but checked a couple of times when we were out of coverage. The screen was white, showed no map data, and showed that the app was doing a rerouting.

So as I expected you can only navigate when you are in range of the towers.

When it is navigating the default is to have the screen backlight on continuously. The Droid actually feels warm after awhile.

Also yesterday I unplugged the Droid around 6:30 AM. We did a round trip through low and no signal areas, I made a couple of phone calls, I also connected to a WiFi network and viewed various web sites, for about 2 1/2 hours I had the navigation mode in use. The GPS and WiFi receivers were on for the whole day. When I got home around 6:30 PM the phone was begging for a recharge.

Conclusion

No surprises. With the current apps the Droid will not replace my stand-alone GPSR. If they offer a capability to store map data and calculate routes on the device then maybe it could replace it. Since my intended uses include camping based bicycling trips I have recharging issues that would limit how I would use the Droid. For a trip that doesn’t include back country and has regular access to a USB power source it would probably be OK.

I am going to explore various off the grid recharging options such as solar cells and a new generator that runs off of body motion.

If you haven’t, go check out part 1 of this series, in which I argue about the increasing role of feature phones in mobile web, and possibly apps.

I think a major shift in how we pay for mobile data is coming, within a year or two. And content companies need to figure out how to conserve bits. They aren’t free.

The role of data plans

Let’s take a look at unlimited data plans for a moment. Unlimited data plans are great! They provide enormous freedom! No worrying about how much data you use! Terrific!

And it is terrific. It’s great for people who can afford to spend $70 per month for each phone in their family. That’s not terrific for everybody. And it leaves people like my father, who want smart phones and that freedom but aren’t planning on watching video or tethering, paying for heavy users.

Variable pricing is inevitable

Unlimited data plans not only reduce access to a larger number of people, they also cause congestion problems. There is no cost to using the network, and there is cost to not using the network. It’s annoying on many devices to switch to wi-fi; it’s inconvenient to change your email or web habits.

As the operators increase available bandwidth, demands will go up. Video streaming, data cards, and tethering become more popular. People enter the world of mobile data from no experience to 3G cards, possibly with the intent to replace their home connection.

As the experience degrades (think AT&T access in places like New York and San Francisco), the operators’ brands take a major hit. Vehicle traffic planners have known this for years: roads fill to capacity. The existence of the larger roads change drivers’ behavior, even to purchasing houses further from town.

Some sort of change in pricing model is inevitable. Mark Lowenstein over at FierceWireless provides a few options. You can read a deeper discussion on the problem, and the solution, over at Slate.com.

And yes, Verizon already has a tiered data plan.

Global concern

I’ve just set out the argument for why the U.S. will not have universal unlimited data. That was the tough part of the argument; the economics for unlimited data are better here than in many places. In much of the world, pre-paid plans with pay-per-kilobyte are the norm. And this includes hundreds of millions of users (over 300 million in India alone) who do not have computer access to the Internet.

Increasing role of smart phones

As we discussed last time, feature phones are becoming more capable. Further, they have cheaper data connections than do smart phones, because on average they are used less. (There’s that tiered pricing again).

On top of this, smart phones are being pushed deeper and deeper into the feature phone market. Nokia has done this for years, and customers do not even realize they own a smart phone. Blackberries and Windows Mobile devices are being used as feature phones. Android phones “for the masses” are being deployed.

As smart phones get pushed deeper into the market, they will be selected by prepaid users more and more. Many of these users will still be paying per kilobyte.

Design implications

Right now, the bulk of the mobile web industry is moving to rich web interactions. But at what cost?

In a world of pay-per-kilobyte, is that 12kb JQTouch framework worth it? Sometimes, yes. But frequently, no.