UX One-liners

Written by: Nathan Gao

A little background to start: I’ve had the honor of working as a designer-in-residence for General Assembly’s User Experience Design Immersive Pilot Program (UXDI) from June through July. Our team built, launched, and taught a UX course 5-days a week, 8-hours a day, for 8-weeks straight.  It was quite the challenging, yet rewarding experience.

However, learning from our approach, I found something about the way we bring people into the fold that we can stand to improve.

We instructors spent much of our early days teaching techniques by going through truckloads of slides. We sent students home to read more chapters and articles loaded with paragraphs after paragraphs of definitions and use cases.

Yet, when students have trouble with a particular technique or concept during their free practice time, we’ve always had to re-explain to them the crux of these ideas with piercing simplicity.

Why don’t these simple core ideas exist in a simple, more easily referenceable form?

Looking up any UX terminology in Google results in many results: incomplete lists long abandoned, or gigantic lists of terms with accompanying paragraphs–and that’s only if you’re lucky enough to avoid the full blown articles. At a time when Dieter Rams’ As Little Design as Possible is common advocacy, we can present the fundamental impressions of UX’s core capabilities as something much more succinct than a wall of text. I’d argue that we would want the same considerations for our own products and content.

I have a modest proposal. Introduce the essence of your techniques and concepts in a single sentence. Do it in a one-liner. If it goes beyond one sentence, make it shorter.

Understand that these one-liners are NOT meant to explain UX techniques or concepts as well as articles or lengthy discussions can. Likewise, the real substance behind any of these techniques and ideas will expand and change over time, context, usage, and the like.

However, my contention is that there should be a much simpler and more concise way for people to see to the fundamental core of a technique or idea. For any confusion and disagreements that exists within the UX community, one of our common goals is to better communicate our ideas and intents to our teams and colleagues so that we can better create.

Why not then reconsider how we communicate the most basic fundamentals of what and how we work?

UX has always had a rich tradition steeped in academia, which is often somewhat verbose. It’s only relatively recently that its relevance to the consumer world has been realized on a massive scale. As UX adapts to a rapidly shortening cycles of technological–and by proxy, behavioral–change, we need to consider simplicity and conciseness in introducing the rest of our world to not only the products we design, but also the universe in which we create.

There will be another session of UXDI session beginning in September. I’ll be preparing a list for the students to use. Would you do it for a class you taught?

Here’s to an improved UX of UX.

Here are some one-liners I think adequately communicate the focus of their associated techniques and methodologies. This is a start. Add your own in the comments.

Card Sorting Activity in which users organize a set of data in ways that they think makes sense.
Contextual Inquiry Ethnographic Interviewing technique where the user is observed using products in their natural usage setting.
Ethnographic Interviews Interviewing techniques combining one-on-one interviewing and extensive observation.
Facets Preset categories used to filter information/content into more digestible chunks.
Heuristics Quick rules of thumb used to streamline design decisions.
Metadata Data used to categorize other data.
Personas Description of fictional yet realistic persons that represents a target user group/market.
Scenarios A story describing a user’s problem situation and how she might use a product to achieve a solution.
Site Maps Modular diagram conveying your site’s page inventory and, to a lesser extent, categories.
Usability Testing A test conducted with end users to see how usable they find a product.
User Flow A path map highlighting what a user has to do within your product to accomplish his goals.

Information Architecture’s Teenage Dilemma

Written by: Jeff Pass

Imagine if you will information architecture as a pimply-faced, malcontent teenager.  IA is eager to express and redefine itself. It wants to be an individual yet accepted by its peers. It is simultaneously aggravated and apathetic about its parents, mentors, and role-models. It is a bit of a mess, but a wonderful, beautiful mess with endless opportunity and potential.

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 13th 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.

The Shallow Dive

Written by: Mark Richman

At a recent job, my department faced large budget cuts. When the dust had cleared, I found I had become a UX group of one. This didn’t come with a corresponding slowdown in work – in fact, following a major rewrite of our call center application, our department was already struggling to keep pace with a backload of business initiatives. Cuts slashed our BAs, our development group, and our QAs, yet everyone remaining was being asked to speed up.

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.

Rough draft wireframe
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.

The General Stakeholder Interview

Written by: Kim Goodwin

This is an excerpt from from Kim Goodwin’s excellent Designing for the Digital Age. It is quite long, so we’ve broken it into several sections. Many thanks to Ms. Goodwin and Wiley for allowing us to share this with our readers.

Topics applicable to most stakeholders

Try to keep the interview conversational rather than reading from a list of questions, but consider writing a list of topics on the inside cover of your notebook where you can glance at them when you get stuck. These are some questions applicable to most stakeholders; topics specific to particular stakeholder roles follow. Note that it’s as important for in-house teams to ask most of these questions as it is for consultants; you may know one answer, but do you know this particular stakeholder’s answer?

What’s your role with respect to this product?

If you’re a consultant, the reason for this question is obvious, but even if you’re an insider, you or one of your teammates may not understand someone’s role as well as you think you do. It’s also an easy, non-threatening way to get the conversation started.

What did you do before this?

Answers to this question will tell you whether this person has some unexpected expertise to share and will give you some clues about how this person might view the world; a product manager who has a background in the domain but not in product management won’t have the same concerns as an experienced product manager who doesn’t know the industry.

What is this product or service supposed to be?

It’s interesting to see what aspects of the product or service each person emphasizes. One of the key things to look for in the response is any hint of functionality no one has mentioned before, since this is important not only in helping the product team achieve consensus, but also in keeping the project timeline within bounds. Some stakeholders will answer you with an impenetrable wall of buzzwords: “It’s a distributed, service-model three-tier architecture that will leverage existing technology,” and so forth. In such cases, ask them to break down what that means by asking how they would explain what it does for the average user.

You’ll also want to ask the reverse of this question: What is the product not meant to be? Some stakeholders have difficulty being realistic about what they can accomplish, so it’s important to build consensus about boundaries as well as goals.

Expect a wide range of answers. With respect to software, this diversity is usually due to what people think will be in the first (or next) version versus what will be in later versions. You may be able to clear things up by asking each interviewee to compare the immediate release to what the product will eventually become.

Who is this product for?

Although the marketing or product management people have the most informative answers to this question, the range of answers from other stakeholders can highlight issues your research will need to address. It’s also important to know what assumptions there are about users so you can test them and see if they’re true.

There may be variation due to a poor understanding of who the users are. On a recent project, for example, one stakeholder told us the product was going to be so indispensable that executive users would want to log in remotely from the airport, while another told us executives would only consume monthly reports generated by subordinates. Both agreed that executives were the targets for the information, but they had differing opinions about whether executives would see the information as so mission-critical that it had to be accessible at all times. This sort of variation doesn’t mean the organization is dysfunctional; it just means people need better user data to clarify things.

When is the version we’re designing going to be released?

It’s normal to hear optimism from the marketing and sales people and pessimism from the engineers, but if the answers to this question differ by more than a month or so, mention it to your project owner. Also, don’t forget to ask why the timeline is what it is. Sometimes there’s a serious mismatch between goals and timeline—stakeholders may say this project is going to be the basis for all of their products in the next ten years, but they want to launch it in just a couple of months. Don’t just let this slide; it will bite you later. Instead, point out the apparent contradiction and ask about it. “You’ve said the product has to be all things to all people. You’ve also said it has to ship by the end of this year. Those two things are potentially conflicting. Which is more important and why?” A reasonable executive stakeholder will clarify what the priorities are.

What worries you about this project? What’s the worst thing that could happen?

This is a good topic for the later part of the interview, after the stakeholder has relaxed a bit. Sometimes the anxieties will be things you can help with, such as worries that the product won’t have the right functionality. In other cases, the worries may point out organizational weaknesses you need to be aware of. While engineers always worry that there won’t be enough time to build the product the way they’d like to (and they’re always right), listen for truly unrealistic expectations. You may hear concerns beyond the usual level of grumbling that one part of the company is not up to doing what it needs to. If you hear that the marketing team is largely inexperienced in the product development world, you may be able to help by educating as you go. If it appears the engineering team is less capable than most, you’ll either need to suggest some additional engineering resources if you’re in a position to do so, or you’ll need to be fairly conservative in your design.

What should this project accomplish for the business?

In a highly functional company, most stakeholders can answer this question to some extent, but it’s amazing how often a senior executive is the only one who can do so. When this happens, you can help the organization by disseminating the business goals during the design process.

If stakeholders struggle with articulating this, try asking more specific questions: How will this product generate revenue? How will this product save money? How should this product affect the company’s brand and position in the marketplace? What should the company be able to accomplish with the product that it hasn’t before?

How will you, personally, define success for this project?

Many stakeholders will simply reiterate the business goal, or they’ll say the thing they’re most worried about won’t happen. Some will give you insight into other things that worry them or what will get them excited about the design. You might hear things like, “If we just avoid this problem we’ve had before, I’ll be happy,” or “Other people in the company will finally see the value my team can offer.” Understanding these issues is essential in building support for the design.

Is there anyone you think we need to speak with who isn’t on our list? Who are those people?

Ask this one toward the end of the interview. Check in with the project owner later to see if discussion with any of the people mentioned is really a good idea.

How would you like to be involved in the rest of the project, and what’s the best way to reach you?

This is a good one to save for last. It’s an especially good opportunity to make sure the senior people stay involved at key decision points. If you have a middle manager who’s reluctant to involve senior management, this gives you room to say “The CEO specifically said she wanted to be involved in that meeting.”

See also

Excerpted with permission from the publisher, Wiley, from Designing for the Digital Age: How to Create Human-Centered Products and Services by Kim Goodwin. Copyright (c) 2009.

The Marketing Stakeholder Interview

Written by: Kim Goodwin

This is an excerpt from from Kim Goodwin’s excellent Designing for the Digital Age. It is quite long, so we’ve broken it into several sections. Many thanks to Ms. Goodwin and Wiley for allowing us to share this with our readers.

Marketing stakeholders

Marketing stakeholders (such as marketing executives and most product managers) are usually responsible for promoting the company’s brand, identifying new market opportunities and products that could address them, or both. Most marketing people will immediately view designers as allies who will promote a customer-centric point of view. Some view designers as threatening rather than helpful, though; when you talk about doing research and driving some of the requirements, you may be treading on territory they view as theirs. If they’ve just spent hundreds of thousands of dollars on market research that doesn’t provide the answers you need, you also have the potential to make them look bad. Talk about how the design team’s work is in addition to theirs, not instead of it, and describe how you can help communicate their vision to the engineering team (which is often a point of frustration).

There are a number of questions the marketing people are best equipped to answer; some examples follow. The more brand-focused questions are things a visual or industrial designer will particularly want to know, though the answers can prove useful to the whole team. These questions are in no particular order; they generally fall somewhere in the middle of the questions for all stakeholders listed above.

Who are your customers and users today, and how do you want that to be different in five years?

It’s essential to see where the marketing team wants to take the product or the brand, especially if it involves a change in direction. This will affect how you plan your user and customer interviews, since you won’t want to limit your research to existing customers if the idea is to break into a new industry vertical. (Note that if you’re a consultant planning the research before the project kickoff, the project lead should have asked this question at that time.)

Sometimes the vision is so ambitious that it sounds impossible. For example, the interviewee might paint a very broad picture about handling all types of business communication. This could turn into a monstrous product that attempts to replace phones, email, instant messaging, online conferencing, and more. Try asking what business they definitely don’t want to be in.

Ask for clear timelines. Sometimes, the engineers think the marketers are unrealistic because they talk in very grandiose terms, but don’t always clarify when they want the vision to be fully realized. Often, the marketing folks are talking about a five-year vision and don’t expect the whole thing to be accomplished in the first release a year from now. This is one of many opportunities to help improve communication between groups.

How does this product fit into the overall product strategy?

If the product is part of a bigger suite of related offerings, you need to know what role it plays in that greater plan. For example, if you’re designing the entry-level product in a set and the marketing team envisions getting people to upgrade as their needs change, you know you’ll need to focus on giving that product limited but excellent capabilities and a design that can scale up. If they’re envisioning the product as some sort of platform for future growth, you’ll need some idea what those possible directions are if you’re going to have any chance of anticipating them in the design.

Who are the biggest competitors and what worries you about them? How do you expect to differentiate this product?

While it’s seldom helpful to spend a lot of time on competitive research unless you want to build a “me too” product, you at least need to know what else is out there. Ideally, you will get to interview and observe people using these competitive systems, too. Some people see the competition as the other companies trying to sell similar products, but be sure to discuss the hidden competition, which might even be some combination of paper, telephones, and face-to-face communication.

What three or four qualities do you want people to attribute to your company and your product?

In an established company, good marketing people have a clear answer to this sort of question, and that answer guides everything they do. This answer is essential when your mandate includes developing a unique design language for hardware or software. It can be useful for interaction design, as well; when you are presenting a particular bit of functionality or behavior, describing how it supports the brand values can be a powerful argument. Mind you, this argument works best with very brand-driven organizations, such as consumer product and service companies—in a company that thinks the brand is just the logo, you won’t have much luck with this approach.

In organizations that are less sophisticated about brand, people may struggle with this question. This is where analogies can come in handy. Some people try to get at this information by asking “If your company were a car, what kind of car would it be?” It can sound less silly and be more productive to frame the question in human terms, such as “If your product were a person, how would you describe its qualities?” You might also ask for examples of other brands or products they think embody each attribute, and why.

Note that most larger companies separate product marketing and corporate marketing; the product marketing people may be focused more on understanding their particular segments, leaving the brand issues to the corporate people. If that’s the case, ask this question of the corporate team.

What is the current state of the identity, and could we have a copy of the style guide (if there is one) and examples of it applied to materials?

This question is essential for consultants, but in-house teams probably have this information already. Like the previous question, this is more geared toward corporate marketing than product marketing. In a company that’s sophisticated about marketing, you’ll see consistent visual themes across print and online collateral as well as the visual and industrial design of products; you can look at any Apple product or marketing piece from ten feet away and immediately see that it’s from Apple, for example.

In less sophisticated companies, you may see one style applied to print, another to the Web site, and still another applied to the products (or even worse, no consistent style across any of them). You might also find that the company has a style guide geared almost entirely toward print rather than pixels or hardware. If you’re lucky, the style guide will at least take into account the visual design differences between print and Web design. It’s a rare company, though, that has much of a style guide suited to digital product design, so visual and industrial designers must often interpret the spirit of those guidelines across platforms.

When the style guide doesn’t seem appropriate to what you’re designing, it’s critical to get access to a senior brand stakeholder; a less-senior marketing person dedicated to a product or group often enforces the guidelines without seeing where they should be bent. For example, when my team was designing a phone for one company, the relatively junior marketing person assigned to the product told us it absolutely had to be a certain color and had to contain certain style elements common to the company’s other phones, even though our mandate was total reinvention of the product family. When we were eventually able to get a senior marketing executive involved, he immediately understood why the parameters needed to be varied, so long as the design still conveyed the brand attributes in other ways. This is certainly a tricky situation when you’re an in-house designer; your best option might be to let it go for now, but later try a style treatment that follows the guidelines and one that captures the spirit of the brand even if it breaks the guidelines.

 

See also

Excerpted with permission from the publisher, Wiley, from Designing for the Digital Age: How to Create Human-Centered Products and Services by Kim Goodwin. Copyright (c) 2009.