The MVP brings tremendous value to a team’s Lean UX practice but it’s critical to understand what “value” actually means and how context changes that meaning. Value for your usability test participant is different than value for your a/b test subject as it is for your product owner or CEO. Your MVP must vary as you move through the validation cycles from each of these consumers of that MVP to the next. The shorter those cycles can be, the less time you spend refining the wrong solutions and the more time you spend refining the more accurate hypotheses.

Laugero makes a strong case for the MVP in his article “Lean UX is Dead, Long Live Lean UX” with this line, “As a discipline, we UXers don’t typically think too much about cost and benefits. We’re not typically held accountable to profits-and-losses. But MVP’s are a good discipline for us — they make us think about how to cost effectively make good decisions. They reduce product strategy to its fundamentals — what features move the business forward, fastest. That’s not typically the way we think. [emphasis added]”

There’s a clear reason why many UX practitioners don’t often think this way. For years, we’ve been focused on delivering documentation as opposed to product experiences. These have been the measuring sticks by which we’ve been evaluated, hired and compensated. The strategic value of UX is hardly ever revealed in the depths of a design specification. We’ve not been afforded the opportunities to engage in conversation at this strategic level because most of our customers see us a pixel-pushers.

By bringing the validated learnings that come out of the Lean UX process to our teams and leaders we begin to shift the perception of UX design from a tactical craft to one that provides strong strategic insight and value. That value can be communicated in many forms. These communication deliverables are transient artifacts and should facilitate knowledge transfer when person-to-person conversation is not an option or is not sufficient.

That being said, getting caught up in the production of these artifacts buries the UX discipline under the label of document-creators. Instead, as each young UX professional learns the craft and begins to master the design of compelling, useful and usable products and services the strategic value of these outcomes quickly outweigh the actual pushing of the pixels. Lean UX provides today’s UX practitioners with a framework for becoming more agile in their practices, focusing their tools with targeted depth so as to minimize wasteful work, and create short feedback cycles that drive towards validated design concepts that solve big, hairy business problems. It is through these repeated, strategic successes that our discipline will become even more valuable to our organizations than it is today.

Our product team was reviewing the feature backlog to determine what should have top priority. We’d heard from many of our larger customers that they wanted Users and Groups to be supported by my company’s product, ProtoShare. There were user stories written for this: “As an editor I want to be able to easily hide/expose content to arbitrary groups of users so that I can control their experience” – which was the main story that we wanted to tackle.

I really like user stories for higher-level stakeholders. Executives and business analysts approach the problem of product development from a different angle. The primary motive is “what can we build that will increase our revenue the most?” Now, thankfully, this dovetails with “what do our current users want?” and “what do potential customers want?” but it puts a particular lens on the problem. By focusing on a user story, which can be written quickly and understood at a high level, you can make a pretty good rough-cut at what you should build and what the business value should be.

Now in a pure Agile environment, this user story might have been sent straight to developers. Can you see the danger here? I’ve heard of Agile teams who want only one sentence of guidance before they start coding. If your developers are also UX experts, no problem. They can solve the user issue, design and develop a solution, and off you go.

So what did we do next? We prototyped. Using ProtoShare, our UX Guru prototyped an implementation hypothesis. It included facets of the issue that weren’t included in the original user story: If arbitrary groups are supported, how are they managed? Do users have their own groups or are they project-wide or account-wide? If someone is added to a group, what happens to all the artifacts that the group is subscribed to? Are groups just a way to select a bunch of users or do they have some independent existence?

Prototyping made these issues concrete. Instead of thinking up all the edge cases, the higher-level users could experience the prototype and would ask specific questions (e.g. “I want to do this, how do I do it?”). Now sometimes these questions fall outside of the original user story, but sometimes they don’t. In the end, we answered enough of these questions to take it to our end users.

So we ran some sessions with customers who had specifically asked for this feature. They had lots of users. During these sessions, the reaction was typically: “yeah, this is useful, but I really want it to do X, Y and Z.” Ultimately, once the users saw and experienced the feature, they were able to effectively judge the actual value of the feature to them.  What we realized is that the feature we were considering to be the top business priority was really a “nice to have” for a handful of larger customers.

You can see why the business stakeholders liked this feature at first: it met the needs of our largest customers. The thinking was that we want to keep them happy, and that by addressing this need we would be a better fit for other big customers. And there was nothing obvious that appeared to serve this end better.

So our UX team learned, through collaboration with the business stakeholders, what the value proposition was for this feature. The business stakeholders learned, through collaboration, that the feature was deeper, more complicated and had more profound implications than were obvious at first glance. And both business stakeholders and the UX team learned from customers that this really wasn’t going to help us sell any more product.

Missing from this story is our development team. They never got involved other than some initial feedback about the feasibility and technical difficulties of various proposals. They continued to work on the already prioritized and understood features.

If we had decided to go ahead and build this feature, there would have been additional collaboration all up and down the chain focusing on development implications. (There are frequently even more missed functionality discoveries once development starts. Having open lines of communication to clear these up quickly is important.) By the time implementation was complete, business, UX, developers and end users would all understand and confirm the value of the feature.

Ultimately, the decision was made not to add this functionality in the next sprint. The total elapsed time between the initial prioritization of the idea and its abandonment as top priority was 3 days. But what I really love about this process is that we actually significantly moved the ball forward on this feature. We didn’t drop the idea completely, we just adjusted its priority. And the knowledge and understanding of the problem didn’t disappear. The user story is still in our system and it is linked directly to prototypes that explore the problem, questions and comments by all stakeholders, decisions and resolutions that are recorded along with their reasoning.

Something else you’ll notice about this story is that for each step in the collaboration, there are defined roles: business analysts prioritize the user stories and communicate that to UX. UX investigates the stories and communicates those issues to business analysts. Part of UX’s investigation involves testing hypotheses with end users.

This process emphasizes my two touchstones for successful UX: user testing and validation, and creation of a shared understanding. One other feature of this method of collaboration is that you need to maintain structure and responsibility for the various stages of the collaboration. This is not free-form brainstorming. It’s adding collaboration to a defined process. Business analysts do their work, and then they are required to communicate it to UX. The communication is a two-way street, with the goal of creating shared understanding. UX pros do their work and communicate it to business analysts, end users and developers, again in a back-and-forth process that listens to feedback, gathers evidence and responds to it.

There is one key reason why I love professional wrestling: seeing that one moment where I can still suspend disbelief.

After reading two articles about what designers can learn from Ghandi and the Red Baron, I thought, wrestling taught me a lot more than this! So, what can designers learn from Professional Wrestling; a set of guys running around in their underwear? Actually a tremendous amount. I’ll share three key insights. Prepare yourself and set aside your judgements that this is white trash entertainment.

1. The Story

This is the most important part is wrestling, as well as design. In wrestling, without a story, you have just two guys rubbing eachother in their underwear, which is less than exciting. The story is what people buy into and makes them tune in. A great story has people wanting to see what happens next. You see the same thing in design. When you present to a client, executive, or team, you don’t present just a design; you present a story. You tell them how everything is set up and how it has all fallen into place; sharing the problems and the opportunities within this design. You tell them why the design matters and find that hook to pull your client in.

Walking into a client with no story is inviting them to give their opinion and random comments. Setting the stage for a story focuses their feedback. It gives them rails. It tells them you have a vision and a rationale and end point with the design. It empowers you with more to control over the direction and outcome of the design.

2. The Promo and art of selling

One of the most important parts of getting a story across in wrestling is the promo. You can have an amazing story and amazing wrestling, but without the ability to connect to the audience, it’s useless. If you can’t make people buy into the story and believe it, you’ll go no where. How many times have we all seen great designs crushed. Part of our role when we go in and present, is to take ideas, protect them, bring life to them, and sell them. Get the design, the potential and the story across to the client. Being dynamic and connecting in presentations is just as critical as the design itself. Not only that, but you have to believe in what you’re selling. You have to buy into your own story, you can’t just fake your way through a great presentation.

The best wrestling promos are the ones that are extensions of personalities. It’s the same with presenting your designs. The best designs are the ones that are extensions of what you love. Why would a client buy into something if you can’t even believe it. You have to be excited and enjoy what you do, because if you don’t, why would other people?

I can never stress how important it is to be a great presenter, and be “on” each time you’re in front of a client, no matter how simple the presentation may be. It’s something I see a lot of designers drop the ball on because they see the designs as selling themselves. The bad news is most often, they don’t.

3. The Patterns and spots

After watching wrestling for 20 years, and training (yes, I trained) for a few years, you learn there are patterns and spots. To simplify, patterns are common elements and spots are usually predefined moves that wrestlers have worked out before the match. Patterns are used to develop the way matches are put together.  Spots often represent a high point in a match to get the crowd moving.

Both regular patterns, and the ability to break patterns when needed are critical in great matches. In our design world, we hear about patterns non-stop. Desktop patterns, mobile patterns, gesture patterns… and we stick to those. We’ve heard presentations and read articles on those. Then we see new designs that come along and twist them or break them and create a new pattern. Or create a one-off for their design; but it works. We can’t always be a slave to patterns or we just end up the same as everyone else, but using them is what makes it comfortable and soothing. Just remember that sometimes we need to throw things out and say “what are we going to do for this to support our story, our goals, and how do we make people fall in love with this”. Don’t be afraid to change even the most common elements.

A spot, by contrast, a more of a signature element. A unique piece that brings the design together. You have the story, you’re presenting it, and now it’s time to pull out the piece that people cheer for. Most wrestlers have spots they perform exclusively. These are their signature moves, and out of respect, other wrestlers don’t do them. In the design world. This is like the animated control on the Path mobile application, or the genie window effect on a Mac. Moments that those designs are known for. In each story, and subsequent design you create, what are your signature elements? What are the moments that people see in your design that they connect to emotionally. That they do a little cheer for when it happens and they tell other people about about. Don’t have any? I’d recommend thinking a little more.

In closing, when you need inspiration for design, it’s not always looking at Apple or the obviously products that are there. Look for the non-obvious sources and what they can teach you. Pull from everything and bring something no one else has to the table.

I have played on many sports teams, some good, some not so good. Early on I learned some very important lessons regarding my team. I learned that in order to stay progressive I needed to look internally for the external growth I wanted. I also learned that in order to stay positive, I needed to remember why I was playing that sport to begin with, remember the goals I had set for myself in that sport, and always stay focused on meeting those goals. Sounds selfish? Well… it is.

However, once I started to do this I realized that several things happened. First, because I was no longer focused negatively on my team, I was able to be more at peace with my situation. I couldn’t change the team, I could only change me. My new found focus allowed me to stay positive, as well as to progress into a better athlete.

Second, my team did become more progressive overall due to the increase in my progress. Sure it wasn’t the ideal state, but it was much better than we had been before.

Thus, next time you are on a project team such as this and unable to escape, move your energy inward and focus on how to get better despite the circumstances. You’ll be surprised just how much better things will get.

This presented a slight problem, as I’m all about collaboration. I am CTO at Site9, and our product, ProtoShare, is built on the premise that collaboration is a powerful process that will revolutionize your UX, design and development experiences.

And as I read the article, I found myself agreeing with much of it. Who hasn’t had the experience of seeing their ideas butchered by a committee? ( See ‘Why Design by Commitee Should Die‘ and ‘Team Collaboration: Identifying the Warning Signs of Failure & Getting to Success‘)

Brainstorming, in particular, is singled out in the article, and for good reason. The author states: “People in groups tend to sit back and let others do the work; they instinctively mimic others’ opinions and lose sight of their own; and, often succumb to peer pressure.” I really agree with these statements. This is why meetings can be so unproductive or worse. ( See also ‘Meetings Where Work Goes to Die‘ and ‘Making Meetings Productive‘).

Another point in the article I completely agree with is that privacy and solitude improve creativity and productivity. I love working alone. Some of my most inspired moments come from ruminating, researching, experimenting and working alone.

I believe in collaborative methods

And yet, I’m still a strident advocate for collaborative methods. I see collaboration as an incredible breakthrough that radically increases productivity. The first time I used a Google Doc spreadsheet, I thought “Here is a somewhat clunky, slower, less powerful version of Excel. But I love it!” Why did I love it? Because I could invite the board chairman in to look at and work on the spreadsheet. I could send it to all my board members and executives when I was finished to get their feedback, all in one place.

So I love collaboration. The key difference is what kind of collaboration. Sometimes I want to collaborate because I’m feeling lazy and I want someone else to do the work. “Brainstorming,” defined as: get a bunch of people in a room to spit out the first thing that comes to mind, might count as collaboration, but its not where you’ll get your massive productivity gains. My version of collaboration does not result in the collaborators getting out of the hard work of thinking, stewing, experimenting and generally making an effort. If you know anything about diffusion of responsibility, you’ll understand why collaboration can have negative effects.

So what do I mean by collaboration? To me it means getting other people to look at, understand and engage with what I’ve done (or engage with something someone else has done). When I’ve written a draft, come up with a solution or solved a problem, that’s when I want to harness the power of collaboration. “Here’s my idea — what am I missing?” People have an amazing ability to see issues that I missed, or even ignored, and to force me back to look at my work with fresh eyes. And what’s more, when I propose something concrete, the people giving feedback are more engaged and creative. That’s why collaborative prototyping is such a powerful means of collaboration. By definition I am presenting something visual and concrete. It’s easy for a huge range of stakeholders to engage with a prototype.

The beginning is important

I tell everyone presenting ideas in meetings to start with: “Here is what I am proposing and why I think it will work,” and then to ask for feedback. Compare this to going into a meeting saying: “I want to accomplish X. Does anyone have any ideas on how we could do this?” For me, the difference is stark. When I present a concrete solution, people get engaged. They can quickly sense the contours of the problem. They pick up subtle information based on my approach and reasoning. And they will see things that I missed.

One example of this, something that happened to me a few weeks ago, involved a product feature that had been on our roadmap for a long time. The implementation path was unclear. The feature had the potential to spiral out of control into an endless list of features. I’d done some thinking, and I thought that I had a strategy for an easy-to-implement, lightweight solution that would provide at least some progress toward solving the underlying problem.

I created a prototype to illustrate these ideas, and I presented them to the CEO and the engineers in charge of implementing a solution. There was pushback. (Have you ever had a conversation with engineers without pushback?) The solution wasn’t complete enough. It didn’t satisfy this use case or that use case. Yes, I said, but my solution is doable. It accomplishes objective A, even if it doesn’t solve B, C and D. It gets us moving toward a solution.

The meeting concluded that the engineers would spend a little time thinking about my solution and possible modifications. I would complete the task of fleshing out the user stories and prototypes so that my idea would be concrete enough to develop.

So…progress made, right? I didn’t love my solution, but it made progress. It was the best I could come up with, and it was a solid idea.

The next day, one of the engineers approached me to discuss the issue. He’d taken my idea, and it had spurred him to think of a slightly modified approach. It would require a small amount of engineering, but it would get us B, C and D. In addition, the benefit of this small shift would also spill over into several other areas of the application as well as open many interesting future possibilities. In short, his idea was perfect and brilliant.

Would either of us have gotten there on our own? I doubt that I would have. He might have, but the fact that I did some hard work and private thinking provided a scaffolding for him to use to complete his ideas.

This is the power of collaboration that I see over and over again. An individual makes the effort to solve a problem. This is a private process. The results are concrete. This is why collaborative prototyping is so powerful, in my opinion. The prototype makes the ideas concrete. This gets your stakeholders more engaged and requires more structured thinking and effort on the part of the individual before collaboration happens.

Brainstorming is great too

In fact, I think brainstorming is a great idea too. But not brainstorming as in getting people together to contemplate a solution to a novel question. For me brainstorming means: “I know you’ve all thought a lot about this particular issue. I want you to share your ideas in a nonjudgmental setting.” It’s the preparation that matters. When people collaborate on ideas that they care about, that they’ve spent mental energy contemplating, and that they understand, the results are phenomenal.

I did some research for an article about creativity. Part of the research was looking at models that academics use to model creativity. One thing they all had in common: preparation. You have to plow the field before you plant. The term we use is engagement: have I spent time understanding the issues? And I will state, unequivocally, that engagement is something only an individual can do.

UX is all about communication

Collaboration in UX is more important than in other fields. Why? UX is all about communication. The dangers of insular thinking in UX are that other people can’t relate to our ideas, even if they are good. When people say “an engineer designed this,” it’s not because engineers are stupid or haven’t thought the problem through. It’s because their values (consistency, supportability, development costs) are not the same as the values of the user (easy, intuitive, powerful).

Another feature of UX design is that I’m almost always working on solving someone else’s problem. When we build software, it has to satisfy the customers’ needs and wants. If I don’t bring them in on it, I can spin off endlessly. Feedback allows me to make course corrections instead of starting over. If I’m implementing someone else’s vision, I still need to work in solitude, but collaboration becomes even more vital.

The aforementioned New York Times article does say the following about electronic collaboration: “The one important exception to this dismal record is electronic brainstorming, where large groups outperform individuals; and the larger the group the better. The protection of the screen mitigates many problems of group work.” I agree with the point that the screen shields individuals from some of the drawbacks of social behaviors. But I also think that most internet collaboration requires an individual to be the driver (at least initially), to do the hard creative work that gets the ball rolling. Collaboration allows you to pass the baton between players, cross-pollinate ideas, stimulate thinking and get multiple points of view. Still, progress is made by individuals. Individual progress is improved with collaboration by engaged stakeholders at the right times. (See ‘Lean UX: Getting Out of the Deliverables Business‘ and ‘Our Blind Spot: Creating a Shared Vision‘.)

Mobile websites and applications (apps) give travelers immediate access to:

• All of the content available on the Internet.
• Data and content that our phones can sense about the local environment.

Mobile apps, in particular, are turning confused tourists into knowledgeable “instant-locals,” providing content on the fly for decisions about where to stay, what to eat, and what to do.

That sounds great, right? Well, as somebody who oversees mobile apps for a global, multibrand hotel company, I can tell you that making sense out of all this content and data is HARD. I have overseen the design and delivery for mobile apps that have been downloaded more than 800,000 times across 6 different continents in 5 different languages and generated hundreds of millions of dollars in gross revenue. For any app, I can testify that the most difficult decision we face is: What content we should present to the user? We could potentially give users an incredible array of content about our hotels and the users’ stay. To make matters worse, on mobile phones we have the constraints of an impossibly small screen and lots of competing real-world distractions. Imagine a train or subway passenger trying to figure out whether a satisfactory hotel is available at the next stop. She needs our content to be easy to access and relevant to her decision.

So, how do we avoid overloading our mobile-wielding customers with content? How do we decide what content is most relevant, especially when a customer is using a mobile phone? That’s where situational awareness comes into play.

Introducing Situational Awareness

Situational Awareness is a field of research within cognitive science that Dr. Mica Endsley defines as “the perception of elements in the environment within a volume of time and space, the comprehension of their meaning, and the projection of their status in the near future,” (Endsley, 1995). In short, situational awareness is knowing what is going on around a user and what is most important to the user’s current goals.

You can imagine how handy this research would be for helping airline pilots, nuclear plant operators and emergency responders. These people regularly face more content and data than our limited human cognitive abilities can process and can quickly succumb to information overload. If not addressed, the result can be a wrong decision or even the inability to make a decision at all–and then disaster. Today, travelers looking for a hotel room in an unfamiliar city are at risk for being inundated with content so that it hinders, not helps, their decisions. So, I decided to apply research from situational awareness to travelers who are in need of hotel rooms. If we can provide our travelers with the highest level of situational awareness, then they can confidently make good decisions.

You may never need to define the content structure for a hotel-finding app, but Situational Awareness can help you define a content structure anytime you are building a mobile app to help your users make a decision or accomplish a goal.  Now, lets look at how you can structure and aggregate content to build Situational Awareness for users.

Understanding the Levels of Situational Awareness

Users can become aware of their context, or situation, at three levels. Each level builds on the previous one. Let’s walk through each of these levels and use finding a hotel as an example.

Level 1: Perception

At this level, a user might know where they currently are and where a hotel is. The user knows the basic facts but still doesn’t have a good picture of how long it will take them to get to the hotel. A study of airline pilots showed that 76% of Situation Awareness-related errors could be traced to the lack of this level of basic information (Jones and Endsley, 1996).

Level 2: Comprehension

At this level, users will comprehend how long it will take them to get to the hotel based on how far away they are from the hotel and what their transportation options are.

Level 3: Projection

At this level, a user can leverage information to make a prediction about how long it will take them to get the hotel at some future date. For example, they may know if they go to Boston during St. Patrick’s day and they have to cross a parade route then it is going to take longer.

You can see how these levels progressively build on each other. To project how long it will take a traveler to get to a hotel, there are multiple things that they must comprehend, including how far away the hotel is. To comprehend how far away a hotel is, they must know several basic facts about their location and the location of the hotel.

The higher the level of situational awareness that our users can achieve through the content we present to them, the easier it will be for them to quickly make confident decisions to accomplish their goals.

To understand HOW our pieces of content build on each other, we must visualize their hierarchical relationship. Fortunately, we have a tool to do just that.

Visualizing Situational Awareness with a Goal-Directed Task Analysis

We can tie all of this content and data together into a Goal-Directed Task Analysis (GDTA), a powerful artifact to visualize and measure situational awareness. I know what you’re thinking. User task flow analysis is nothing new. Why is GDTA different? GDTA helps you plan displaying the right content at the right time for the right situational awareness. GDTA maps the best way to combine content and data to help users comprehend quickly–and then make a decision.

What’s the first step in constructing a GDTA? Map the goals of our users and the decisions that our users must make to accomplish those goals. See Figure 1 as an example. (Note that this is just a mapping of a demonstrative subset and not a complete mapping of all potential goals.)

Fig 1. Goal and Decision Structure for Travelers, Partial Segment

The next step? Build a hierarchy of content that users will need to achieve maximum levels of situational awareness to make those decisions. See Figure 2 for a hierarchy of content for the decision “Is the hotel in a good location for me?”

Fig 2. Content Hierarchy for a Decision

Now that we have a hierarchy of content created in our GDTA, we can use it to ensure that we are presenting content to our users that will provide them with maximum situational awareness.

Tips for Applying Situational Awareness to a Mobile Phone Application

I have used GDTAs over the past six years to inform the content strategy for mobile websites, native smartphone apps, native tablet apps and tools designed to be used in the field by the US Army. With all this experience under my belt, I want to share some practical tips for applying the tenets of situational awareness to a GDTA and, ultimately, to a content strategy.

1. One Goal = One Screen
   Don’t make users dig through multiple places in the app to gather all the content they need for a single decision.  All key content for a decision should be shown on the same screen. For example, in all of the hotel details pages that I plan, I always include those key indicators for allowing a user to accomplish the goal of picking a hotel that is right for them: price, distance, photos and amenities.

2. Machines Should Consolidate Content, Humans Should Make Decisions
   The thing that I have found most useful about the GDTA is it keeps me focused on consolidating content into a unit of information that gives users at-a-glance situational awareness. It’s the only way to help users focus on making decisions and not waste their time trying to make sense out of the content. The higher level of situational awareness that we can achieve through a technical solution, then the better we will be able to aid the user. For example, consider the content piece “Projected time to get to to the hotel.” I would present the user with a single message: “It will take you 33 minutes to get to the hotel from the airport on the day your flight lands”. And the bonus? This “rolled-up” content provides not only provides maximum situational awareness, it is also ideal for a small screen.Unfortunately, an accurate system projection of this complexity is rare. I have yet to come across a technical system that can calculate this timing projection with any degree of accuracy. That would be borderline artificial intelligence. So, barring that, I try to present Level 2 pieces of data together so that users can more easily make the jump from Level 2 Situational Awareness provided by the content we have available to Level 3 Situational Awareness by applying human intelligence. In this case, I would display the distance to the hotel as well as basic traffic advisories.
3. Let Users Drill-down for If They Need More Confidence
   Users tend to have a lower level of confidence in a system’s Level 3 projections, so it is a best practice to let users drill down to see the underlying Level 2 and Level 1 content. Following our “time to the hotel” example, I would let the user tap on the system-projected time and give them a pop-up message with the Level 2 content presented:

• the hotel is 10 miles away by car.
• traffic is heavy.
• there are currently no special events.

If the Level 3 projections are accurate, then users will learn to trust them over time and not be as reliant on Level 2 content.

4. Prompt Users to Revisit Decisions Based on Changing Conditions
   Conditions will constantly be changing in an environment as dynamic as a large city with lots of hotels, so travelers may need to re-evaluate their hotel decisions based on certain critical triggers. For example, if there is heavy traffic congestion then a traveler may want to revisit their hotel decision and pick a new hotel that they can get to more quickly. Mobile apps are great, because they allow us to send out these critical real-time alerts and warnings through push notifications.
5. Be Aware of In-App Content vs. Environmental Content
   I always try to remember that we can’t present every bit of content or information to travelers in our apps. So, as I go through the content from the GDTA I try to think “Is this content they could easily get from their surrounding environment?” For example, we don’t include natural disaster information within our app, unless the disaster affects our hotels. It is relevant to users’ decisions, but users can perceive natural disasters easily from their surrounding environment. If a traveler is stranded because of a snowstorm, then he or she knows it is going to take longer to get to their hotel. However, if the hotel that the traveler is trying to reach is closed or damaged, we should notify the traveler.

The Bottom Line

Situational Awareness gives us a research-proven method and model for making sense out of the flood of real-time content that travelers access thanks to mobile devices. The GDTA gives us a powerful artifact that visualizes how we should structure content to make travelers fully aware of their situation–and quickly. I find GDTA tremendously helpful for deciding what content we need to gather and present to users. The GDTA also informs technical and design decisions to consolidate and present content so that users can accomplish their goals. I focused on travelers and hotel-finding in mobile apps here, but the problems of information overload on a mobile device are coming to life in almost every industry and domain. Fortunately, we don’t have to re-invent the wheel because GDTA is a robust model ready to help us.

What you already know

A persona is a character who represents a certain segment of the people you potentially support. The segment could be a marketing segment, focused on how people buy your services. The segment could be a behavioral segment, drawn from hours of generative interviews and analysis. Or it could be a segment from another way of looking at people which is important to your organization–perhaps hair type, if you are a hair salon. There are lots of ways to segment people.

What you are wondering about

You also know there are different scopes that your organization attempts to cover. If you build, sell, and maintain data management products and consulting services, your scopes might include “get the word out to people who don’t know about us,” “help developers resolve tricky situations using our code,” “teach new developers how to use our code,” “support our own engineers keeping up to date with techniques,” “convince customers to upgrade to our latest version,” etc. You realize, with slight doubt, that there could be several personas for each of these scopes. Let’s count just the ideas I’ve mentioned: five scopes, and say there are three or four personas per scope. Does that mean there can be 15 to 20 different personas?? This possibility is daunting. Its seems like it’s too much to wield adroitly to imagine scenarios and invent customized tools as support.

How to get your head around it

Each scope, if they are defined narrowly enough, usually results in three or four behavioral segments. Each scope also usually results in one mental model, but sometimes there is one behavioral segment that is different enough that I split the data into two mental models, one representing that segment. Once, the data got split into three mental models, but I think that was more because we had defined too broad a scope to begin with, and narrowed it into three scopes when we divided the data. These three mental models all shared the same three behavioral segments, to different degrees. This is the point I want to make. Just because each scope has its own set of personas doesn’t mean that some of those characters can’t be the same across scopes.

There, now that I’ve said that, it all makes sense. You can have one master list of characters, just like in a television show. Some of those characters appear in every episode of the show. Some only appear in one episode. If you imagine each episode as a scope in your research, you  have a perfect analogy.

But wait a minute. I just switched from saying “behavioral segment” to saying “persona” or “character.” You caught that. True. They are not one-to-one, necessarily. You might want to make a couple of personas to represent different demographic or purchasing aspects of the behavioral segment. You might have a behavioral segment that is unhappy about taking business trips. One character representing this segment might be a mother who is focused on spending as much time as she can with her toddlers while they are pre-schoolers. Usually travels in the cheapest seat her company can buy. Another character of this same behavioral group might be a businesswoman who has spent so many years traveling every other week that she is tired of hotels and just wants to be home in her own bed more often. She usually travels in business class and enjoys boarding priority. A third character in this group could be a younger woman with a fear of flying. Perhaps she only buys one ticket a year. Each persona you create is a character, like in a television show. Each persona has a first name. A few of the personas could represent the same behavioral segment, just like a few of the characters in a show might represent the same motivations. I can think of one example: the companions of Doctor Who, over the years, all represent the motivation to pursue excitement, see amazing things, and be near a person whom they love and revere. That is one behavioral segment with several different characters in it.

As you collect more research over the years and explore more scopes, you will add to your cast of characters. Sometimes you will discover the same behavioral segment in a new scope and decide to keep the character(s) you already defined for it. Sometimes you will decide it will illuminate a business problem better to invent a new character within that same behavioral segment. Keep track of these characters over time, the business problem they clarify, the behavioral segment they belong to, and the scopes they are active in.

Having to know and stay up to date on this much information is the reason that many of us don’t get much sleep at night. But, there is a secret that many of us don’t know that could save us all a ton of angst.

That secret: the fundamentals of UX Design don’t change. As long as you know them, you can solve any problem, at any time, no matter how up to date you are with the latest trends and methods.

For example, like UX, in sports the fundamentals don’t change. In basketball, one needs to know how to dribble, shoot, rebound, and more. Once an athlete knows these skills, they can basically play the sport of basketball no matter where they are, who their opponent is, and how many people are on the court (thus solving any basketball problem at anytime). Of course, from this state they can also learn how to run plays, play more intricate defense and more, but knowing the fundamentals of the sport is what propels them forward.

UX is no different. Once we know the basics, and know them well, we are able to approach any problem and outline a solution. It is during this outlining time that we are using our fundamentals to highlight gaps in information that we need to fill in order to come up with a full solution. We can then go back and research which knowledge and methods we need to fill the gaps in information that we found.

That is the secret to ensuring you are always up to date, knowing the fundamentals of the UX game. This allows us to frame the solution of any problem, and saves us from having to know every in-depth methodology out there. So, take time to learn the basics inside and out, and trust me… you will get a lot more sleep at night.