The IA Summit (and information architecture) enters adolescence

The first IA Summit was held April 8-9, 2000, in Boston, MA, and was titled Defining Information Architecture. Now, fast forward to this year’s 13^th IA Summit held April 3-7 in Baltimore, MD, in which the Summit entered the awkward teen years against the slogan “Observe Build Share Repeat.”

Taking the slogan to heart, a number of Summit workshops, sessions, keynotes, and discussions focused on reframing information architecture as a practice and as a field. Granted, IA is closer to 40 in chronological age (many date back to Richard Saul Wurman’s 1976 declaration “I am an Information Architect,” though personally I subscribe to Andrea Resmini’s Brief History timeline), but it is also experiencing adolescence thanks to a rapidly transforming digital landscape that makes puberty seem pretty innocuous. Consider, for example, the proliferation of:

• Big data and open machine readable datasets (e.g. DATA.gov, and AWS Public Data Sets)
• Content syndication, especially approaches like COPE (Create Once Publish Everywhere)
  • Plus increased use (and occasionally understanding) of taxonomies and metadata
• Free and open-source:
  • Blogging and content management systems like WordPress
  • Content management frameworks like Drupal
  • Design tools like Twitter Bootstrap and hosting services like GitHub
• HTML 5 and CSS3 with their improved capabilities especially around design and media
• Mobile devices and technologies
• Responsive web design in its various approaches and permutations

Like a teen whose body is changing faster than it realizes, so too is information architecture stretching and growing and developing. But information architects (at least most of them) have gone through puberty and should be able to adapt their practice and usher their field through this tectonic change.

Remaking information architecture

Coming of age is always difficult. It requires patience and introspection. It is uncomfortable, unpleasant, awkward, and is in many ways unending. But, it offers a unique opportunity to remake and improve information architecture in the face of change and to prepare for the next tools, technologies, and even modalities altering both the digital and physical landscapes.

This means making hard choices and invariably suffering missteps and setbacks. But when the IA community comes through it, it’ll be older and wiser with a better understanding and control of its body (the practice and field of information architecture). Then IA can start realizing the unmet potential of its youth. So what is the path ahead?

Define information architecture not as a concept, but as a practice and a field

For me, the highlight of the 2013 IA Summit occurred before the opening keynote. It was the pre-conference workshop, Academics and Practitioners Round Table: Reframing Information Architecture, moderated by current Information Architecture Institute president Andrea Resmini. The all-day session consisted of 30+ information architects working to identify the requirements that would lay the foundation for a common language, grammar, and poetics for IA.

While the proceedings of the workshop will be published in the Journal of Information Architecture, the real work will begin when the larger community comes together to define and formalize itself. This necessarily includes:

• Defining what is and is not information architecture
• Identifying and documenting the major IA schools of thought
• Mapping out and understanding how IA relates to sibling (such as usability, information design), parent (such as architecture, library science) and extended-family (such as psychology, linguistics) fields
• Agreeing on a basic timeline for information architecture’s intellectual history, including formative events that pre-date the emergence of the field as well as key technological and cultural events that shaped it
• Codifying information architecture best practices and developing standards around key artifacts
• Formalizing the requisite background, training, skills, and certifications for practitioners and then defining the various roles within IA, noting which overlap with other fields and how

Here it should be noted that individual IA practitioners, organizations, and programs have made strides in addressing the above. But until there is a confluence from across the information architecture community, these will be little more than outposts in the wild and may even promote schisms within the community.

Accepting some basic truths about the practice of information architecture

The larger discussion around remaking information architecture also includes coming to consensus around some important concepts that every information architect needs to understand. These are discussed in my April 17, 2013, Aquilent (my employer) blog post 2013 IA Summit Themes but are summarized here:

• You cannot control device usage. Device usage will change and evolve faster than we can keep up, and it is a fool’s errand trying to predict or determine how users access content.
• You cannot control content. Syndication and content reuse ensure that content takes on a life of its own, so it’s essential to understand and leverage taxonomy and metadata.
• You cannot control meaning. It is not inherent or discrete and can’t be turned on and off; information architects can only share meaning and should consider a meaning-first approach.
• To serve the users you must serve the content. Understand and leverage syndication, promote content longevity and usefulness, and consider targeted, accidental, and future audiences.
• Sometimes you’re the architect, but often you’re the builder. We cannot always do dramatic and innovative work, but remember, the best information architecture is invisible.

There are, of course, many other concepts that are essential to the practice and field of information architecture will be identified and defined as its adolescence continues.

The time is now…

With the IA Summit turning 13 and information architecture in a time of adolescent turmoil and transformation, it seems clear that the timing is right to define and formalize both the practice and field of information architecture.

Heading into the 2014 IA Summit, members of the community need to open their minds and roll up their sleeves for the difficult, awkward, and emotional work ahead. And they should do so knowing that once information architecture enters its adulthood, it will open up new world of influence and opportunity.

Put another way – and paraphrasing B&A founder Christina Wodtke – be bold, take risks, and fail spectacularly. Now is the time to clearly define and state the communities’ vision for information architecture then set out to realize it.

Wait, I thought, I have both my iPad and my laptop in my backpack.

I felt ridiculously conspicuous pulling out either just to check Google Maps. Between the two, I chose the iPad. It’s smaller and it has 3G. However, I felt as if all my fellow passengers were reading my giant screen along with me.  There’s a reason, I realized, that I’ve been observing commuters on their phones or slightly larger Kindles, but seldom whipping out their iPads on trains, bus stops, or speed walking through the city.

The iPad hit the market about three years ago, quickly becoming disruptive by creating a user need where there previously was none. 22% of U.S. adults now own a tablet. Given that it looks and acts like a larger smartphone (minus the obvious calling feature) and that there are apps, it’s easy to classify it as a mobile device. And that’s probably true – the iPad is more mobile than, say, your laptop.

However, as an app developer or a brand that wants its presence on the device, the larger question remains. Do you design for users on the go? Or do you focus on a more in-depth user experience? What is your content strategy? After three years of usage, we have data and opinions to support multiple points of view.

Mark Zuckerburg famously stated that the iPad isn’t mobile (Parr, 2010). Jakob Nielson’s report suggests that iPad users don’t use their iPads in truly mobile situations, and those that do take their iPads away from home tend to use them in more relaxed situations (Nielsen, Budiu, 11).

Where does that leave your feature offering and user flow?

I design mobile apps for Cars.com. After several years, countless usability sessions, and app design for three platforms (Android, iPhone, and iPad), our design team came to the realization that we should not necessarily think of it as design for mobile, but as design for tablet, or even more broadly: design for touch.  And when it comes to interaction, this is certainly true. The iPad shares the same interaction model as other touch devices. Our content strategy, however, has had to shift after trial and error.

Our apps are built primarily around the assumption that users are searching for cars. On top of that, since they’re doing so on a mobile device, they’re also interested in contextual tasks, which include finding dealers who stock those cars, contacting those dealers, and test-driving the cars. This basic flow was positively reviewed in the app marketplace for both the iPhone and Android apps. Thus, when the iPad app was developed, we had employed the same content strategy. We also focused a large effort on creating an in-app map feature, assuming users would be using it on the go.

After conducting user testing, I realized the following:

• About 20% of our users have WiFi iPads instead of 3G. This meant that all the contextual features we were considering, such as on-the-dealer-lot and on-the-go usage would be available only to those who either have a 3G iPad or access to a free WiFi.

• iPads were generally a shared device. Spouses and families typically had one per household, and therefore no one person carried it with him or her at all times.

• The largest iPad use case was on the couch, in front of the TV. In this case, iPads replaced laptops for consumption of information, such as browsing the web, or more cognition-heavy tasks such as researching a product. This is different than a laptop, which is still turned to for creating, or a smartphone, which is used for contextual and hyper-local information, such as finding the closest dealership or grocery store. This is also the reason why Josh Clark recommended considering the “belly zone” when designing the navigation for your app and avoiding putting controls on the bottom (Wroblewski, “Design for Mobile: iPad Design Tips”).

Given all the arguments against the iPad being mobile, where does this leave content strategy? All evidence points to the fact that you should design for touch but consider content differently. Think of it as a touch device that is used in one place. As you plan your content strategy for an iPad app, consider the following.

Focus On What You Do Best

It’s tempting to cram in many bells and whistles into this highly visual device. After all, the graphics are at the foreground and Apple’s design guidelines extensively instruct us to let the user interact with the content, not the chrome. The content, however, should be what your brand does best. Focus on your core user path and keep the flow simple and fairly linear, at least in the beginning.

For example, our initial app at Cars.com primarily allowed users to research new cars. We designed for large graphics and minimal content, thinking that we were meeting iPad users’ expectations. Our users, however, expected to find listings of cars, not just research, because that’s what our brand is known for. Their expectations didn’t change simply because they were using an iPad. We re-focused on search, which is what we do best, and our ratings improved greatly.

As you consider content, pare down features that are essential to your brand and develop one solid user flow. Often, your core user flow is an obvious one. We leveraged analytics to understand how consumers used our regular site on their iPads prior to making changes to the actual iPad app. After all, a significant portion of traffic to our site comes from iPad devices. This provided insight on what specific features from the site can be customized in the native app for a better experience.

Consider The Funnel & The Couch User

If you have a cross-channel brand, consider the consumer journey through your brand. For example, for us at Cars.com we’re always thinking about the consumer’s shopping funnel. When people first begin their search for a new car, they may perform high-level searches, research, and comparisons. As they get lower in the funnel and near their car purchase date, users turn to their smartphones for activities such as locating and contacting dealerships.

Since we’ve established that people use their iPads on the couch, we now aim to design primarily for the couch user. Our iPad tasks focus more on the initial search, with research features folded into the main flow, and we spend less time worrying about location-based services. Our secondary and tertiary flows, however, include map features and geo-location because it is still, after all, an iPad.

Sync Across All Channels

50% of U.S adults now own either a tablet or a smartphone, and many own more than one. This has major implications on how and when users consume information across the same brand. For e-commerce, for example, one-quarter of visits to e-commerce sites occur from mobile devices, however all but 15% return back to their laptops to purchase. For us in the automotive industry, 79% of new vehicle buyers use the Internet to research their vehicle purchase. While virtually all of them use a desktop/laptop at some point, nearly 30% use multiple devices.

That means, depending of where they are in the shopping process, users can ostensibly be searching for cars on their laptops at work, checking listings on the iPhone during the commute, and comparing cars in front of the TV on their iPads at night. This doesn’t mean that we should necessarily replicate all tasks and flows equally across all devices. It does, however, mean that the user experience should be seamless.

Figure out what your users are doing on each device and provide syncing capabilities across channels. On Etsy, for example, where 25 percent of the visits but 20 percent of the sales come from mobile devices, the site syncs items in the shopping cart, favorite items, purchasing history, and conversations with sellers.

For Cars.com, this means that when users save their favorite listings or dealers, they are expecting to see the same saved items whether they are on their Android phone, laptop, or iPad. It’s perfectly fine if the iPad is only used on the couch, as long as when the user is ready to head to the dealership with their smartphone in their pocket, the same information they had saved on their iPad the weekend prior is available at their fingertips. If there is any difference in the information they see, it should be contextual to the user’s mobile needs and mental model.

With smartphones, that means taking into account location and urgency. For example, seeing a dealership nearby on a smartphone can include such data points as sales and service hours, and whether they are open now. In another instance, availability of listings can show in order of proximity to the user’s current location.

What About Other Tablets?

The iPad may have started the trend, but other tablets are certainly catching up. Now, just over half of tablet owners report owning an iPad. Nearly half own an Android-based device. The Windows 8 tablet has recently entered the market, and so has the iPad mini. What are the implications of these newcomers?

In addition to whether a device has cellular service, price and physical size ultimately factor into the users’ decision to take a device on the go. From my experience with the Surface Windows 8 tablet, its physical size alone may preclude it from becoming a mobile device as well. In addition, Windows is advertising a physical keyboard attachment. While this may be convenient, the keyboard definitely places the tablet closer to the laptop realm and may not necessarily be very portable. It weighs in at two pounds, according to Microsoft’s website, which is heavier than the iPad. The tablet is also expensive and is only WiFi for now.

The iPad mini, however, is smaller, lighter, and has a cellular data plan option. Like smaller Android tablets, it’s relatively less expensive, which makes users more inclined to bring it along when they’re on the go. This could mean, however, that your apps on these smaller tablets resemble more of the smartphone app experience rather than the larger tablets, at least in terms of the tasks users conduct.

Iterate Often

Whichever features you decide to release, the app marketplace is dynamic and provides a direct pipeline into user feedback by way of ratings and reviews. With the pressure to keep the app fresh in the marketplace, it’s tempting to add more features.

For example, GateGuru from Kayak initially delivered its promise to show airport information and flight status. However, more and more features were added to the point that users are now questioning whether it’s even the same app.

As mentioned above, we experienced something similar with our Cars.com iPad app. The first release of our app did not meet users’ expectations because it didn’t deliver what our brand promises: the ability to locate car listings. The app ratings and reviews certainly reflected that, and we worked quickly to ameliorate our standing with the app marketplace to add listings in the next iteration.

Conclusion

Listen to your users and always check whether the new features are desirable. As you first release an app, start with your core competency and consider the features that are essential to your primary user path. As you iterate and add more features from your business and product road map, take into account what users are saying. You may find yourself adding or sunsetting features based on how and where people are using your app. Mobile or not, the tablet market is here to stay and, directly or indirectly, users will tell us what features to build next.

Suggested Reading

• The Explosion of Mobile Audiences: A growing mobile landscape
• Wroblewski, Luke “Design for Mobile: iPad Design Tips” 2010: Notes from a Josh Clark presentation
• Retailers Try to Adapt to Device-Hopping Shoppers: Google, eBags, eBay, and Mod Cloth struggle with device synching
• Parr, Ben. “Mark Zuckerberg: The iPad Isn’t Mobile” Mashable.com: Next Question
• Nielsen, Jakob and Budiu Raluca. “iPad App and Website Usability” 2011: Results from a study
• 2012 New Autoshopper Study: Tablets and Smartphones Are Used by One in Five Digital Auto Buyers
• Mobile Marketing Trends, Insights and Best Practices: Slides from eMarketer Webinar

Down at the bottom of the screen was a little window where you could type simple English-like commands – things like go to card 2 or beep. Once you’d mastered those, you could add them to your buttons or trigger them at certain times, creating real interactivity. Pretty soon I was making little games and utilities. It was the coolest thing ever.

HyperCard’s Home Stack: Pure Nostalgia

HyperCard came with something called the home stack that opened when you first launched it. I looked at it and thought, This isn’t very useful. It shows up all the time but it doesn’t do much. So I made a better one. It included various utilities, and of course a rock-paper-scissors game. I made packaging and convinced the local Mac store to sell it for $7.

It sold two copies.

Since then I’ve worked on products with more than twice as many users, but the story remains the same. This isn’t very useful. This doesn’t serve people’s needs. Let’s make a better one.

In college I discovered a career for what I did: user interface design. And though the title has changed over the years – user experience designer, interaction designer, product manager, product designer, founder – the motivation hasn’t. Technology is confusing and doesn’t meet people’s needs. I want to fix that.

Eat Your Vegetables

These days, it’s fashionable to talk about audacious ideas. Paradoxically, it’s also popular to focus on ideas that can be built in a month.

In a post last year, Paul Graham listed Frighteningly Ambitious Startup Ideas and spawned a bumper crop of companies (though my favorites, Bring Back Moore’s Law and The Next Steve Jobs, don’t seem to have much traction). Wired’s cover story for February was 7 Massive Ideas That Can Change the World.

But I can’t help thinking we’ve skipped our vegetables and gone straight to dessert. We are insinuating ourselves into more and more of people’s lives, yet we haven’t managed to meet their needs in predictable, understandable, let alone enjoyable ways.

I watch people using their devices and I cringe. They get their single-click and double-click mixed up. They open an email attachment, update it, and then can’t understand why their changes aren’t in Documents. They try to set up iCloud and end up creating three Apple IDs. They miss out on all the useful things technology can do for them, lost in a sea of complexity, confusion, and techie-centric functionality. These things were supposed to be labor-saving devices, right?

Make no mistake: This is our fault. To begin with, we’ve created ever-more-inconsistent expectations over time. Consider single- vs. double-click. Easy, right? You single-click to select, double-click to open. Unless it’s a webpage. Or Apple’s column view, where selecting and opening are the same thing so it doesn’t matter. Well, for folders; for documents, it matters.

Anyway, it’s really easy to tell if you’re in a webpage or not so you know which convention to use. Just look at the top of the screen, on the left. It should say Firefox, or Safari, or Chrome. Oh wait, you’re on Windows. Look at the top of the window. No, the frontmost window. See, it has a bigger shadow than the others. Oh wait, you’re on Windows 8? Well, are you in Metro or not? Oh wait, they don’t call it Metro anymore. I forget what they call it. Do you see a lot of colorful flat boxes? What were you trying to do again? Hey, where are you going?

You may think I’m overcomplicating things for effect. I’m not. It seems simple to you because all that stuff is already in your head. When you switch from GMail in a browser, to Outlook on Windows, to Mail.app on Mac, you know which conventions change. You have what designers call a mental model, rooted in years of experience and history, that allows you to make the right call. Most people don’t – nor should we have to.

And these interaction details are the tip of the iceberg. We do a disappointing job of understanding what people outside our bubble are trying to accomplish. Let’s be honest: We mostly make products for ourselves. Later, when they’re successful, we start wondering how people use them. We do user studies and surveys and ethnographies and then ignore the results because it’d be expensive to fix and besides, they’ll figure it out, right? I mean, we did. We lack the comprehensive understanding we’d need to make real, substantive change, to make products that are both usable and useful.

Downward Arrow

Therapists sometimes use the downward arrow technique with their clients. It starts with the apparent problem and proceeds through a series of “why” questions to the underlying issue:

Client: “I get nervous speaking in class.”

Therapist: “Why do you get so nervous?”

Client: “I’m worried that I might say something stupid.”

Therapist: “And if you did?”

Client: “I would be so embarrassed!”

Therapist: “Why? What would be so bad about it?”

Client: “It would mean I’m not good enough.”

And so forth.

Product design requires a similar process: start with a design or feature question and dig down until you find the assumptions that underlie it:

Me: Why do you ask for a user’s password every time he downloads a free app?

Imaginary Apple Guy: For security.

Me: What do you mean by security?

IAG: Well, if someone gets hold of your phone, they’d be able to install apps without your permission.

Me: And what would be so bad about that?

IAG: The apps could do malicious things with your phone.

Me: But doesn’t Apple sandbox apps and review them for malicious behavior?

IAG: Sure, but a maliciously-installed app could connect to your Facebook account.

Me: And is the risk of that happening when your phone is stolen worth requiring a password for every install?

Note that the point isn’t to make me look smart, or simply to reveal flaws. By the end of that (fictitious) exchange, we’ve gone from an ill-defined concept (“security”) to a specific question that deals in user needs.

The Product Mantra

To answer such questions we need the fundamental, defining goals of our product. Who is it for? What purpose does it serve? It’s impossible to evaluate trade-offs otherwise.

When I was at AOL our illustrious head of Consumer Experience, Matte Scheinker, introduced the notion of a product mantra: a clear, concise description of your product. Critically, it must be specific enough to disagree with.

Using my own to-do app, Stky, as an example:

• 

  Stky

  Mantra A: Stky is a to-do app for naturally disorganized people. It keeps overload in check by having you reprioritize each day’s tasks anew.

• Mantra B: Stky is a productivity app anyone can use. Unlike its competitors it keeps you in control of your tasks and on top of your life.

Both mantras are accurate. But only Mantra A is specific enough to disagree with. Do disorganized people need a to-do app? Is daily reprioritization too much work, especially for such people?

Mantra B could describe nearly anything.

Now, suppose I’m deciding whether to add a new feature to Stky: multiple sticky notes. You could have your Work sticky, your Home sticky, maybe a Stuff to Read sticky, and the like. Seems useful, and certainly I’ve had users request it. Let’s hold it up to our mantras:

• Using Mantra A: Do we want to add additional management overhead to an app for disorganized people? Probably not. And if the sticky represents our daily list of priorities, doesn’t adding multiple stickies break the whole paradigm? Probably. So maybe it’s not a good idea.
• Using Mantra B: Well, multiple stickies means more control, right? And lots of people want it, and we want a product anyone will use. So I guess it’s a good idea…along with nearly any other idea.

Even better, this exercise almost forces us back into downward arrow. Why do users want multiple stickies? What are they trying to accomplish? Is that deeper goal consistent with our mantra? If so, is there another feature that would meet their need in a way that fits the product better?

Asking why and writing a mantra won’t magically give us insight into our users. But it will force us to form hypotheses, which can be tested against evidence in the world around us.

And the constraints we create via those hypotheses allow us to make choices. Because the great products, the ones we revere, are invariably the work of product teams brave enough to make choices. We marvel at Apple’s clean, usable design. We call it simplicity but it’s not that: It’s knowing what to keep and what to leave out and having the guts to disappoint some of the users all of the time and all of the stakeholders some of the time. Many of us already know that, but we can’t bring ourselves to choose when push comes to shove.

None of this is a substitute for user research. We still need usability tests, ethnographies, brainstorming sessions, click data, bucket tests, discovery, and all the rest. But in the absence of clear hypotheses and specific questions, user research is a little like the proverbial tree falling in the forest. Research tests our assumptions and tells us where we’re right or wrong; it doesn’t tell us what to build.

This isn’t the kind of audacious problem we solve all at once…nor do we have to. Every product that actually makes someone’s life better is a piece of the solution – not just for the life it improves, but for the designer who’s inspired by it, the team that decides to one-up it.

Make no mistake: This is hard stuff. It requires tenacity, and bravery, and empathy. It requires observing how people live their lives, and then handing them products that aren’t at all what they asked for. It needs more user-centered ways of doing bug triage and structuring development workflow. But as technology becomes everyone’s ever-more-constant companion I can think of no greater or more worthy challenge.

When I renamed my blog last year, I created a tagline: “We make stuff, for people.” It was meant to be funny, sure, but also to encapsulate everything I’ve said here. Technology is meaningless without people; yet, as technologists, we’re prone to forgetting that. We end up debating strange, empty questions. Does the world really need another photo sharing service? Is skeumorphic design good or bad? Is Ruby better than Python? None of it matters on its own.

It’s important to make stuff. But it only matters if we make stuff, for people.

So, to help us make sense of this ping-pong, broad-to-narrow game we need to play today as experience designers, we wanted to go back to the thing that unites and inspires us all: our users. They are the glue that connects us as a practice — and also connect our broad and narrow thinking, our wild flights of expansive concepting to the late-night detailed design sessions. In taking a step back and discussing what they’ve taught us, we get to see a different perspective on where the work is heading — and hopefully, catch a glimpse at what’s coming next.

RE:DESIGN/ is an empowering set of conferences because it brings the design community together as a real thought leadership practice — asking us all to examine the work and actively debate and discuss where it’s going and how we want to help shape that. The size, the format, and the mix of speakers and topics create such a fun opportunity to directly contribute to the industry’s evolution, while also setting an expectation that we take our role and responsibility in that seriously, too.

RE:DESIGN/ UXD, with a focus on small-scale, salon-style discussions, eschews the typical panel format. The result is an atmosphere where attendees can interact, network, and learn from each other. This conference will bring together user experience thought leaders from traditional design firms, interactive agencies, in-house groups, journalists and beyond. This year, the conference is taking place in Silicon Valley on April 29+30. Our symposiarch for this year’s event is Marisa Gallagher of CNN.

Register now and use code UXBA for $75 off the advertised rate.

I needed to find a way to work faster and smarter and decided to address inefficiencies in my design process. As I did so, a couple of key concerns stood out for me:

Get critical design decisions made as early as possible: To go from an exploratory design to a final solution, numerous decisions needed to be made by the client. To elicit those decisions, I needed to give the client wireframes or prototypes that provided a clear context. The earlier these decisions were made, the faster I could complete the detailed design.

Reduce the client’s dependence on high-fidelity wireframes: I had routinely been asked to make painstaking changes to an early set of high-fidelity wireframes, only to discard those pages as we moved towards a final solution. Frustrating? You bet. Instead, I wanted to drive the design in the manner that Bill Buxton described in Sketching User Experiences: The fidelity of a prototype or wireframe should reflect its stage of refinement. This meant introducing low-fidelity items into the process.

Diving In

The concerns above dovetailed nicely, and to address them I formalized an early design stage I call The Shallow Dive.

Instead of attempting to achieve a final design solution, The Shallow Dive is an early UX analysis phase that is solely concerned with identifying design issues. The aim of this phase is to identify key elements and decisions that will influence the detailed design of the project.

A first, rough draft of wireframes is refined with the development group and then discussed with the client.

To start, the BA and I do a first-wave analysis of all of the screens and workflows that might be affected by the project. Then I create a first, rough draft of wireframes. We then refine these with the development group.  After discussing the wireframes with the client, the resulting decisions are carried forward into the detailed design.

The types of things that we look for might include:

• What is the optimal hierarchy on each page?
• What information is required to be carried from step-to-step of a multi-step flow?
• What options need to be presented immediately, and what can be hidden?
• Can we remove some non-critical information from the initial display?

Goal #1

The sole goal of The Shallow Dive is to speed the transition into a detailed design phase.

A number of things could slow this transition down. Lack of clarity in requirements may confuse translation into screen designs. Requirements that look good on paper may suffer when visualized. Without proper insight into the context of use, direction and priorities may be unclear.

To this end, within The Shallow Dive we also:

• Identify and resolve key decision points affecting the detailed design.
• Resolve any ambiguities encountered when the requirements are translated into screen designs.
• Identify and document any usability issues that may appear.
• Identify any user research needs.

Outcomes

This approach has worked well. It gets the client’s project manager into the spirit of iterative design right away. Since the first set of wireframes is deliberately rough and clearly emphasizes one or more design issues, the PM ‘gets it’ and understands the process of chipping away towards an ultimate goal. The PM shows those rough wireframes to their management, who become acclimated to using them to address a few key points, rather than solve all aspects of the project. If suggestions are made about an item that I don’t think is important at the present time, I make a note to ‘fix it in the mix’ and address it in the final design phase.

The Shallow Dive has some key advantages. Critical decisions are made earlier in the project, reducing the need for multiple iterations of detailed wireframes. This eliminates wasted time and shortens the design effort. Targeting the entire project allows us to present a comprehensive list of questions to the client at once, allowing for more effective use of the valuable face time with management. As well, the client gets experience in evaluating rough designs, making it easier to share ideas.

But most of all, the client accepts that design takes place in stages and doesn’t demand a comprehensive solution from the get-go. And that, my friends, is a little slice of heaven.

Go ahead and give it a look. Read your last job description. It’s impressive, right? Chances are, you emphasize your accomplishments, your ability to create stunning deliverables, and your extensive knowledge of the user experience practice.

Now, think back to your last project. But, ignore the deliverables and design ideas. Forget the budgets and timelines. What are you left with? Aside from a handful of sharpies and post-its, you’re left with the daily conversations and experiences you had with your team. What were they? Did you have to persuade somebody to see your point of view? Was there frustration, misunderstanding, or even a heated argument? Or, did things just “click” and everybody worked in harmony right from the start?

Most of us never stop to wonder why certain projects flow effortlessly while others feel like we’ve entered into a cage match. The truth is that most of us ignore the very stuff that determines if our human interactions are a success or a failure. Most of us ignore soft skills.

What are soft skills?

Everybody has his or her own definition. Some people call them “social skills”; a popular movie scene shows a man humorously screaming, “I’ve got people skills!” at his interviewer, and there are countless books on the subject. I define soft skills as the interpersonal abilities and sensibilities we gain during our journey from children into social adults.

Whatever label you prefer, taking a look at what soft skills are and how you apply them can have a huge impact on your work performance. This holds especially true for us in the UX field where we constantly strive to redefine boundaries, achieve consensus, and persuade others to see our point of view. The road isn’t always smooth, or even paved, and it’s our soft skills that will get us to our destination.

Soft skills applied

Let’s look at three scenarios where soft skills are put to the test. Whether these scenarios are familiar to you or not, ask yourself what you would do in each situation. Ask yourself how you would apply your soft skills and what result they might achieve.

Scenario 1: You say tomato, I say UX.

It’s 12:10PM, and the rumble in your stomach confirms that it is indeed lunchtime. Instead of waiting for your favorite noodle dish to be served, you are waiting in the conference room wishing your pencil were an appetizer.

Finally, the door bursts open and Don, the marketing manager, enters the room. “Hey sorry to keep you waiting! I was chatting with Susan about my landing page, and she was saying how busy you guys are! Thanks for taking the time to meet with me about this UI stuff.”

Did he really say “UI”? Okay, it’s an honest mistake. You decide to return the smile and politely respond, “It’s actually user experience, or UX. There’s a separate group handling UI design.”

He pauses a beat and shrugs his shoulders, “Hey – UX, UI, it’s all the same, right? Now, I was thinking about my landing page design last night and I made some sketches. I know you are probably a wizard at Photoshop, so try not to laugh…”

What would you do?

Option 1: Put him in his place.

You respond, “First of all, UX is not the same as UI. I design experiences, not just interfaces. Secondly, there’s a lot of thinking that goes into it that you are unaware of. I start with something called discovery…”

Outcome: You may have succeeded in educating him on what you do, but you did it in such a way as to leave him few options but to be offended or embarrassed. Regardless of what he says next, Don won’t be coming back to you with the same openness and enthusiasm as he did today. Chances are, he might be asking your boss for somebody else who is “easier to work with.”

Option 2: Respect and be respected.

You smile and say, “Don, you know how your job as the marketing manager involves creating these great strategy plans for the year and outlining each campaign to make sure it aligns with a goal? Well, user experience is similar in that we look at the objectives for a project and strategize on how best to design the system to match those needs. UX…”

Outcome: You’ve avoided bruising Don’s ego by sidestepping the fact he doesn’t know what UX is. You show respect by stating the value of his role and you speak his language by drawing parallels with your own. By pivoting from a head-on posture to side-by-side, you have a much better chance of him accepting what you have to say and forming a new partnership.

Scenario 2: I don’t buy it.

It’s Wednesday morning and you’re ready to present your wireframes. You flip through your presentation even though you know it like the back of your hand. Your diagrams are polished, but not too high fidelity. Your annotations are thorough but concise enough to be digestible. You’ve memorized the talking points and are anxious to present the design to the entire team.

You begin smoothly enough by thanking people for their time and quickly settle into your regular cadence. The butterflies in your stomach perk up as you talk about the ever-contentious homepage redesign. People begin to nod in agreement with your strategy and you sigh in relief since the hard part is nearly over. You pick up the pace and mention the new slider design and how it can handle multiple business priorities. Suddenly, you notice a frown on the CEO’s face and your throat dries like a towel. Here it comes.

“I don’t like sliders. Get rid of them,” says the CEO.

Just like that, your presentation grinds to a halt and all eyes are on you. Even the butterflies want to know what you’ll say next.

Option 1: Dig in.

You fold your arms and say, “Well, I think the slider is the best way to go.”

Outcome: Besides the soundtrack from a spaghetti western, this head-to-head approach yields both a winner and loser. And since it’s the CEO you’re facing, the end credits will reveal you were the latter. You want to avoid win-lose scenarios as much as possible because not only will they undermine somebody’s credibility, they promote a culture that values strength over merit.

Option 2: Just the facts.

You adjust your glasses and respond, “Well, I did try different options but this one seems to be the best fit for our users. People are accustomed to using sliders in our other app and analytics shows they actually look at all of the messages before exploring.”

Outcome: The best way to deal with emotional arguments is by sidestepping the emotion. You can’t rationalize somebody out of a personal design preference. So, defer to the facts of the design. Make it about the users and business goals, not you. You are not your design.

Option 3: Turn the critic into the collaborator.

You nod and reply, “Yeah, the slider is a tricky element on this page. I explored a lot of other options but I’m open to new ideas. Let me walk you through my thinking and maybe you will see something I didn’t.”

Outcome: It’s far easier to criticize a design than it is to create a solution. Engaging people in the design process will let you be seen as a person who wants to make the work great, not someone who craves credit for every decision. Plus, by drafting critics into becoming problem solvers, you minimize on the amount of unconstructive noise without risking confrontation.

Scenario 3: There’s a storm brewing and it’s going to be a doozy.

“I don’t care about rational arguments and I don’t want to talk analytics. I don’t care what you say. I want it designed this way and that’s the way it’s going to be!”

I couldn’t believe I heard these very words during an internal design review. What started out as a simple discussion quickly escalated into a heated debate. Well, only one of us was heated, but we were clearly both debating. Unfortunately for me, he was the project owner.

Conflict is inevitable. People go to war, they fight in court, and there are small disagreements between people all the time. When faced with conflict, think about your options. There’s more than the fight-or-flight response.

Here are your options when dealing with conflict:

1. Flight. Someone might be having a bad day and are looking for a confrontation. If you think it’s best to avoid it altogether, do so. There is no shame in knowing when to pick your battles.
2. Fight. If you think you are in the right and don’t mind making it clear that you are to be the winner and they are to be the loser of an argument, fighting for your position is what you want to do. Just be mindful of the potential repercussions.
3. Give in. When push comes to shove and you don’t have a solid position, you will falter. Giving in is one way to quickly end a conflict and please the other party.
4. Ask for help. Some situations are too difficult to face ourselves, so we call in somebody bigger and stronger to do it for us. That’s how it works on the playground anyway. In the office, we can call on our boss to handle things beyond our capability.
5. Compromise. While it sounds like a good thing that a mutual agreement has been reached, compromise is never satisfying. Neither party gets what they truly want. And, the compromise looks a bit like design-by-committee, which always looks ugly to everybody not on the committee.
6. Consensus. This is the holy grail of conflict resolution. You work through the material and everybody agrees the solution is a “win.”

Reading these scenarios and carefully choosing your option is a bit like living with telepathic abilities. Many times, we make choices in the heat of the moment based on our emotions, our instincts, or honestly the need to be “right.” I suggest we take a page from our own design playbook and first begin with exercising empathy. Even when you don’t know the “right” answer, thinking about what the other person is experiencing will make it far easier for you to decide how to react and have the best outcome.

What about you?

As your resume grows and you travel further down your career path, your may find yourself relying on your soft skills more and more. I’m of the mind that one’s work is never finished. In practice, there is no perfect. And, even the smoothest and most charismatic of us can use a little work. Here are three steps to getting on the path to improving your soft skills.

Step 1: List your work activities that require soft skills. For example, let’s say your list includes “Give presentations.”

Now, imagine the best presentation you’ve ever seen. Maybe it was watching a Ted Talk, your CEO, or even a colleague who works in the next office. We’ll define that performance a “10.” Now, list what skill level you think you need in order to do your job well and be satisfied.

Step 2: Write down your current skill level in another column. This takes some honest self-reflection. And remember, cheating only hurts the cheater. Unless you are delusional, in which case, I say go for it.

In this example, maybe you feel nervous and freeze up during presentations. Or maybe you lack the ability to go “off script” and exude the confidence and charisma you saw in your CEO. But, you still get your point across and nobody really complains. So, you think you’re about a “5.”

Step 3: You knew the gap analysis was coming up next, right? Well, calculate the gap between what you need to be at and your current skill level.

What do we do when we see a gap? No, we don’t go shopping. We bridge it. Here are the bricks:

Make a Plan to Better Presentations

• Brainstorm and talk to colleagues on how they honed their skills.
• Look for speaking opportunities and practice religiously.
• Join Toastmasters and refine your speeches along with your listening skills.
• Try an improv class to boost charisma and trust in yourself.

Whatever the soft skill you are looking to improve, don’t forget it takes both learning and practice. Be creative and most important, approach soft skill development with the same tenacity you do with the hard skills we hone everyday.

Level up

Developing your soft skills will yield improvements both in yourself and your relationships with others. Contentious meetings will run smoother, your opinions will be heard (and valued) more often, and you will win the employee of the month award. Okay, the award might be a stretch, but others will recognize you for your ability to handle difficult situations and influence outcomes. And best of all, you will be doing it in a way that feels natural.

Take a look at your resume again. What is the next job description you will be writing? For many of us, the UX path can wind from practitioner to leader. The transition can happen slowly, but as your responsibilities and leadership duties grow, so will your reliance on the soft skills you have developed.

Soft skills are the leader’s hard skills.

If that number surprises you, it should. The study took place in 1994.

The bar is exponentially higher now for people involved in website user experience design and development when it comes to load speed. Here’s a quick look at the state of affairs.

Slow speeds are a real usability challenge. According to software and monitoring experts at Gomez and Akamai, most users (up to 73%) have encountered a site that was too slow, crashed, froze or otherwise didn’t perform.

Your visitors’ expectations are high. A sizeable 47% of consumers expect a page to load in 2 seconds or less, and 40% of people will abandon a page that takes more than 3 seconds to load.

Slow load speed can be a costly challenge. These sources estimate that a 1-second delay can lead to a 7% drop in conversions, meaning that an e-commerce site doing $100k daily would experience a $2.5M loss in sales on an annual basis tied to 1 second in load speed.

If you’re curious about the impact of load speed on conversions, and want to learn about users’ expectations for mobile browsing vs. desktop browsing, KISSmetrics has built a stellar infographic on the topic.

Mozilla ran a study to test a similar concept: what happens if the development team combines files and rearranges the source to make the Firefox home page load 2.2 seconds faster? You guessed it. Conversions increased dramatically. Firefox saw a 15.4% lift in browser downloads.

If all of this weren’t compelling enough, you should also know that organic search results can be negatively affected by slow load times. If you run search engine advertising, you’re familiar with quality score—Google’s determination of how ‘relevant’ your ad is—and you know it impacts the per-click price of your ad. Landing page speed is part of the quality score determination, too.

You get the point. The need for speed is great, and there’s a lot at stake.

What can you do to improve load speed?

There are a lot of solutions for improving how quickly your site loads. Some are simple and quick to implement, and others are tougher to tackle. Here’s a strategy to start moving your site in the right direction.

Run speed tests. Use Google’s PageSpeed Insights tool. See what easy-to-implement suggestions it spits out and heed the recommendations.

Then run your site through the Pingdom speed tool. How many requests have to be done to load your site? Are there tracking scripts that might be outdated or aren’t needed anymore? Can you consolidate any of the other requests?

Knock out the low-hanging fruit changes. Some of the recommendations you might receive include things like:

● Minimize HTTP requests.
● Resize and optimize images.
● Optimize multimedia.
● Convert JavaScript behavior to CSS.
● Use server-side sniffing.
● Optimize JavaScript for execution speed and file size.
● Convert table layout to CSS layout.
● Replace inline style with CSS rules.
● Minimize initial display time.
● Load JavaScript wisely.
● Create a dedicated landing page for mobile.

Install plugins to simplify your process. Your content management system might have plugins available that’ll make your life easier. For example, here are a couple of popular WordPress plugins that help with load speed in various ways.

W3totalcache improves site performance by improving caching with respect to the browser, page, objects, database and more. To learn more about this, you can read up on configuring the W3 total cache plugin.

WP Smush.it—Especially if you’re a blogger, you probably use plenty of images, and images can take considerable time to load. This plugin reduces image file sizes and improves performance by compressing the files.

WP Optimize—This plugin allows you to clean up and optimize your database, especially if you’re a blogger with significant archives.

When in doubt, simplicity is key. Don’t be afraid to gut components that increase load time and A/B test simpler versions of the page against their predecessors. You may be surprised at the impact of a faster loading page, even if it suddenly has less of the stuff you once considered critical.

Toby Biddle is a seasoned website usability expert and CEO of Loop11, a tool for unmoderated online user testing.

Footnotes and sources

1 Nielsen, J. (1994). Usability engineering. London: Morgan Kaufmann.
2 You can learn about the Mozilla site speed case study here.

Anything that slows down customers or gets in their way after they download your app is a bad thing. That includes sign-up/sign-in forms that show up even before potential customers can figure out if the app is actually worth using.

It’s a simple UX equation

This antipattern seems to be going away more and more as companies are beginning to figure out the following simple UX equation:

Long sign-up form before you can use the app = Delete app

However, a fair number of apps still force customers to sign up, sign in, or perform some other useless action before they can use the app.

Example

The application SitOrSquat is a brilliant little piece of social engineering software that enables people to find bathrooms on the go, when they gotta go. Obviously, the basic use case implies a, shall we say, certain sense of urgency. This urgency is all but unfelt by the company that acquired the app, Procter and Gamble (P&G), as it would appear for the express purposes of marketing the Charmin brand of toilet paper. (It’s truly a match made in heaven—but I digress.)

Not content with the business of simply “Squeezing the Charmin” (that is, simple advertising), P&G executives decided for some unfathomable reason to force people to sign up for the app in multiple ways. First, as you can see in Figure 1, the app forces the customer (who is urgently looking for a place to relieve himself, let’s not forget) to use the awkward picker control to select his birthday to allegedly find out if he has been “potty trained.” This requirement would be torture on a normal day, but—I think you’ll agree—it’s excruciating when you really gotta go.

Figure 1: Registration Torture: Sign Up/Sign In antipattern in SitOrSquat app.

But the fun does not stop there—if (and only if) the customer manages to use the picker to select the month and year of his birth correctly (how exactly does the app know it’s correct?), he then sees the EULA (Figure 2), which, as discussed in the previous article, End User License Agreement (EULA) Presentation (Boxes and Arrows January 2nd, 2013), is an antipattern all to itself.

Figure 2: Reading the EULA while wanting to pee should be an Olympic sport.

SitOrSquat’s EULA is long, complex, and written in such tiny font that reading it while waiting to go to the bathroom should be considered an Olympic sport, to be performed only once every four years. Assuming the customer gets through the EULA, P&G presents yet another sign-up screen, offering the user the option to sign in with Facebook, as shown in Figure 3.

Figure 3: Finally! Sharing my bathroom habits on Facebook has never been easier!

I guess no one told the P&G execs that the Twitter message “pooping” is actually a prank. They must have legitimately thought that they could transfer some sort of social engineering information about the person’s bathroom habits to “achieve and maintain synergistic Facebook connectivity.” I would have to struggle hard to find monumental absurdities from social networking experiments that are equal to this. I can’t imagine that anyone thinks “Finally! Sharing my bathroom habits on Facebook has never been easier!”

Assuming that the user is a legitimate customer looking to use the bathroom for its intended purpose, and not a coprophiliac Facebook exhibitionist, we may hope that he will naturally dismiss the Facebook sign-in screen and come to the next jewel: the Tutorial, shown in Figure 4.

Figure 4: Tutorial is a sub-par Welcome experience pattern. Here it is another impediment to progress.

SitOrSquat tutorial is an extra screen that provides very little value, other than impeding the use of the app for its intended purpose. (If you need a tutorial, I recommend a much more effective contextual Watermark pattern, which I discuss in Chapter 5 of the Android Design Patterns book.)

50 Taps and 7 Screens of Antipatterns

Note that the entire app outside of registration consists of basically four screens (if you count the functionality to add bathrooms!). However, if you include all the sign-up antipattern screens (including my initial failure to prove that my potty training certificate is up to date, as referred to in Figure 1), it takes seven screens of the “preliminary” garbage before the content you are looking for finally shows up (refer to Figure 5). If you count the number of taps necessary to enter my birthday, that becomes almost 50 taps!

Figure 5: The Glory of 50 taps needed to get through the Sign Up/Sign In antipattern in SitOrSquat app.

One of my favorite UX people, Tamara Adlin (who coauthored The Persona Lifecycle: Keeping People in Mind During Product Design with John Pruitt) wrote brilliantly: “For Heaven’s Sakes, Let Them Pee.” I believe that never before has this line been so appropriate. In the absurd pursuit of social media “exposure” coupled with endless sign-up screens, with heavy-handed “lawyering up,” P&G executives completely lost sight of the primary use case: letting their customer SitOrSquat.

Long sign-up screens detract from the key mobile use case: quick, simple information access on the go. Overly invasive sign-up/sign-in screens presented up front and without due cause will cause your customers to delete the app.

There is no reason to force anyone to register for anything

When deciding whether to force the customer to perform an action, consider this: If this were a web app, would you force the customer to do this? If you have Internet connection, you can save everything the customer does and connect it back to his device using a simple session token and a guest account. And even if you don’t (for example, while riding in a subway, using airplane mode, and so on), today’s smartphones have plenty of on-board storage you can use for later syncing with your servers when the mobile network eventually becomes available.

This means there is simply no reason to force anyone to register for anything, other than if they want to share the data from their phone with other devices. As a general rule, rather than forcing registration upon download or at the first opportunity, it is much better to allow the customer to save a piece of information locally on the phone without requiring that he log in. Wait until the customer asks for something that requires registration, such as sharing the information with another device or accessing information already saved in his account; at that point completing the registration makes perfect sense.

For example, imagine how absurd the Amazon.com shopping experience would be if the app asked you for your home address, billing address, and credit card upfront—before allowing you to see a single item for sale! Yet entering the home address (where would you like to have the items shipped?) and credit card (how would you like to pay for this?) makes perfect sense during the checkout, after the customer selects a few items and indicates she would like to complete the purchase.

Finally, remember that “Forms suck,” as brilliantly quipped by Luke Wroblewski in his book Web Form Design (Rosenfeld Media, 2008). Only ask for what you strictly need to proceed to the next step and omit extraneous information. (Effective mobile data entry controls and forms is a huge topic to which I devote chapters 10-12 of my upcoming Android Design Patterns book (Wiley March 11, 2013), now available on Amazon.com).

“How many sides do you see?”

“One,” I said.

He pulled the box towards his chest and turned it so one corner faced me.

“Now how many do you see?”

“Now I see three sides.”

He stepped back and extended the box, one corner towards him and one towards me.

“You and I together can see six sides of this box,” he told me.

—Eber Hampton (2002) The Circle Unfolds, p. 41–42

Creating a Learning Resource with Aboriginal Students

My graduate school thesis project was to create a learning resource for an Aboriginal literature course for Aboriginal students at the University of Alberta. This effort was an interesting challenge since it involved me—a non-Aboriginal designer—trying to design for Aboriginal students from multiple cultural backgrounds.

While navigating the expected cross-cultural design issues, I met some wonderful people and learned a great deal about the importance of letting those with whom you design guide the research and design process.

This daunting task left me more than a bit intimidated at the end of the day. However, I felt from the outset that if I took the time to get to know my design partners and if I took the time to examine how they could guide me, somehow we could be successful.

The resource was to be a website representing Aboriginal literatures from multiple cultures to enrich the learning experience for first-year Aboriginal students. My final project was a prototype design that I then tested in paper form.

The learning resource is based on materials used in English 114: Aboriginal Literature and Culture, a compulsory, full-year Aboriginal Canadian literature course in the Transition Year Program (TYP) at the University of Alberta. The TYP program is for Aboriginal undergraduate students and is designed to prepare them for admission into one of eight faculties at the University. Some students have extensive contact with their Aboriginal communities and heritage; some have little or no contact. Most students are from Canada, but there are students in the program from all over North America.

Extra tutorial support is included in every class, to aid in the transition to post-secondary study. The material used in English 114 comes from Aboriginal authors from diverse communities in North America. Many different forms of literature are studied, including poetry, prose, and oral literatures.

Resource objectives

There were no specific learning outcomes created for the resource. It was simply meant to help students explore and appreciate the literature—particularly oral literatures—through video, audio, images, and text. Both teachers and students felt that commenting on and discussing works on the blog portion of the site was important. Teachers felt that the materials and the blog would help students become more engaged with the material.

“I found I wasn’t comfortable, until the end, talking to the professor because for me, the work I was doing was so personal I was afraid of criticism—to think I didn’t know what I was doing. I was kind of shy.”—Jesse, student

I spent many months completing a literature review. I didn’t find much research on visual design practice for multiple cultures and genres. I interviewed students, all the instructors, the teaching assistant, and many other academics and professionals working in Aboriginal studies. I also audited courses in Aboriginal literature and attended as many classes as possible for the course for which I would design the website.

There were some pretty clear needs identified for the course that the instructors, students, and I felt might be helped by the use of digital media. One of the biggest benefits centered on the importance of oral literatures. Audio and video files would clearly benefit the study of oral literatures when storytellers could not be brought into the classroom. Other benefits were to:

• Help students refine independent research skills
• Encourage communication between students and between instructors and students by creating a forum
• Show media in class using the website
• Give students the opportunity to access materials outside of class
• Provide background materials to students who are unfamiliar with the material, benefiting students who hesitate to ask questions
• Provide a more “low stakes” context for students to explore concepts raised in class
• Allow students to seek out information
• on their own and explore issues they might be too embarrassed to raise in class
• Increase continuity between course sections and allow instructors to share resources
• Allow instructors to check in more often on students’ progress
• Give reticent students the chance to express opinions in the possibly less-intimidating forum
• Use multimedia to demonstrate the “webbed” nature of the texts by allowing students to see how issues intersect

Some pseudonymous student comments about the course:

“I think there wasn’t enough visual stuff, personally. I would like to see the places described in the story.”—Sarah, student

“We did have some overheads, but we couldn’t make out the overheads.” —Trish, student

“ …when the author reads it you are like, wow, is that ever powerful, I’ve got tingles. You can hear their emotion and what they are trying to portray with the literature.”—Christine, student

“Video would be awesome—tone and facial expression are really important.” —Jason, student

Importance of Visual Design

I obviously can’t summarize here all the project complexities or discuss all the wonderful things I learned throughout this process. One aspect of the research, however, reinforced for me the power of collaboration in the design process.

Refining needs and features for the project was challenging, but my most daunting task from the outset was how to create a visual design to meet the needs of the university course, the multiple cultures of the students, and also reflect the literature studied.

Students and instructors also felt the resource had to visually represent traditional and contemporary Aboriginal culture without using imagery that was specific to one culture or geographic region, but they also believed it needed to reference Western literary traditions because many of the authors on the syllabus referenced Western literary traditions in their literature. A daunting task to say the least.

Visual design is not of minor importance to Aboriginal cultures and the visual expression of those cultures.

While progress has been made, by various institutions, to foster understanding of Aboriginal cultures in Canada and the United States, images created by non-Aboriginal and Aboriginal designers found in mainstream media are not nearly as enlightened. Visual communication design creates effective communications that can “affect the knowledge, attitudes and behavior of people” (Frascara, 1997, p. 5). If designers can affect people with the communications they create, then they might be able in some way to prevent visual stereotyping of Aboriginal peoples and cultures.

It is easy to find examples of appropriation and stereotyping of imagery in mainstream media. Logos for the Atlanta Braves, Cleveland Indians, and Chicago Blackhawks are some highly visible examples of blatant stereotyping, but more subtle examples also exist. The popularity of the “New Age” spiritual movement is one such example of cultural appropriation that furthers the misrepresentation of Aboriginal cultures (Hulan & Warley, 1999–2000).

“ …you just can’t have a dreamcatcher a wagon and a chief on every page. There is a lot more to Aboriginal culture.” —Jason, Student

“ …the fact that there’s a million different medicine wheels if you look on the internet, it’s almost like a cliché or something, even though it has real cultural worth.” —Rob, Instructor

The “Aha” Moment

My plan for the visual design process had been to conduct semi-structured interviews with students and instructors and begin collecting ideas for visuals. I had hoped that from there we’d have some ideas to start working together on creating some participatory design sessions.

However, each time I came to discuss the visual tone of the resource and what should be included, it seemed we ended up talking about placement of menus and what types of information were desired for the website. Looking at websites or thinking about them made it very hard to get away from talking about features, functionality, and content. Not that those factors were not critical to shaping the visual design, but I wanted to discuss the visual tone and symbolic references that users felt might be important to include.

My thesis supervisor suggested I try to move away from the digital medium into the print medium to avoid the focus on features. Why not look at some other medium? You’re thinking this is the big “Aha” moment right? Not yet…

My plan was to try a session with five students reviewing book covers from Aboriginal authors and discussing what visual design appealed to them. From my own training and experience as a designer, I selected what I felt was a representative sample of different visual styles: Illustration, photography, typography, and the like.

Throughout my research, a critical theme was the importance of the land and landscape to Aboriginal cultures. I had this information, but I wasn’t really sure what to do with it. Any specific references to a geographic region might exclude some students or authors referenced in the curriculum. Students were from all over North America and had connections to a huge variety of landscape—prairies, mountain ranges, coastal regions, arctic regions, rain forest… This project had to be respectful to the students, teachers, and Aboriginal literatures studied. Imagery was already a very sensitive topic, so omitting any particular region or any one group was far from ideal.

During our sessions, students gravitated to abstract images of landscape that employed natural color palettes. Interestingly, some students selected these images because they felt the images represented both contemporary and traditional cultures. Few if any students selected imagery that had specific symbolism. There was great sensitivity to the use of symbols, partially because they may exclude certain groups but also because there has been a long history of offensive appropriation of Aboriginal symbols. Most students seemed to gravitate to those images that suggested the land in an abstract way.

For example, the book Transitions was selected as both a contemporary and traditional portrayal of Aboriginal culture. One student thought that because the stones were constantly evolving and were part of the land that they were representative of the contemporary and the traditional. Another student mentioned that the industrial feel of the rock landscape suggested the contemporary but that the rocks also suggested traditional elements of the “Grandfather, the stones of the earth.”

Monkey Beach and Transitions: Photography and landscape seemed most appealing to students.

I had already been thinking about using natural imagery, but the problem seemed to me to be the suggestion of one geographic region. Abstract representations of landscape seemed to solve my dilemma. It was suggestive of some type of landscape, but it wasn’t specific. When students suggested a color palette of earth tones, images of landscape, and photography instead of illustration, I had my a-ha moment.

I now had a direction for the visual design that was so simple yet would address a very complex issue. I could create an image that was respectful and addressed what was important to those involved but was universal enough not to exclude anyone.

Putting it all together

In the discipline of design—in sharp contrast to the modernist movement—there is a concern with how to tailor communications specifically to suit audience needs. McCoy (1995) calls this “narrowcasting” instead of “broadcasting.” With this concern comes the understanding that designers cannot make assumptions about cultural groups, even their own (Steiner & Haas, 1996).

I felt so incredibly challenged by this project not only because it meant I had to try to learn how to respectfully design with students and teachers from cultures that I was not familiar with but also because I could not understand how I could possibly design something that could be tailored to so many varied groups. My session with the students helped me realize how my own background led me to subconsciously dismiss the idea of finding some kind of universal solution since it would go against my own postmodern sensibilities.

Those sensibilities closed my mind to the possibility of universals that might be meaningful to the students and also be representative of the wide variety of literatures and cultures represented in the curriculum.

In short, without the different perspectives brought to the project by the students and teachers I was working with, I would probably never have come to the solution that I did. As I have moved forward with my career and my teaching and I see so many changes in the world of design, I think that more and more we may find ourselves in a position where we may have to challenge ourselves to find those universals. My takeaway from all this: try to practice a collaborative approach whenever possible to inform your work and allow yourself to see six sides of the box.

Works Cited

• Frascara, J., (1997). User-centred Graphic Design: Mass communications and social change. London: Taylor & Francis.
• Hulan, R., & Warley, L. (1999–2000). Cultural literacy, First Nations and the future of Canadian literary studies. Journal of Canadian Studies, 34.3–4, 59–73.
• McCoy, K. (1995). Graphic design in a multicultural world. How 10(2), 146–151.
• Steiner, H., & Haas, K. (1996). Design for the global village. Applied Arts, 11(3), 46–48 and 50–52.

Conceptual Model: a Model for Users’ Mental Model

A conceptual model of an application is the model of the application that the designers want users to understand.  By using the application, talking with other users, and reading the documentation, users build a model in their minds of how to use the application. Hopefully, the model that users build in their minds is close to the one the designers intended. This hope has a better chance of being realized if the designers have explicitly designed a clear conceptual model as a key part of their development process.

A conceptual model describes abstractly — in terms of tasks, not keystrokes, mouse-actions, or screen graphics — what users can do with the system and what concepts they need to be aware of. The idea is that by carefully crafting a conceptual model, then designing a user interface from that, the resulting application will be cleaner, simpler, and easier to understand. The goal is to keep the conceptual model: 1) as simple as possible, with as few concepts as are needed to provide the required functionality, and 2) as focused on the task-domain as possible, with few or no concepts for users to master that are not found in the application’s target task domain.

Object/Operation Analysis

An important component of a conceptual model is an Object/Operation analysis: an enumeration of the user-visible object-types in the application, the attributes of each object-type, and the operations that users can perform on each object-type. Purely presentational and purely implementation object-types have no place in an application’s conceptual model because users will not have to be aware of them.

Objects in the conceptual model of an application can usually be organized in a type-hierarchy, with sub-types inheriting operations from their parent types. Depending on the application, objects may also be organized into a containment hierarchy, i.e., in which some objects contain other objects. Laying out these two hierarchies in a conceptual model greatly facilitate the design and development of a coherent, clear user interface.

This analysis can help guide implementation, because it indicates the most natural hierarchy of implementation objects and the methods each must have. It also simplifies the application’s command structure by allowing designers to see what operations are common to multiple objects and therefore can be designed as generic operations. This, in turn, makes the command structure easier for users to master: they must only learn a few generic commands that apply to many object-types, rather than a larger number of more narrowly applicable object-specific commands.

For example, in a well-thought-out application that allows users to create and manipulate both Thingamajigs and Doohickeys, when users know how to create a Thingamajig and want to create a Dohickey, they already know how because creation works the same way for both. Ditto copying, moving, deleting, editing, printing, etc.

Example: Object/Operation Analysis for a Simple Office Calendar App

For example, let’s examine an objects/operations analysis for a simple office calendar application. The objects, attributes, operations, and relationships might be as follows:

Objects: It would include objects like calendar, event, to-do item, and person (see Table 1).  It would exclude non-task-related objects like buffer, dialog box, database, and text-string.

Attributes: A calendar would have an owner and a default focus (day, week, month). An event would have a name, description, date, time, duration, and a location. A to-do item would have a name, description, deadline, and priority. A person would have a name, a job-description, an office location, and phone number. However, Events should not have byte-size as an exposed attribute, because that is implementation-focused, not task-focused.

Operations: Calendars would have operations like examine, print, create, change view, add event, delete event. Events would have operations like examine, print, and edit. To-do items would have more-or-less the same operations as events. Implementation-related operations like loading databases, editing table rows, flushing buffers, and switching modes would not be part of the conceptual model.

Table 1. Object/operation analysis for a simple office calendar application.

Keep it Simple

Sometimes it is tempting to add concepts to provide more functionality. But, it is important to realize that each additional concept comes at a high cost, for two reasons: 1) it adds a concept that users who know the task domain will not recognize and therefore must learn, and 2) it increases the complexity of the application exponentially, because each added concept interacts with many of the other concepts in the application.  Therefore, extra concepts should be resisted if possible. The operative design mantra with conceptual models is: “Less is more.”

A Conceptual Model Provides a Foundation for the App and the Project

The user interface design translates the abstract concepts of the conceptual model into concrete presentations and user-actions. For best results, the user interface is designed after the conceptual model has been designed.  Scenarios can then be rewritten at the level of the user interface design. Designing the UI from the conceptual model may expose problems in the conceptual model, in which case the conceptual model may be improved.

A conceptual model provides a foundation not only for the UI design, but also for the application’s implementation and documentation. It therefore plays a central role in the design and development of the overall product.

Summary: Six Benefits of Conceptual Models

Starting a design by devising a conceptual model has several benefits:

1. By laying out the objects and operations of the task-domain, it allows designers to notice operations that are shared by many objects. Common operations across objects make the UI simpler for users to learn and remember.
2. Even ignoring the simplification that can result from noticing shared operations, devising a user-model forces designers to consider the relative importance of concepts, the relevance of concepts to the task domain (as opposed to the computer domain), the type hierarchy of objects, and the containment hierarchy of objects. Having thought about these things greatly facilitates designing a user-interface.
3. A conceptual model provides a starting point for the development of a product vocabulary, i.e., a dictionary of terms that will be used to identify each of the objects and operations embodied in the software. This helps ensure that terms are used consistently thoughout the app and its documentation.
4. Once designers have a conceptual model for an app, they can write scenarios depicting people using the app to perform tasks, using only concepts from the conceptual model and terms from the vocabulary. For example, a conceptual-level scenario for the calendar application might be: “John checks his appointments for the week. He schedules a team meeting, inviting team members, and adds a dental appointment.” Such scenarios (which can be separated into use-cases), help validate the design in functional reviews. They can also be included in product documentation and training. Conceptual scenarios describe tasks and goals without revealing the UI-level user interactions required to achieve those goals, so they can be used as task descriptions in usability tests.
5. A conceptual model provides a first cut at the app’s object-model (at least for the objects that users will be aware of), so developers can use it to begin implementing the app.
6. An actively-maintained conceptual model supports a better development process. It can insure that all user-visible aspects of an application (functionality, terminology, UI, documentation, support, …) are consistent. By making the conceptual model the joint responsibility of all team members, the application can be made coherent. Both of these also reduce development resources by reducing rework.

Further Reading

•   Johnson, J. & Henderson, D.A., “Conceptual Models: Begin by Designing What to Design”, Interactions, Jan-Feb 2002.

•   Johnson, J. & Henderson, D.A., Conceptual Models: Core to Good Design, Morgan & Claypool, 2011.