I recently designed a few Icons in omniGraffle for wireframing, and threw them into a stencil (below) so that you all can reuse them if you’d like. I’ll be expanding this into a more complete library over time, but right now there are a few renditions of a gear icon I was developing. These are all vectors so they’ll scale nicely. Feel free to reuse / distribute!
As I’ve previously noted state diagrams are an essential UX artifact, as a way to evaluate the completeness of assumptions around scope, and as a way to properly establish the limits within which to design. Too many product designers skimp on this, diving into representations and design sketches based upon prior experience and intuition.
You’ll never hear me diss the vital importance of intuition in design, but if you’re a designer you should know that shortcuts send ripples through the design process that can ultimately disfigure your product. If you’re skipping your state diagrams, it’s time to stop. Why? Because you probably haven’t woken up to this fact: in interaction design, you aren’t designing a site.
Let me use the physical world to explain. Consider traditional architecture. Lets say you’re designing a building – even a 1st yr architecture student will tell you how important it is to consider the site where your building will be located. It influences a buildings form, positioning, materials, and construction, zoning limitations. Architects don’t build sites. They react to and built within them. As do interaction designers.
In interaction design, you aren’t designing a site. You are designing an experience within a complex virtual workflow that is your site. But how do you represent your site? Diagram it. The experiences and touchpoints that you’ll diagram are a representation of that site – and they will inform the limits of the user experience you ultimately design. In essence: the UIs you generate do not create a site, they are your intervention into a site that already exists. The state diagram applied to UX is a versatile representation for articulating flows, modalities, alternative paths, as well as significant and natural transitions within that site.
To help you get started, I’ve posted an Omnigraffle stencil and template for UX State Diagrams
This is an OmniGraffle Template and Stencil for drafting basic State Diagrams for interaction design and touchpoints for user experience as a part of experience design. It’s based upon a drafting style that I’ve been evolving, give it a try and let me know how it works for you. Would love to hear your feedback from using it; and I’ll post versioned updates as the system matures.
State Diagram Template & Stencil bundle for OmniGraffle:
Click here to download
While I was at MIT, I developed a Shape Grammar that describes Louis Sullivan’s system of ornamentation. Using the Grammar as a tool, it is possible to calculate (generate) each of Sullivan’s designs, as well as to generate entirely new designs following his system.
Enjoy ~ and let me know what you think!
How is the experience design of your smartphone optimized? It’s interesting to note that the ultra-simple design of iOS UI ironically makes it less efficient to use, in performing a growing number of tasks that I want to use my Smartphone to accomplish. Really, iOS is just as easy to figure out – if not easier – than Android-based UIs, but it’s a less efficient model for the tasks that it’s not optimized for. Behind its famous simplicity is a very narrow design optimization around specific use cases. Now, this is all just my impression based upon my own frequent use of both an iPhone and an Android device, but it seems that iOS is optimized for texting, calling, contacts management, and browsing. Essentially, the basics: the first generation, core set of functions. The entire experience of extensibility in use of the device, in the form of apps, both built in, and third party developed, has been based upon the same paging icon grid (with groups and a multitasking strip added on), and the same abstract notification layer. In short, the UI grants the same point of entry for each and every function.
In comparison, the Android experience has flexibility that enables optimization for a number of other emergent and growing use cases and entry points. The icon grid and paging concepts were implemented but disentangled, and pages were expanded to display widgets that both deliver and capture information. And it makes a big difference. Not so much for those “basic” functions I noted, where my interaction model is pretty much the same. But what if I want to check the weather? If I want to check the weather on my iPhone, I swipe to the correct page, I scan for and tap the icon, and it loads the app in its last state. To accomplish the same on my droid, I hit home and swipe to what I call my “location” page – with navigator, maps, places, and a weather widget that proactively shows me all the information I need. Then, I’m done. Less time in the device, more time on the go. Twitter is the same way – in the droid I have a “social” page with a collection of my top SNS widgets, they both pull the latest updates and allow me to quickly enter updates.
Add to that a more robust and proactive notification layer to account for incoming streams I may want to react to. In many cases, I’m finding I can accomplish the same things while actually spending less time in the device, and less time tap-tap-tapping.
The debate is endless and iOS purists will disagree with all of the above, but it’s a compelling question to explore: which UI framework will scale better with evolving usage patterns?
In the wake of more ubiquitous application multitasking on leading mobile platforms, it’s worth remembering that for many use cases, there’s a more important and pervasive need for multitasking, involving the engagement of a mobile application experience into the user’s life experience. It’s obvious that Mobile is so disruptive because people can easily interface with it while on the go and while doing other things. Users interface with their mobile applications and either augment or overload their experiences while walking, driving, eating, talking, shopping, etc. Many applications are built with functionality that intrinsically supports this type of multitasking, like FourSquare (LBS) or maps (navigation) or music players. Social perspective on this aside, how do you work within mobile frameworks to design for this, in a general sense?
Support quick processing and quick recall. As users are switching back and forth from your application to whatever they are doing in real life, it is important to help them get grounded quickly in your interface. One important enabler for this to keep your input controls in consistent locations, often clustered around “hot spots” that the user can reflexively access. As they interface with your application over time, they are able to more readily interface with the controls not only because they don’t have to hunt for them but because you’ve trained them how control the experience. In addition to this, creating a clear visual signature for the data and content elements of your application is increasingly important. For whatever content the user is consuming, you can assume you’re not going to have their undivided attention at all times. Clearly legible content is even more important in this case.
Develop simple gestures. Ease of use takes on new meaning within the context of mobile applications. Users might be interfacing with your application while driving (even though they shouldn’t be) or while not even looking. There are a few design qualities that enable this. One to incorporate simple, repeatable gestures. Multi-step application usage through multiple states or contexts should involve similar gestures or movements to help users easily control the application without thinking about it. In addition to that, in terms of touchscreen inputs, making your buttons and components large enough to easily interact with is critical. This is obviously a natural part of the design of the hardware inputs on the device; however, it’s just as important in your UI. Finally, design your applications so that they can be used with one hand, if you want people to be able to use them while doing other things.
Responsive, but controlled. One thing that drives me crazy as a user of my mobile is when I’m txting as I walk – which I do a lot – and the screen rotates from portrait to landscape as a result of the movement of my arm. This is a good example of the application being too sensitive, too responsive, for a particular set of use cases. In consideration of that, it makes sense to give thought to the amount of “listening” your application ought to be doing while users have it open: all of their gestures or movements might not actually be interactions. Pause controls can be an effective mechanism for letting users manage this themselves, particularly if you have several different use cases and levels of interaction.
For complex applications, flow diagrams are critical design artifacts. They establish the appropriate system limits within which you should be designing. Not using them means you’re compensating with other, less suitable artifacts, or you’re avoiding the problem they solve altogether, which means your product or service is going to run into potentially serious challenges in scope and functionality as it moves through the analysis and development phases of it’s lifecycle – Agile or not. Far too often, that’s exactly what happens.
Occasionally, we come across UIs that create what I call the Ping-Pong Effect: where the user’s attention must bounce back and forth between two UI components, and in fact two separate task flows, in order to use the application’s primary workflows, as designed. The problem typically emerges when each task flow is given equal prioritization, forcing the UI to balance two things. You might be thinking, “why would anyone do that?” – and yes, agreed, but it is more common than you might first think. HUD UI components in immersive video games are a very common example. Another example that I had some experience with was a workflow that supported the collection of data, while simultaneously allowing users to explore the data being collected. Sounds simple right? According to the original specifications, it was not desirable to force users to have to fill in all of their data prior to showing them any of the exploration, because the exploration itself was intended to drive engagement and establish the value of the tool.
The devised solution broke the data and the exploration into several sections and then captured the data for each section prior to displaying the aggregate data from others. The data display and the inputs occupied different parts of the screen, so as users move through the tool, they have to constantly switch between data entry and exploration. Predictably, the tool’s performance suffered a bit, exacerbated by the fact that most users will naturally be more interested in a subset of the sections. The solution to this problem is of course to disentangle data entry into a separate, optional flow. Some users will never go into that flow, but we knew from previous analytics that those that do would likely complete the whole form, covering all sections. In addition to that, more contextual data capture could be integrated into the exploratory flows as well, to gain data on a piecemeal basis.
Every strategist will inevitably make products that love themselves. These are products that are designed to address a real need or frustration, but subsequently get totally carried away with the solving of the problem. In a sometimes staggering display of complexity, duplicity, and abstraction – they fail to perform, ironically, because they are doing too much. The trick is to get to know the warning signs and put the right composition of checks and balances in place to make sure the product has a healthy perspective on things.
What does it mean to say that a product is self-obsessed? Let’s break it down to a few points:
When you’re doing acceptance testing and analysis of a product concept – always make sure you’re asking the right set of questions, or creating the right evaluative scenarios. Don’t just measure your user’s ability to understand the functionality of the product and the value that functionality creates. You also have to measure if they like the way the solution is articulated in a broad sense. This often comes down to the nature of the more repetitive tasks that the product creates for them.
Of course, there are a hundred shades of gray to this line of thinking, but it’s the way of thinking that is important.
Before I go, let’s dig up a well-loved example:
Microsoft’s Office Assistant. Remember Clippy? He was here to help. Really.
The 2010-2011 MIT IDEAS Competition kicked off this past Wednesday with the traditional generator dinner, during which students get together and form teams to solve some of the world’s toughest problems. For the second year, I’m coordinating Monster’s support of the competition, in an effort to bring innovation to the problems in job search and career services. My focus this year is on migrant workers; here’s the pitch I gave:
We want to support technology that empowers migrant workers to find work as well as necessary resources. So, there are a number of areas where we’d like to talk about innovation: finding work being the obvious, but also, for example, helping migrant workers to find shelter, health care, or dealing with language barriers, or understanding the risks associated with certain types of jobs, locations, or even employers. Creating better recognition and attribution of the skills they may possess to increase the number of opportunities they have access to, or providing better representation both locally and globally to migrant communities.
And consider their plights worldwide. Compare for example, the situation domestically in the US with the migrant workforces in urban China, or domestic workers who migrate to the Middle East.
There are many unique challenges that each of these groups face. Our hope is to create a more ubiquitous support framework to improve life for a worldwide population of migrant workers; a population so large that in 2009 alone the World Bank estimates they generated $420 billion USD in remittances, of which $317 billion went to developing nations.
