the big persona > site personas and the dialogue process

24 Jan 2005 - 2:47pm
9 years ago
4 replies
632 reads
Ben Hunt
2004

To me, the single biggest risk is surely: restricting your choices by
designing within your Big User's boundaries.

If you design for her, as an individual, do you risk making decisions
based on her existing practices, preferences, prejudices and taste,
instead of the glorious What Could Be? Personas let us make design
decisions based on real facts, while at the same time thinking beyond
discrete instances. This is crucial to join up the solid 'grounded'
foundations and the lofty celestial possibilities.

I'm interested in your suggestion of using two personas: one user, and
one stakeholder. Does this mean the stakeholder gets to be a user?
Clasically, personas are always end-users of the software, although we
use something we've been calling the "Site Persona" ('site' because it's
UxD for the web).

Here's a brief introduction:

Site Personas & the Dialogue Process
====================================

I've recently started using 'Site personas' in web site / application
design, using something I'm calling the 'Dialog(ue) process'.

I'm working out the process as I go, but here it is in rough:

1) Develop user personas.

2) Develop a site persona, which is a discrete personality (just like a
user persona), complete with name, goals, tone of voice, capabilities
and style. Note that the Site Persona's goals are derived from analysing
goals and success criteria for the application/project/client. However,
the SP embodies those goals. The SP may be modelled on a particular
professional, such as a counsellor, customer service representative,
trained facilitator, or hotel concierge.

I have a pet SP called Pierre, who's a concierge in a high-class hotel.
There are several aspects of Pierre's style that I find really useful in
designing web sites, including:
- His brevity: he only communicates the minimum information required to
communicate what needs to be communicated.
- His low demand: he only asks for the minimum of input and information;
he makes up the rest through intelligence, memory, note-taking and
experience.
- His modesty: he doesn't draw glory to himself; his satisfaction comes
solely from helping his clients achieve their goals.
- His proactivity: he's always anticipating what customers may want next
- even before they've thought of it themselves.

3) Work through scenarios of use, from entry point to success point, by
literally playing out the dialogue between a Primary/User Persona and
the Site Persona. I actually type the dialogue elements into a script,
which is a 2-column table that enables the 2 personas to take turns.

The dialogue may be composed of:
a) Things that are actually on the screen (such as information the SP
gives to the UP, or options that the UP can click or handle to give an
instruction/request);
b) Summaries of what's on-screen, told in a dialogue style that matches
how it will be viewed
c) Mental monologue in the user persona's head

4) Review & refine, asking:
- How can the interaction be made more succinct?
- Can any dialogue be anticipated and avoided (site intelligence)?
- Is there any scope for confusion? How would the site persona help the
visitor make it through smoothly?
- What errors could possibly occur? How can the site persona best
respond, in a way that increases the visitor’s trust?

I'm finding this a really neat and elegant process, which has the added
benefits of generating starting-point copy and structuring interaction
elements in a syntactical order.

One simple example: A hotel customer has a question, and asks Pierre. If
Pierre doesn't have the answer straightaway, he makes sure he puts it to
someone who can answer it as quickly as possible, gets a response to the
client (if desired), and remembers the answer for future.

A web site analogy would be: UP has a query, and pulls up the FAQs/Q&A
page. There are just a few genuinely frequently asked questions on
there. They can't find their answer. Pierre wouldn't leave it at that,
and he wouldn't make the customer trawl through pages and pages of Q&A
to find it. So Pierre, representing the web site, takes the initiative.
On-screen, you'd get a form at the bottom of the FAQs, saying: "Did we
answer your question? If not, please let us know, and we'll get back to
you as soon as possible. If you would like an email in response, please
enter your email address." That's it, but the benefit is great. Not only
does it help the UP to continue towards a possible successful goal, but
is also helps the site to achieve its goals.

That's one of the great strengths of the dialogue process: working out
coherent ways of achieving a good balance between users' goals and the
software's goals. We're quite familiar to working out win-win solutions
through dialogue in real life, so designers already have skills to use
the dialogue process successfully. Because the site persona embodies the
goals that drive the software (there are *always* goals, and they're
just as important as users' goals, but often depend on them to succeed),
it gives a compact, memorable, identifiable way to act out interation so
that all goals can be met.

As I say, this is work in progress, but I'm getting good results in web
design at least.

- Ben

Comments

24 Jan 2005 - 5:22pm
Robert Reimann
2003

Ben Hunt wrote:

> Classically, personas are always end-users of the software, although we
> use something we've been calling the "Site Persona" ('site' because it's
> UxD for the web).

Actually, this isn't true about personas. About Face 2.0 discusses, albeit
briefly,
the idea of non-user / customer personas, which can represent other involved
parties such as IT managers, call center employees, etc., who have their own
set of goals which are typically quite different from those of end users.
Such non-user personas are very appropriate for information systems in which
the end user is not the purchaser, installer, or maintainer of the system
(each of which may require separate personas!).

I first heard of the idea of Site Personas at UC Berkeley some years back;
Sara Beckman at the Haas School of Business(!) was suggesting the use of
them
in a class of hers. It's a clever idea, but does run the risk of muddling
the concept of what a persona is and the methodology for arriving at them.

Websites (and any SW for that matter) *do* have behavior, but they don't
have *motivation*, which is what drives a more typical persona. It sounds
as though a large part of what you are describing below is really an
embodiment of proper site/program behaviors, much like those described
in Ch. 14 of AF 2 ("Making Software Considerate"). I would argue
that these traits should be common, however, to almost any SW application.

What remains are specific goals abstracted from stakeholders and other
non-users. But in order to prioritize these, especially vs. conflicting
end-user goals, doesn't it make more sense to attribute these goals to
"real" humans with real motivations, rather than to a faceless "Site"?
And how do you handle the case when stakeholders, customers, and users
all have somewhat conflicting goals?

Anyway, I don't want to sound too critical, as it sounds like it's working
well for you, but wanted to point out some possible limitations and
confusions
that might result. I completely agree that an analysis of the kind you
describe regarding program behavior needs to take place, it's simply a
question whether stretching the concept of personas to model program
behavior as well as human behavior is the best such approach.

Robert.

---

Robert Reimann
Manager, User Interface Design

Bose Corporation
The Mountain
Framingham, MA 01701

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesigners.
com] On Behalf Of Ben Hunt
Sent: Monday, January 24, 2005 3:48 PM
To: IxD
Subject: Re: [ID Discuss] the big persona > site personas and the
dialogueprocess

[Please voluntarily trim replies to include only relevant quoted material.]

To me, the single biggest risk is surely: restricting your choices by
designing within your Big User's boundaries.

If you design for her, as an individual, do you risk making decisions
based on her existing practices, preferences, prejudices and taste,
instead of the glorious What Could Be? Personas let us make design
decisions based on real facts, while at the same time thinking beyond
discrete instances. This is crucial to join up the solid 'grounded'
foundations and the lofty celestial possibilities.

I'm interested in your suggestion of using two personas: one user, and
one stakeholder. Does this mean the stakeholder gets to be a user?
Clasically, personas are always end-users of the software, although we
use something we've been calling the "Site Persona" ('site' because it's
UxD for the web).

Here's a brief introduction:

Site Personas & the Dialogue Process ====================================

I've recently started using 'Site personas' in web site / application
design, using something I'm calling the 'Dialog(ue) process'.

I'm working out the process as I go, but here it is in rough:

1) Develop user personas.

2) Develop a site persona, which is a discrete personality (just like a
user persona), complete with name, goals, tone of voice, capabilities
and style. Note that the Site Persona's goals are derived from analysing
goals and success criteria for the application/project/client. However,
the SP embodies those goals. The SP may be modelled on a particular
professional, such as a counsellor, customer service representative,
trained facilitator, or hotel concierge.

I have a pet SP called Pierre, who's a concierge in a high-class hotel.
There are several aspects of Pierre's style that I find really useful in
designing web sites, including:
- His brevity: he only communicates the minimum information required to
communicate what needs to be communicated.
- His low demand: he only asks for the minimum of input and information;
he makes up the rest through intelligence, memory, note-taking and
experience.
- His modesty: he doesn't draw glory to himself; his satisfaction comes
solely from helping his clients achieve their goals.
- His proactivity: he's always anticipating what customers may want next
- even before they've thought of it themselves.

3) Work through scenarios of use, from entry point to success point, by
literally playing out the dialogue between a Primary/User Persona and
the Site Persona. I actually type the dialogue elements into a script,
which is a 2-column table that enables the 2 personas to take turns.

The dialogue may be composed of:
a) Things that are actually on the screen (such as information the SP
gives to the UP, or options that the UP can click or handle to give an
instruction/request);
b) Summaries of what's on-screen, told in a dialogue style that matches
how it will be viewed
c) Mental monologue in the user persona's head

4) Review & refine, asking:
- How can the interaction be made more succinct?
- Can any dialogue be anticipated and avoided (site intelligence)?
- Is there any scope for confusion? How would the site persona help the
visitor make it through smoothly?
- What errors could possibly occur? How can the site persona best
respond, in a way that increases the visitor's trust?

I'm finding this a really neat and elegant process, which has the added
benefits of generating starting-point copy and structuring interaction
elements in a syntactical order.

One simple example: A hotel customer has a question, and asks Pierre. If
Pierre doesn't have the answer straightaway, he makes sure he puts it to
someone who can answer it as quickly as possible, gets a response to the
client (if desired), and remembers the answer for future.

A web site analogy would be: UP has a query, and pulls up the FAQs/Q&A
page. There are just a few genuinely frequently asked questions on
there. They can't find their answer. Pierre wouldn't leave it at that,
and he wouldn't make the customer trawl through pages and pages of Q&A
to find it. So Pierre, representing the web site, takes the initiative.
On-screen, you'd get a form at the bottom of the FAQs, saying: "Did we
answer your question? If not, please let us know, and we'll get back to
you as soon as possible. If you would like an email in response, please
enter your email address." That's it, but the benefit is great. Not only
does it help the UP to continue towards a possible successful goal, but
is also helps the site to achieve its goals.

That's one of the great strengths of the dialogue process: working out
coherent ways of achieving a good balance between users' goals and the
software's goals. We're quite familiar to working out win-win solutions
through dialogue in real life, so designers already have skills to use
the dialogue process successfully. Because the site persona embodies the
goals that drive the software (there are *always* goals, and they're
just as important as users' goals, but often depend on them to succeed),
it gives a compact, memorable, identifiable way to act out interation so
that all goals can be met.

As I say, this is work in progress, but I'm getting good results in web
design at least.

- Ben

_______________________________________________
Interaction Design Discussion List
discuss at ixdg.org
--
to change your options (unsubscribe or set digest): http://discuss.ixdg.org/
--
Questions: lists at ixdg.org
--
Announcement Online List (discussion list members get announcements already)
http://subscribe-announce.ixdg.org/
--
http://ixdg.org/

25 Jan 2005 - 5:07am
Ben Hunt
2004

Reimann, Robert wrote:

>Websites (and any SW for that matter) *do* have behavior, but they don't
>have *motivation*, which is what drives a more typical persona. It sounds
>as though a large part of what you are describing below is really an
>embodiment of proper site/program behaviors, much like those described
>in Ch. 14 of AF 2 ("Making Software Considerate"). I would argue
>that these traits should be common, however, to almost any SW application.
>
I'd disagree that software doesn't have motivation. It is designed to
achieve several purposes (real goals), and in the process it has to make
decisions. The logic behind those decisions is equivalent to motivation.
Yes, it's configured by a designer and a developer, but it's just as
real as a human motive.

>What remains are specific goals abstracted from stakeholders and other
>non-users. But in order to prioritize these, especially vs. conflicting
>end-user goals, doesn't it make more sense to attribute these goals to
>"real" humans with real motivations, rather than to a faceless "Site"?
>
>And how do you handle the case when stakeholders, customes, and users all have somewhat conflicting goals?
>
I think it makes more sense to combine the motives behind the
site/software into a single persona, for a few reasons:

1) There may be several stakeholders and other interested parties, but
there is only one site, which is the meeting place where the consumer's
and organisation's goals meet and get resolved.

Compromises need to be made, which is best achieved in a single-minded
way. A site persona is ideally placed to do this, because while it takes
responsibility for *all* the important goals, it also has the
responsibility for making the "most right" decisions that lead to the
best result. In this way, it's like a great CEO whose job it is to
deliver success at all costs. (The site persona's goal is always to
deliver the site's goals by enabling visitors to achieve theirs).

Having several personas who represent various stakeholders is more
realistic, but all it does is create a committee. How do you move
forward to the decision-making? You need a leader for that.

2) It's good for a site/product to act out a consistent, single
personality (brand). The site persona provides a mechanism for defining
what the brand experience should be up-front, and then expresses that
consistently in every element of every page.

3) A site isn't human. It can have super-human abilities, such as the
ability to gather data from huge diverse sources very quickly, endless
patience, massive computational power, limitless memory, and stays awake
24/7. To limit it to the attributes of a set of people doing jobs would
miss the opportunity to rise above the limits of human abilities.

- Ben

25 Jan 2005 - 9:39am
Robert Reimann
2003

Ben Hunt wrote:

> I'd disagree that software doesn't have motivation. It is designed to
> achieve several purposes (real goals), and in the process it has to make
> decisions. The logic behind those decisions is equivalent to motivation.
> Yes, it's configured by a designer and a developer, but it's just as
> real as a human motive.

We can split semantic hairs here, but in my book, humans have motivations,
and the logic of a program reflects the human motivations of its creators.
Ascribing motivations to constructs seems counterintuitive and problematic.
It's difficult to imagine a cell phone or coffeepot having motivations, yet
personas can certainly be used to design them.

> Having several personas who represent various stakeholders is more
> realistic, but all it does is create a committee. How do you move
> forward to the decision-making? You need a leader for that.

That is the role of the _designer_, to determine the solution
that provides a win-win situation for the business and the user.
This line of reasoning strikes me as somewhat worrisome, since
you have cast the thing you are designing as the arbiter of its
own design. At some point you need to draw the line back to the
stakeholders to show that their needs are being met, which is the
reason for having stakeholder personas. Perhaps my biggest concern
is that this method once again transfers focus away from the user
and her goals, and towards the software.

> It's good for a site/product to act out a consistent, single
> personality (brand). The site persona provides a mechanism for defining
> what the brand experience should be up-front, and then expresses that
> consistently in every element of every page.

I'm not a brand expert, but it seems to me that brand is more complex
than a set of personality attributes. That said, I can see how this
kind of exercise could help clarify some forms of brand messaging.

> A site isn't human. It can have super-human abilities, such as the
> ability to gather data from huge diverse sources very quickly, endless
> patience, massive computational power, limitless memory, and stays awake
> 24/7. To limit it to the attributes of a set of people doing jobs would
> miss the opportunity to rise above the limits of human abilities.

This is actually my point. A site isn't human, and therefore shouldn't
be modeled as one. From what you've described above, it sounds like you
might also be a little unclear on the use of non-user personas. They,
like user personas, have goals that need to be accomplished by the site:
these may be business goals, or goals surrounding installation, support,
etc. The attributes of non-user personas are their own; they don't
map to site behaviors directly. The mapping process is the work of the
designer.

The designer's task is to create a solution that completely
satisfies (or exceeds) the goals and expectations of the primary user
persona(s), while not dissatisfying the other user and non-user personas.
This is best accomplished through scenarios in which these goals are
tested against proposed design solutions, which is so far similar to
your "dialogue", but minus any personification of SW. In the case of
conflict,
goals can be prioritized based on importance to the user and business
personas.
In your model, this is done more implicitly, rather than explicitly as
described above. This can make it more difficult for stakeholders to
unravel the decision-making process behind the design, which can in turn
affect buy-in, and lead to requests to "change the site's personality",
which of course you can do, because it isn't, after all, an "actual" person.

Anyway, as I said before, this seems to be working well for you so far. But
you should also be aware of the potential "gotchas" with such an approach.

Robert.

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesigners.
com] On Behalf Of Ben Hunt
Sent: Tuesday, January 25, 2005 6:08 AM
To: "Reimann, Robert" <Robert_Reimann at bose.com>IxD
Cc: IxD
Subject: Re: [ID Discuss] the big persona > site personas and the
dialogueprocess

Reimann, Robert wrote:

>Websites (and any SW for that matter) *do* have behavior, but they
>don't
>have *motivation*, which is what drives a more typical persona. It sounds
>as though a large part of what you are describing below is really an
>embodiment of proper site/program behaviors, much like those described
>in Ch. 14 of AF 2 ("Making Software Considerate"). I would argue
>that these traits should be common, however, to almost any SW application.
>
I'd disagree that software doesn't have motivation. It is designed to
achieve several purposes (real goals), and in the process it has to make
decisions. The logic behind those decisions is equivalent to motivation.
Yes, it's configured by a designer and a developer, but it's just as
real as a human motive.

>What remains are specific goals abstracted from stakeholders and other
>non-users. But in order to prioritize these, especially vs.
>conflicting end-user goals, doesn't it make more sense to attribute
>these goals to "real" humans with real motivations, rather than to a
>faceless "Site"?
>
>And how do you handle the case when stakeholders, customes, and users
>all have somewhat conflicting goals?
>
I think it makes more sense to combine the motives behind the
site/software into a single persona, for a few reasons:

1) There may be several stakeholders and other interested parties, but
there is only one site, which is the meeting place where the consumer's
and organisation's goals meet and get resolved.

Compromises need to be made, which is best achieved in a single-minded
way. A site persona is ideally placed to do this, because while it takes
responsibility for *all* the important goals, it also has the
responsibility for making the "most right" decisions that lead to the
best result. In this way, it's like a great CEO whose job it is to
deliver success at all costs. (The site persona's goal is always to
deliver the site's goals by enabling visitors to achieve theirs).

Having several personas who represent various stakeholders is more
realistic, but all it does is create a committee. How do you move
forward to the decision-making? You need a leader for that.

2) It's good for a site/product to act out a consistent, single
personality (brand). The site persona provides a mechanism for defining
what the brand experience should be up-front, and then expresses that
consistently in every element of every page.

3) A site isn't human. It can have super-human abilities, such as the
ability to gather data from huge diverse sources very quickly, endless
patience, massive computational power, limitless memory, and stays awake
24/7. To limit it to the attributes of a set of people doing jobs would
miss the opportunity to rise above the limits of human abilities.

- Ben

25 Jan 2005 - 9:28pm
Will Tschumy
2004

Ben-

I think this is a great approach!

In reading a bit farther along in the thread, I know we've already
touched on the idea that the site persona is a proxy for the brand
attributes - this is a powerful tool, and allows UxD's to really take
their proper place at the strategy table - after all, if the product or
service doesn't support and inform the brand strategy, then one of you
is lying ;)

I've always thought of UxD as (among other things) the act of making a
brand real - particular for online businesses, the experience of a user
of a system impacts the perception of the brand far more than any other
communication touchpoint (advertising or whatever else). We used to
map this out in the Customer Acquisition Lifecycle at Scient.

When I've thought through the process of directly apply the brand
attributes as a characteristic of product design, I've run into an
issue of generality - everyone wants their application / site to be
helpful, Succinct, anticipatory, etc. That said, I wonder if a Site
Persona / Application Persona could be used to make expicit the design
choices that an organization has made. Have you thought about using
the Site Persona / Application Persona as a way to explain to non-UxD /
technical audiences what the impact is of technology / business
strategy choices?

thanks. Will.

On Jan 24, 2005, at 3:47 PM, Ben Hunt wrote:

> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> To me, the single biggest risk is surely: restricting your choices by
> designing within your Big User's boundaries.
>
> If you design for her, as an individual, do you risk making decisions
> based on her existing practices, preferences, prejudices and taste,
> instead of the glorious What Could Be? Personas let us make design
> decisions based on real facts, while at the same time thinking beyond
> discrete instances. This is crucial to join up the solid 'grounded'
> foundations and the lofty celestial possibilities.
>
> I'm interested in your suggestion of using two personas: one user, and
> one stakeholder. Does this mean the stakeholder gets to be a user?
> Clasically, personas are always end-users of the software, although we
> use something we've been calling the "Site Persona" ('site' because
> it's UxD for the web).
>
> Here's a brief introduction:
>
> Site Personas & the Dialogue Process
> ====================================
>
> I've recently started using 'Site personas' in web site / application
> design, using something I'm calling the 'Dialog(ue) process'.
>
> I'm working out the process as I go, but here it is in rough:
>
> 1) Develop user personas.
>
> 2) Develop a site persona, which is a discrete personality (just like
> a user persona), complete with name, goals, tone of voice,
> capabilities and style. Note that the Site Persona's goals are derived
> from analysing goals and success criteria for the
> application/project/client. However, the SP embodies those goals. The
> SP may be modelled on a particular professional, such as a counsellor,
> customer service representative, trained facilitator, or hotel
> concierge.
>
> I have a pet SP called Pierre, who's a concierge in a high-class
> hotel. There are several aspects of Pierre's style that I find really
> useful in designing web sites, including:
> - His brevity: he only communicates the minimum information required
> to communicate what needs to be communicated.
> - His low demand: he only asks for the minimum of input and
> information; he makes up the rest through intelligence, memory,
> note-taking and experience.
> - His modesty: he doesn't draw glory to himself; his satisfaction
> comes solely from helping his clients achieve their goals.
> - His proactivity: he's always anticipating what customers may want
> next - even before they've thought of it themselves.
>
> 3) Work through scenarios of use, from entry point to success point,
> by literally playing out the dialogue between a Primary/User Persona
> and the Site Persona. I actually type the dialogue elements into a
> script, which is a 2-column table that enables the 2 personas to take
> turns.
>
> The dialogue may be composed of:
> a) Things that are actually on the screen (such as information the SP
> gives to the UP, or options that the UP can click or handle to give an
> instruction/request);
> b) Summaries of what's on-screen, told in a dialogue style that
> matches how it will be viewed
> c) Mental monologue in the user persona's head
>
> 4) Review & refine, asking:
> - How can the interaction be made more succinct?
> - Can any dialogue be anticipated and avoided (site intelligence)?
> - Is there any scope for confusion? How would the site persona help
> the visitor make it through smoothly?
> - What errors could possibly occur? How can the site persona best
> respond, in a way that increases the visitor’s trust?
>
> I'm finding this a really neat and elegant process, which has the
> added benefits of generating starting-point copy and structuring
> interaction elements in a syntactical order.
>
> One simple example: A hotel customer has a question, and asks Pierre.
> If Pierre doesn't have the answer straightaway, he makes sure he puts
> it to someone who can answer it as quickly as possible, gets a
> response to the client (if desired), and remembers the answer for
> future.
>
> A web site analogy would be: UP has a query, and pulls up the FAQs/Q&A
> page. There are just a few genuinely frequently asked questions on
> there. They can't find their answer. Pierre wouldn't leave it at that,
> and he wouldn't make the customer trawl through pages and pages of Q&A
> to find it. So Pierre, representing the web site, takes the
> initiative. On-screen, you'd get a form at the bottom of the FAQs,
> saying: "Did we answer your question? If not, please let us know, and
> we'll get back to you as soon as possible. If you would like an email
> in response, please enter your email address." That's it, but the
> benefit is great. Not only does it help the UP to continue towards a
> possible successful goal, but is also helps the site to achieve its
> goals.
>
> That's one of the great strengths of the dialogue process: working out
> coherent ways of achieving a good balance between users' goals and the
> software's goals. We're quite familiar to working out win-win
> solutions through dialogue in real life, so designers already have
> skills to use the dialogue process successfully. Because the site
> persona embodies the goals that drive the software (there are *always*
> goals, and they're just as important as users' goals, but often depend
> on them to succeed), it gives a compact, memorable, identifiable way
> to act out interation so that all goals can be met.
>
> As I say, this is work in progress, but I'm getting good results in
> web design at least.
>
> - Ben
>
>
> _______________________________________________
> Interaction Design Discussion List
> discuss at ixdg.org
> --
> to change your options (unsubscribe or set digest):
> http://discuss.ixdg.org/
> --
> Questions: lists at ixdg.org
> --
> Announcement Online List (discussion list members get announcements
> already)
> http://subscribe-announce.ixdg.org/
> --
> http://ixdg.org/
>
>
for wct01 at earthlink.net
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: PGP 8.0.3

mQGiBEAqjm0RBAD28/HeQhyPnGjop1etuJTIMKAqEA0bcqNRApTxIxk3H9JnjHnE
ZOcIbq85KFdvKe7E5SkApZKzDsnSVOc180eFwRiAGE3aYi/ueOpeSqpiKLHj0zo1
yOP3f1QwhWYU5S0fBfTaSOidjneeRLFQ+NB2phXP2AyZU97wlAdRMA2/KwCg/zfc
juDFvzeHhEjXRSQXKEqY4+sD+wdI9air24wi97y3QNyQitBsyts25O0yCqgU0iEh
y62baTyOxi1VEVxveUAJNTnK7GILzTICYBOrX5NpQgBmWAEpC15oSMWYHb2UyTZm
3NbVihhVuWkCcY1L8Ik5jehRb0JyB0Cvp3dsLNjJouiFu10iMkVqjGQKadjCpGUZ
Zo40BADiG8V0lWZym8yQ67/lN7x3urB6TpFPH6sUbxQZESQwPnMKCdDHWEEyuL2M
rr/yJwrK+7vsnkLP1fYNS7ajCfYeH7832vuU1nbUFkLvLCeXS5DtHozYr6/hwqNy
io+3ECzsLc559n77REjEEvFNyNVoZvLx5a56mQzKXmz+EmcGrbQlV2lsbGlhbSBU
c2NodW15IDx3Y3QwMUBlYXJ0aGxpbmsubmV0PokAVgQQEQIAFwUCQCqObQcLCQgH
AwIKAhkBBRsDAAAAAAoJEIutTxYy9L9NJkYAoJNVHv9YqLbDrQoVqV3cs0prPtxT
AJYiveL5DQcAkhqIl3YPtnAMTrRTuQINBEAqjm0QCAD2Qle3CH8IF3KiutapQvMF
6PlTETlPtvFuuUs4INoBp1ajFOmPQFXz0AfGy0OplK33TGSGSfgMg71l6RfUodNQ
+PVZX9x2Uk89PY3bzpnhV5JZzf24rnRPxfx2vIPFRzBhznzJZv8V+bv9kV7HAarT
W56NoKVyOtQa8L9GAFgr5fSI/VhOSdvNILSd5JEHNmszbDgNRR0PfIizHHxbLY72
88kjwEPwpVsYjY67VYy4XTjTNP18F1dDox0YbN4zISy1Kv884bEpQBgRjXyEpwpy
1obEAxnIByl6ypUM2Zafq9AKUJsCRtMIPWakXUGfnHy9iUsiGSa6q6Jew1XpMgs7
AAICB/0Zz7j3QcmHtW8Uo71oUYQE18EzvbPIRW57moNSMW8C7VnPZWVMtYBRITqG
A4uLBMxNrmel7ytgFBrFDnGv4JfojRuUXCtX7kXNytDk26l982/iK0y6taBSCdqt
wrEpIR9K3paRGZvshGeCsFKl0FO1RWYltfwFfsY3dg/21KXi4lBo2PteZOeg/YUU
TvJi4y6p2Iauxww59io4jnw7uQdXDNsJsXE4htb396Pfcumu6H+Mjb2kAFz6l+nl
Iv6g8xMWqfLOTb4mt3yHwM9J/S74wHmzbh6U8xPorfPOWhftDWWSEB+Tq8Q8YysT
46WdJjUPuPZRarId8z4rDn33Seq+iQBMBBgRAgAMBQJAKo5tBRsMAAAAAAoJEIut
TxYy9L9NiuYAn2onSerK0LhL5elUeYM7J7BGJcy9AJwN1mDqz2ri1aRXpNR4eB82
VPpDMQ==
=Cv53
-----END PGP PUBLIC KEY BLOCK-----

Syndicate content Get the feed