Jared Spool: Hello there. You have
dialed into yet another episode of the “Spoolcast.” I am Jared Spool.
I’m the guy in charge of these things, but today we have the real person
in charge of all things Awesome UX. We have Miss Kim Goodwin, who is
one my favoritest people in the world. This will be podcast number 751
with her and she is going to enlighten us about how we get scenarios to
work in our organizations.
Kim Goodwin: I’m well, Jared, especially after that fantastic introduction. How could I not feel pretty good?
Jared: That’s how I feel. That’s how I
feel. I’m putting together this conference. Every year I go out and I
find speakers who are talking about things that I’m most interested in. I
invite them, and your stuff always ends up on the top of the list
I’m putting them together, and I’m writing up the description of why I
have each session. As I’m writing it up I keep finding myself writing
the phrase “Get on the same page.” We have Bruce McCarthy talking about
production management, so it’s like, “Get on the same page with your
We have Jenn Lukas talking about creating a living style guide out of
CSS. It’s like, “Get on the same page with a living style guide.”
Nathan Curtis talking about design systems. “Get on the same page with
your teams through a great design system.”
Of course, scenarios help us get on the same page. The thing is that I
didn’t do this on purpose. I crafted the conference in terms of the
people I wanted to hear. It just occurred to me that everything I wanted
to hear about was about getting people on the same page.
This is because this is the thing that I deal with most when I’m
talking to the companies I’m working with. I was wondering if you’re
seeing this, too. Are you talking to people a lot about “How do we get
on the same page about what we’re doing?”
Kim: Very much so, Jared. That’s a huge
focus for everybody working in this space right now. I think 20 years
ago when your conference first started…
Jared: Yes, 20 years.
Kim: We were all trying to figure out
what our profession was. We were trying to figure out the techniques for
solving the design problems in the first place. Our message were just
starting to come together and certainly drawing from other fields, like
industrial design and HCI and other things.
But I don’t think we generally had coalesced a method. Where
nowadays, I feel most practitioners have had some contact with pretty
similar sets of methods in a pretty well understood way that we can
Now that that’s done, everybody’s focused on, “Wait, why are we still
not getting stuff done?” Ultimately, it all comes down to aligning the
organization around where you want to go.
Some of that’s about process. Some of that’s about skills. Some of it’s about culture,
but it all comes down to alignment.
Jared: Yeah, that’s exactly right. I’m
thinking about the first UI conferences that we did. We had sessions
every year about the basics of usability testing, for example, and the
basics of what we would now call “Interaction design.” Back then that
wasn’t what it was called, and the basics of these things.
Now this year we have a session that is still usability testing and
user research. But the way Erica Hall is going to deliver it, it’s about
coming to a shared understanding, getting to a common knowledge about
It’s the elements of that type of research that get everybody on that
same page. I think you’re right. We have moved past the basic tools.
Yet, we’re still struggling to produce great experiences all the way
So, it isn’t just having the tool in our hand that automatically
makes us instantly producing a great UX, just like buying the most
expensive blender does not make you a great cook. You have to know how
to use those tools in a great way.
Kim: Exactly. Alignment is honestly, not
even just alignment within a product team, it’s alignment across an
organization and especially as a user experience now might be partly
digital. It might be bricks and mortar retail. It might be on the phone.
It might be a thing you get in the mail. All of that is wrapped up into
the user experience.
You have to get even more people on the same page. Now that I think
about that, that’s probably another reason why, just in the last few
years, that need for cross-team, cross-silo, cross-functional focus is
probably bigger than ever.
Jared: Yeah. In a lot of organizations
it’s like that old phrase about, “The future is here. It’s just not
evenly distributed.” The knowledge of how to get to great designs is
here, but it’s not evenly distributed.
Kim: That’s true. It’s not even evenly
distributed within an organization. Generally, I find that in a given
organization there’s one team that’s maybe doing really sophisticated
Where other parts of the organization, especially when they’re
internally focus groups like the IT group, often maybe lags behind the
product group, because it wasn’t that a customer facing driver for them,
Jared: In this world where we’re now
putting together multi disciplinary teams, do you think that means that
in a given team, there’s going to be a distribution of knowledge of what
it takes and just getting that entire team to have a shared
understanding and being on the same page takes work? It doesn’t just
Kim: Certainly, within that team you
want a distribution of skill sets because that’s why we’re multi
disciplinary in the first place.
Where I find those teams often begin to struggle is because they
don’t have a sure understanding even of the problem they’re trying to
solve, they don’t have a shared language or a shared perspective on what
it is the solution needs to accomplish in the first place.
It feels like requirements and even Agile user story, I think don’t
really make it clear for teams. So, in my experience the first step is
to come together around a tool that helps everybody see the problem from
the same angle.
Jared: You’re absolutely right about
that. Let’s hone in on the role scenarios play there. It feels to me
like they play a really critical role in helping that team and the parts
of the organization that has to interface with that team, interact.
Kim: If I can rewind a little bit and
look at something that you want to do, ideally is a precursor to
scenarios, journey maps do a better job of aligning people around the
problem, to prepare them to develop scenarios of the future solution.
Some time ago when I first started teaching scenarios, which is
probably more years than I care to count, I would find some people took
to it naturally and others really struggled with the generative aspect
of scenarios and didn’t quite know where to go with them.
When I started teaching journey mapping, which essentially takes your
user research and lays it out in a timeline fashion. Imagine that you
are outlining this person’s encounter with your tools and with other
tools in some way and then you’re mapping that versus, “How do they feel
about this? What are they trying to accomplish? What are they trying to
learn at each stage of this journey?”
That’s a structure that starts to really open people’s eyes around,
“Oh, boy, this stage in our journey is really awful.” Actually, we do OK
here. People aren’t too stressed about this.
That’s first to align the team around, “Where should we focus our
energies?” because a whole user journey is usually quite large and
touches probably every part of your product and maybe other people’s
That’s a great starting point and it’s a good jumping off point for
generating a scenario that tells the future story of the product.
Jared: When putting the journey map
together, when you’re doing that, are people coming from the same place
when you’re doing that, or is this a tool that you gather around to
synthesize where everybody on the team is coming from?
Kim: You could do it either way. In my
experience journey map works best when you have people who have a shared
base of user research, rather than just discredited assumptions and
Ideally you pull together some qualitative research people have done
and you start to map that out. In my experience actually, that journey
mapping exercise tell people whether they’re good or bad at qualitative
research because you can’t do a journey map that means it’s a lousy
But if you want to use a journey map as a starting point when you
don’t have that shared context, that’s not a bad thing. Because part of
what it will probably reveal is that lack of shared context.
You can say, “OK, if you all think we understand our users, let’s sit
down and try to do our journey map together.” That’s actually going to
reveal the holes in the team’s knowledge and probably reinforce that
actually it is worth you going down and sitting down with at least a
handful of users in their actual context.
Jared: Being able to get that journey
map built, once you have it built, it feels to me that now it’s a really
useful tool to help people who weren’t involved in that research to
pick up and get up to speed quickly and tell those stories.
Kim: Yes. It’s a way to make that
tangible. It’s a way to express a lot of what you saw in those
interviews in a pretty compact and digestible way. Then from that
journey map you can start to get people thinking, “All right. Now let’s
imagine what that future experience is like.”
You begin to tell the story of if you had a magic black box that you
could put in people’s hands, what would happen? How would that story
unfold differently? That’s where you start to build, Jared,
understanding about the solution.
In a universe where you just have a bullet list of requirements or
you have some acceptance criteria detailed in an Agile user story, which
to my mind is not really a story per se.
Jared: You mean as an administrator, “I want to be able to log in” is not a story of my experience? [laughs]
Kim: Yeah, because there’s really no plot or character in that, is there?
Jared: No, no. You can see the authentication system as a villain. [laughs]
Kim: You want to log in, Jared? Tell me
all about that. What an exciting story. That’s the thing. Agile user
stories are good scoping tools.
They’re effective communication tools in many ways, but stories
they’re really not whereas a scenario says, “Imagine if we had the magic
new product or the improved functionality. Here’s how that would
unfold.” That starts to imply a whole host of requirements.
It’s a generative tool that helps product managers understand
requirements, helps designers influence those requirements, and helps
all the engineers start to get a picture of, “Oh, that’s going to have
to connect to this, and we’re going to have to build it this way.” It
starts to take shape very quickly that way when you’ve got a story to
Jared: This idea of being able to tell
stories seems to be a key piece of this “Getting people on the same
page.” Do you think this goes back to a basic human trait of just being
Are we just taking advantage of what thousands of years of evolution
and sitting around the camp fire teaching our children how to be good
humans has all been about and we’re just moving that into the process?
Kim: Yes, I do. I think storytelling has
to be our most natural form of communication as humans. It’s something
that we all learn to do at an early age. The beauty in that is through
storytelling. As children we’re generative.
We’re creative, which I think is a very critical part of the design
process because if we can’t be imaginative it’s hard to come up with a
future state that’s going to be more desirable. We absorb stories very
well. There’s very little cognitive barrier to absorbing a story.
We don’t have to process a whole lot because everybody from Dr. Seuss
and the star-bellied sneeches trained us to absorb the moral of the
story without really having to think about it much.
Jared: It’s interesting that we can use
that as our touchstone in terms of helping people get on the same page.
One of the things that I’ve always been attracted to your approach to
scenarios about is how it’s very much a human storytelling process. I
guess going from the journey maps to the scenarios is really just a
We’ve got this journey. We now have the scenario of what it is today,
and we can come up with an aspirational scenario of what we could do.
What’s neat is in any given story what I learned about storytelling is
it’s not just the details you include. It’s also the details you leave
out. Scenarios are interesting because of what we don’t say explicitly
Kim: Yes. First I think that we’re
trying to be as human as possible in the design process, so we come up
with the most human solutions. Why not turn to those tools that help us
think in that form? You’re right that we do leave certain things out.
What I see often when people use cases or more formal structured
tools is they’ll start talking about how we hit this database table or
this server does something or this part of the system behaves in this
way. Who cares?
Jared: Or we sell more cookies or we sell more hotel rooms.
Kim: Right. Who cares? Whereas if we
focus on what does this particular human being that we’re envisioning,
whether that’s a persona or some real user we interviewed that we’re
using as a center point of our story, when we think about that and we
just describe what they experience — what do they see and encounter — it
doesn’t matter how the back end does it.
It doesn’t matter if we buy that capability and plug it in. It
doesn’t matter if that’s built using OAuth. Whatever technology doesn’t
matter because we’re just getting at the gist of it. That helps keep
requirements at the right level because I see a lot of teams that will
do requirements that are actually lists of solutions instead of lists of
problems that must be solved.
The scenario focuses on, “This is the behavior we want to enable.”
Then from there we can figure out, “Oh. Well, there are three ways we
might enable that. Which is the best?”
Jared: That’s really interesting because
that’s very similar to something that…when I was talking to Bruce
McCarthy about his workshop, which is going to be on “How can
user-experience people work with product managers effectively,” we got
on the subject of something that separates a really good product manager
from folks who are trying but don’t quite get there.
One of the things that separates is that the people who are trying go
down that requirements route that you just talked about, but the people
who are really good at being a product manager back away from the
requirements. He has a word he calls themes.
Themes are the overarching problem that we are trying to solve, but
we’re not going to make a list of requirements that are the solution.
We’re going to talk about that we need to solve this problem. Maybe the
solution that comes to mind first is the one we’ll take, but maybe
there’s a better solution. We want to leave ourselves open to that.
When we talk about what the roadmap will be for the next three
releases, we’re not going to talk about specific functionality and
features. We’re going to talk about the themes we’re going to tackle in
each stop on the road map.
It feels to me that pairing scenarios up with those themes would make
them more human, more accessible to everybody, and more clear that this
is the problem we’re going to solve when we get to that part in the
road map, but we don’t necessarily know today what the right feature is.
We’re not going to commit to it. We’re going to commit to solving the
Kim: Yes. Better yet, Jared, in an Agile
world where a lot of people are focused on what they’re doing in the
next one or two sprints…
Jared: People use Agile?
Kim: They use AgileFall or something of that nature…
Jared: Yes. [laughs] They use something.
Kim: …but they call it Agile.
Jared: They call it Agile, right. OK.
Kim: Don’t call it anything but Agile.
In a world where people tend to be focused on the short term and the
every chunkable functionality, what a scenario does when you attach it
to one of those themes or whatever you want to call it is the first pass
at a scenario is deliberately timeline agnostic. What I mean by that is
it’s not going to focus on, “What’s the version one?” A scenario
initially says, “What do we really want that solution to be?”
Then we’re going to pair that scenario with some sketches — fast,
cheap, low-fidelity — but make it clear what we’re envisioning for the
solution. Speaking of getting people on the same page, nothing beats a
sketch paired with a scenario to do that.
From there you say, “OK, we all agree that this is the thing we’re
aiming at. Hmm, how long is it going to take us to get there or to get
80 percent of the way there?” because maybe from a product management
point of view that last 20 percent isn’t worth it.
Even so, in order to get there, we’re going to maybe come up with
some interim sketches and figure out, “All right. Well, maybe this is a
two-sprint project. Maybe this is a big, ambitious thing we’re going to
have to work toward over the course of the next year.”
That initial fast, cheap scenario puts all of the subsequent user
stories into context, so that everybody knows, “Ah, this is about
enabling that stuff that we’re going to have fully implemented six
months from now.”
Jared: That’s fascinating. I have this
image of a designer standing in front of a wall with a whole bunch of
sketches. They’re actually play-acting the scenario as they talk about
each sketch and walk through each sketch.
The scenario…it’s like those Bible stories that we all know the basic
plot to, yet we tell them over and over again, the Passover story, the
Easter story, Muhammad going to the mountain, or whatever the story is,
Luke discovering R2D2 and taking it Obi-Wan Kenobi, all those religious
We all know the basic story and we can tell that story over, and
over, and over again, but now we’re using the sketches almost as props
for how that journey will happen going from here out.
Kim: Scenarios can operate at a lot of
different levels. You can do very low-level scenarios that are about
iterating that thing in front of you that you’re going to ship in a
couple weeks. Scenarios also operate very well at the medium- to
long-term vision level.
I think you and I both have found in our work that organizations that
have a crisp longer-term vision of, “What is the thing we want to
build?” and it’s not just a bullet point in a mission statement, but
some concrete visualization of that thing, are more able to execute on
that. Scenarios really help you with that.
The best example of that I found is one that kind of stole from you. I
use it in my workshops from time to time, which is the “Apple Knowledge
Navigator” video. What was it, 30 years ago? Apple put together a kind
of hokey video that includes Siri, except Siri looks like Bill Nye the
It includes a clunky version of the iPad. It includes screen sharing
and a whole bunch of other stuff that honestly has only shown up in the
last 5 to 10 years. They’ve known for a long time roughly where they
were going, and that’s probably been a big part of why they’ve been able
Jared: Did you know that that video was part of a set?
Kim: No, I’d love to see the other one.
Jared: The only other one I’ve been able
to find is a version of it that involved a digital camera. Again, this
was years before anybody had digital cameras. It was 1987, and I don’t
think the first digital cameras showed up…Apple had one of the first
digital cameras in the mid-’90s, like ’94. Then the Kodak digital
cameras came out right after that.
All those were done by Hugh Dubberly. As far as we know, there were
four done. Two of them have survived, and the other two, nobody seems to
have any original footage of.
Kim: Definitely, for the folks on the podcast, I think that video is worth Googling and I’ll probably drag it out in my workshop.
Jared: Yeah, “Apple Knowledge Navigator” is how you find it.
Kim: It’s a great example of how putting
it in the form of a story and illustrating it in some concrete way
makes a huge difference in people’s ability to see, “Ah, that’s where
we’re going.” Every time a team that I work with is able to start doing
that, when you have a story and you have some sketches to go along with
it, it really reduces the confusion and the swirl about what a
If you have a requirement that’s just a bullet point, you can spin
back and forth about what that means and whether the requirement’s been
met for months.
Jared: It’s such a powerful way to get
everybody talking about solving the same problems. It’s still surprising
to me that we have to re-learn this lesson over and over again.
Kim: If I could wave my magic wand and
make design schools better at one thing, it would be at helping people
ask the right questions and better define the problem. I really think
that’s the thing that many teams struggle with the most.
Jared: It’s funny you say that. I do
have a magic wand over a design school, and the conversations that we’ve
been having at Center Centre, as we’ve been designing the curriculum,
is just that. It’s trying to push the emphasis less on finished product,
and more on the process that got you there, which means you have to be
able to tell the stories of why you did what you did and how you did
what you did.
Kim: That’s actually very important in
getting people on the same page. As a designer, you can come up with,
whether it’s a crude sketch or a beautifully polished artifact…if you
say, “Ta-dah! Here’s the solution,” you’re going to get all kinds of
pushback because people don’t know how you got there.
One of the great things about this progression from user research, to
journey maps, to scenarios, to story board, to finished sketches is,
“Wow, you can see how that evolved from the previous steps.” People can
follow you there, even if they aren’t folks who can immediately look at a
sketch and grasp, “Oh, yeah, that’s the solution.”
When you show them the logic behind it, what that says is, “Oh, this
isn’t the designer just coming up with something out of thin air.
There’s a reasoning behind this and there’s actually an argument for why
this design is good.”
Of course, you want to do usability testing and other things to help
you make sure that you’re on the right track. But, in terms of selling
that initial solution, you have a path that got you there that other
people can see.
Jared: I sit through meetings where
someone in a client is presenting a design they’ve come up with. They
just launch into the screens, say, “Well, this is the home page, and
this is the this page, and this is the that page.” They don’t talk about
More importantly, they don’t talk about how they got to this design
from the journey map or from the sketches. The audience is left to
reverse engineer that in their head. Of course, they all do it
differently. Then, there’s all this conversation that happens around
what they think the path was that got them there that turns out not to
match. All of this is sort of lost. It’s a struggle for a lot of folks.
The best representations I’ve ever been with, before we saw the
design, there was this statement of, “The research taught us this, and
so we learned that the customers are trying to get to this result, but
right now they get stuck here and here.” It only takes a minute to say
that, but they go back to that and make sure that everybody’s on the
Then they say, “And then we tried a bunch of designs.” In many cases,
in the best of presentations I’ve even seen, they actually show some of
the designs they threw out and talk a little bit about, “Well, we first
tried this, because it seemed like the obvious thing. But then we
realized it didn’t work for this case or it didn’t work for this reason.
“And so we then evolved it and we got to this thing, and now here’s
the design we ended up with. And let’s go back to that scenario. The
user’s going to start by telling us what they need, and then they’re
going to click on this, and that’s because we want to be able to give
them the right information,” and then boom, all the way through.
Kim: In addition to that, an effective presentation is specific about which user.
Every product in the world has more than one user. Regardless of
whether you are a fan of personas or not, you want to be specific about,
“Look, we’re talking about users like this kind of person or that kind
of person, and this is the one we’re focused on right now.”
When people inevitably say, “Oh, well why didn’t you design it this
way?” or, “I think it should have this feature,” or, “This whiz-bang
button, that’s my pet peeve as a stakeholder,” you can say, “Ah, yes,
but help me understand when this persona or this kind of user would do
that, because they actually don’t care.”
That way, you can take it out of the context of you, the designer,
have a different opinion form the CEO — which is an argument you’re
always going to lose — to you, somebody with access to information about
user behavior, can bring the conversation onto some neutral ground so
everybody sees, “OK, yeah. We’re using the same evaluation criteria
That tends to make those conversations go so much better.
Jared: It’s interesting. While you were
saying that, I was just thinking. Twenty years ago, when we started this
conference, the conversation was all about personas. We talked about
personas. Then scenarios were sort of this thing that dangled off the
persona. It’s interesting now that the conversation is all about
scenarios. When necessary, we bring the persona in to talk specifics
about the users.
As I thought that through while you were talking, it occurred to me
that, to this day, personas are still a little controversial. There are
still people who stand up and, for whatever reason, say, “Personas are a
dumb idea. We create stupid personas, then we design for them, and we
create bad designs.”
No one ever says anything like that about scenarios. I have yet to
see anybody say, “Oh, we should never use scenarios when we design.”
Kim: It’s funny because, to me, the
personas and scenarios are intertwined. If, for some reason, you’re
allergic to personas, I think you can do something similar by picking an
individual from your research who seemed to represent a behavior
pattern. Either way, you really need to do the analysis about the
behavior patterns, whether you give them fictitious names and faces or
There’s a lot of resistance to personas out there, mostly because
people get them wrong. If people have had an experience with badly done,
so-called personas, it tends to sour them on the tool. You get people
who over-do the fiction part, who just make stuff up and don’t really
use behavior patterns based on research.
Or, they focus on the creative writing aspect and worry about what the dog’s name is and everything else. Who cares?
Jared: The dog and the Hummer.
Kim: Yeah. The essence of the persona is
the behavior and the goals. If 95 percent of your persona details are
not drawn from the research, then, yeah, you’re doing yourself a real
Jared: Have I ever told you my favorite dog and Hummer story?
Kim: Oh, no. Please do.
Jared: One of the red flags that I see
in personas is when I get a persona description that’s got some clip art
person, almost always white. [laughs]
Kim: And smiling. Don’t forget smiling.
Jared: Yup, smiling person, happy
customer. They describe this thing in three paragraphs. They describe
who this customer is, but there’s at least two sentences that describe
their pets and what they drive.
Kim: Because somebody saw that on a checklist somewhere and decided it mattered.
Jared: It makes it personal, right? We
have the CEO, and he’s got a greyhound and drives a Hummer. We’ve got
the mom and she drives a Mini Cooper and she has an Irish setter, and
they say what the name is, too, “The Irish setter’s name is Butch and
the Greyhound’s name is Killer.”
A client says, “Hey, we’ve had another consulting firm. We worked
with them to create a set of personas. Do you want to review them?”
I said, “Yeah! I’d love to.” Sure enough, first persona I read,
there’s a dog and a Hummer. They’re both right there, and I’m like,
“Huh. OK.” This was a firm I had a lot of respect for, so I’m like,
“Wow, I can’t believe they went down that road.”
Then, as I got to learn more about the project, it turns out that the
project was for the Home and Garden Television Network HGTV. The thing
that these personas were for was a project search engine. The project
search engine would help you find the best plans and recipes for home
Kim: So your Hummer is relevant.
Jared: Here is the deal. After doing
their research, one of the things they found, and this surfaced in the
research, was that if you’re doing do-it-yourself home improvement
projects, the car you have actually dictates some of the materials you
can cart back and forth.
People who have pets have special needs with regards to pet-safe
materials. If you’re re-doing the bathroom floor, what happens if the
dog runs into the work, as it’s being done, and gets into the grout or
the chemicals as the flooring? Is it going to be a safe environment?
They were trying to incorporate in the personas the fact that some
people had pets, and some people and big cars and some people have small
cars. If you drive a Mini Cooper, it’s a different materials supply
than if you have a pick-up truck.
Kim: Some of these biographic details in
personas are totally legit. They’re meant to reinforce certain things.
For example, if I tell you, “This persona shops at Walmart and that
persona shops at Nordstrom,” that’s going to reinforce certain
characteristics about those personas, and that’s totally legitimate.
Jared: The rule of thumb, I’ve sort of
come to this, and you can tell me if you have a similar one, “Can I
point to a design decision that would be effected by that sentence in
Jared: If I can talk about, “Well,
people with small cars will need certain types of projects than people
with large cars, with huge payload capacity, will have different
requirements for the projects. Then, boom, it should go in the persona.
But, if I can’t talk to a specific design element from day one, then
maybe we should leave it out.
Does that work for you?
Kim: Yeah. That’s a fair criterion. One
thing you have to be a little bit careful about is it’s not always
purely interaction design decisions. Sometimes, it’s a visual design
decision or a copy tone decision. Sometimes it’s about the emotional
aspect of the design that part of the persona speaks to. It’s not purely
functional stuff, too.
If you’re just telling me, “It’s the dog, Henry. They went to college
here and they drive this car,” because you think in some formulaic way
that should be part of a persona, no. All that’s going to do is
undermine the credibility of the tool and make your team roll their eyes
and go, “What is this fictitious crap that the design team is getting
paid to make?”
Jared: Again, if you can’t tell the
story of how this came from the research and how it makes a difference
in the design, it gets in your way.
Jared: Wow. I always learn stuff when I
talk to you. It’s always a pleasure. I’m so excited that you’re coming
back this year for our 20th year to do this.
Kim: Twenty years, congratulations on that, by the way.
Jared: We’re just going to keep doing it until we get it right.
Kim: All right.
It’s pretty darn close to right, if you ask me.
Jared: Thank you.
Kim: I keep coming back, because it’s a really awesome event.
Jared: Thank you for that. We try really hard. We focus a lot on the design. It’s part of what we do.
Kim, thank you so much for talking with me today.
Kim: Always my pleasure Jared, thank you.
Jared: For all you who have been
listening, thank you so much for giving us your attention. If you enjoy
these podcasts, please take a moment, go the iTunes, click on the
appropriate number of stars, leave us a comment. That really helps us a
Thanks for listening and thanks very much for encouraging our behavior. We’ll talk to you next time. Take care.