Menu Search
Jump to the content X X
SmashingConf London Avatar

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf London, dedicated to all things web performance.

Designing For The Multifaceted User

Designing with users in mind is a tricky thing. Not only does it require of us a sound understanding of who our users are, but the actual act of translating what we know about them into a well-designed product is not always an obvious or easy path.

Currently, our user experience tools tend to focus on “who” users are. I believe this is a hangover from how we traditionally approached marketing and market research. A couple of years ago, I stumbled across a somewhat different method, which has proven useful in a few of my own projects. It has been particularly handy for building value propositions and for clarifying assumptions we make about our users’ behaviours. Most of all, I like how it helps with prioritizing product design decisions.

Further Reading on SmashingMag:

So, first, let me explain where I think our current toolset falls short, and then I’ll walk you through an example that uses this newer technique. By the end of this article, you should be ready to give it a try yourself.

We Are Multifaceted Link

Put yourself in the shoes of a user for a moment. Imagine that a friend has introduced you to a new Facebook group about a subject you both like. If you are the shy sort, like me, you would lurk around for a little while. Once you became more familiar with the group’s dynamics, you might gradually become bold enough to post a comment or share an appropriate link.

Imagine also, then, that you’ve stumbled upon a blog post on a topic that you care strongly about. Someone has posted a comment that you completely disagree with — I’ll wager that, if you’re fired up, you would post almost immediately, rather than take the time to absorb previous posts. You remain the same person, yet your reaction to something will depend on what it is and what is happening at the time. This is normal.

Acting differently according to circumstance and context is natural. Image source6.

What does this mean for us as designers? For me, it means that our deliverables right now are probably too prescriptive in their details about who the user is. We would probably do better to work towards a clearer understanding of the user’s varying contexts — contexts that would yield different behaviors and decisions.

In short, our current tools tend to focus on the person, not on predicting their reactions and, therefore, what we should effectively be designing for.

Personas, User Journeys, Mental Models? Link

Personas, when created properly based on research, distill what we know about a few key user profiles. They have many advantages, particularly in enabling a common language among stakeholders about who our users are. User journeys and experience maps show a potential path that a user can take through an application or website. They are great for understanding flows and for mapping user needs to functionality.

However, both of these tools, and others similarly derived, take on a depth-wise view of the user. User journeys can map out specifically what a user may do, too, but not take into account why they make certain decisions. With personas, you garner some degree of knowledge about users’ background contexts and activities, but they might contain more detail about particular user profiles than what you need to design app-wide features.

Consider what is actually involved in your typical design process. At any stage, your design needs to cater to different activity flows. As designers, we often have to collapse a complex range of user behaviors into quantifiable feature sets that could feasibly fit a product management schedule.

Between personas and user journeys, it would get unwieldy to explore and map these complex ranges of behavior in a way that wouldn’t give us a headache. The closest tool we have at our disposal is the mental model, with which you map out a user’s intentions and tasks. However, a generic use of mental models doesn’t always take different contexts into account at a glance.

The question remains, how can we better position a product or design an interface that maps onto users’ decision patterns when their behaviors and motivations span a spectrum?

Modelling User Groups Link

I finally found a semblance of the method I’d been looking for while gate-crashing a guest lecture by a friend and colleague, David Rollert7, a designer with extensive experience.

Holding a roomful of smart design-engineering students at his attention, David showcased a number of user experience tools that day, including a way to model groups of users. Using a dating website as an example, he explained how we can define key “dimensions” of customer groups (figures 1 and 2 below). This first step is not dissimilar to what we often already do when creating personas. The following diagrams are quoted from David’s slide deck, with his blessing.

Demographic dimensions for a dating service8
Figure 1. Demographic dimensions for a dating service.

Psychographic dimensions for a dating service9
Figure 2. Psychographic dimensions for a dating service.

This next step is where we start to look for patterns. Then, picking two of these dimensions, he showed an example of a 3 × 3 matrix where you could map someone’s immediate goal relative to the role they preferred to play (figure 3). In order to fill in the matrix, David asked the question, “What does each group need?”

Mapping target customers: what does each group need?10
Figure 3. Mapping target customers: What does each group need?

A similar technique of user modelling is mentioned in A Project Guide to UX Design11 by Russ Unger and Carolyn Chandler (chapter 6, page 90), but it barely spans a page. While emphasizing the need for real user research, this reference still aligns with what we’ve always done — grouping users according to who they are, rather than what the users want to do or what drives them.

I thought it was fascinating. Rather than asking the question of “who” these customer groups are, what if we were to ask different questions? Such as, “What do these groups of users want to do?” or “What do they need to know?” Over my next few projects, I started incorporating this technique into my own work with clients, and it has turned out to be a useful tool on many occasions.

Before getting much further, I want to point out that this method is not a deliverable. It is not something you just draw up and send over to your client or product manager for sign-off. It is a technique that is most effectively used in a workshop format with all stakeholders in the same room.

Exploring Our Assumptions About Users Link

“User” has become such a loaded word. We pile all our beliefs, interpretations and emotional baggage onto the word “user” and on what they would want. Having been on many teams, I’ve started to realize that it’s a common problem that not all stakeholders and team members understand the word “user” in the same way. This is why having a set of personas internally can help iron out the issue of language.

However, the problem with personas is that they place a particular user on a map discretely, but they are not necessarily the best high-level tool for looking at continuous spectrums of user contexts.

The matrix technique explores what we know and what we don’t know about our users by looking through the lens of contexts for their behaviors and motivations.

I’ve used this method to do the following:

  • to establish key audiences;
  • to understand or validate value propositions;
  • to help prioritize research areas and product features — to identify what we already know and where we lack data;
  • to pinpoint which features are vital.

It is essentially a structured brainstorming tool to make sense of user patterns. Best of all, it can be an easy way to unpack assumptions that each stakeholder is making about their users.

Step 1: Draw Your Matrix Link

In the many times I’ve since done this little thinking process with clients or workshop attendees, a 3 × 3 grid has worked best for me. This is probably because it gives enough variation without being too precise — thereby keeping us from getting analysis-paralysis.

A blank matrix.12
Figure 4. A blank matrix.

Step 2: Identify Important Axes Link

The next step is to identify how many of these different “selves” of our users can exist in this system we are designing for.

Let’s talk about the example of a potential social app for runners. It’s a straightforward offering with which local runners can post routes and visiting runners can find routes. We could imagine virtual competitive elements; a runner might have previously posted a time that you are trying to beat on the same route. Or you might just want a scenic run as a way to explore a new city’s environments.

What kinds of behavioural attributes can we come up with for runners who would likely use this app? I tend to think in terms of “opposing” attributes. You might end up with a list looking like this and the corresponding user stories:

  • explorative
    “I want a new way to experience this city through running.”
  • competitive
    “I like to race against someone else, or against myself.”
  • frequent
    “I run a lot, several times a week to every day.”
  • occasional
    “I run once a week or less.”

Your axes might then look like this:

curious engaged
social individual
explorative competitive
frequent occasional
visitor local

Depending on the project you are working on, you may or may not know something about the users you are talking about. The team with which we explored the idea of this social app belonged to a sports shoe company and consisted entirely of runners who travel fairly frequently to run marathons. They had also done studies previously and gotten some ideas of the spectrum of novice runners to advanced runners, and some insight into the kinds of people who use an existing Web app that they produced.

As you go through this exercise, keep in mind what you know about your users and what you are presuming. From the list above, choose two axes that most interest you or that you think are worth exploring. Choosing might be difficult if you are just starting with this method; in which case, the best thing to do is to dive in and see what happens. If it doesn’t work or if ideas don’t seem to flow, change your axes and keep going.

A blank matrix with a pair of key axes.13
Figure 5. A blank matrix with a pair of key axes.

Step 3: Identify Key Questions Link

I liken this step to a “magic 8 ball” process. Ask a question! I generally like, “What would these users want to do?” Or, even more simply, “What do they want?” The latter question would cover what users want to know and what they would want to do. You could also ask questions like, “How would they feel?” as a kind of emphatic exercise.

As you think up questions, keep a list handy. You’ll need it later.

In this example, let’s stick with “What can they do?” Or, from a user’s perspective, “What can I do with this app?”

A blank matrix with axes and question.14
Figure 6. A blank matrix with axes and a question.

Step 4: Fill It Up Link

Fill in the matrix as best you can. If you already have some insights from research, then mark which things you know for certain, as opposed to things you believe to be true but have nothing yet to back it up.

Generally, by the time you’ve filled the first matrix, you’ll have a fairly good idea of what information you already know about your users and what further research might be required.

Filling in a matrix.15
Figure 7. Filling in a matrix.

Step 5: Iterate Link

Once you are done with the first matrix, set that aside, and draw another blank grid.

You can do one of two things:

  1. Pick another question from your list, “What do these users need from us?”; or
  2. Switch one of your axes to something different, but stick to the same question.

Start filling in the matrix again from the top. Remember, this is a brainstorming process. Putting down ideas that you can refine later is more important, so try to move rapidly through each iteration.

When you have done as much as you can with this iteration of the matrix, do the dance again: pick another question, or switch another axis.

It’s best when your team collectively chooses which questions and spectrums to think about.

Rinse and repeat. You’ll likely find that you can generate a lot of matrices in the space of just an hour, even if it may be a slow start at first.

Analysis And Key Insights Link

Once you have done a few of these, it is time to sit back and look for patterns. Let’s look at a few things that could emerge.

Assumptions vs. Knowledge Link

One important thing to remember — I cannot emphasize this enough — is when you and your team sit down and write this all out, what you have is merely a summary of a complex set of assumptions. As you manage your discussions around any insights, keep in mind that you are discussing various degrees of potential truth. This is an handy tactic to avoid getting into fights about too much detail!

With your matrices in hand, now is a very good time to see which set of users we already know about, and how confident we are in stating their needs. Obviously, it is also a very good time to identify which users we know nothing about. Have we already done any research on any of these user groups? Do we have any case studies that back up any of the answers we have listed in the matrices? In short, what do we know, and what don’t we know?

If we don’t have any evidence at hand to back up some of these user needs we have written down, then these are merely assumptions that we need to test. Assumptions are great because they serve as perfect design hypotheses. With this set of matrices, we can now identify what kind of user research we need to undertake to validate our assumptions.

Common Factors Link

Quite often you’ll notice that some questions generate similar results all the way down one column or one row. For example, in figure 7, we assumed that all “exploring” users would likely be interested in finding new routes regardless of whether they are locals or visitors and, similarly, that all “competitive” users would likely be interested in time-keeping.

Nothing is wrong with this; it just means that when we come to test for these needs, we will have some parameters to decide what kind of users we need to talk to. And when we come to design for these scenarios, these features will likely represent the “baseline” functionality to include in our app.

Priority and Dependencies Link

Sometimes, when you are trying to prioritize features, the practice of generating these user matrices can help you unpack some clear dependencies. In the case of our app, it became clear very quickly that the type of users who would populate the routes in a meaningful way would be locals — before being used by visitors. This means we needed to make the app attractive to local runners first, from all standpoints: in our feature set, in our communications and in our marketing.

Core Value Proposition Link

“Value proposition” is just a fancy way of describing the promise of the value you will be providing to customers. When you work through a set of matrices, you might find that you have a clearer view of what you are really promising users by addressing the ranges of users’ needs and contexts.

As for our little example, we had done a handful of matrices in less than an hour. Suddenly, one of the team members shouted excitedly, “‘I wish I knew where to run!’ That is the question we need to answer!”

I handed her the pen, and she scribbled the figure below (8) at the bottom of our last matrix. We knew then that, for this app to succeed, we would have to be able to answer this question, no matter what the user’s context — and that would be our core value proposition at its rawest. With this, we now had an excellent focus on the reasoning behind the design, and we’d just given ourselves a clear fundamental principle through some bottom-up thinking.

Value proposition.16
Figure 8. Value proposition.

Taking It Further Link

So, we have a set of matrices on our hands and some high-level analysis and insight. What next?

First, as with many workshop tools that encourage structured brainstorming, the process is as important as the result itself, possibly more so. As I stated in the beginning, this process doesn’t generate a pretty formatted deliverable — rather, it clarifies how we really think about our users.

Having gone through the process of generating these matrices and analyzing them, you should find that you can take on subsequent challenges with more clarity:

  • Decide which user groups require more research, from which you can generate personas, mental models and user journeys for more detailed tasks, if required.
  • Establish a product road map based on having identified which needs should be met across user groups, so that you can decide which features to design and build together.

One happy little byproduct of expressing user needs through such matrices is that you can delineate each of them into a corresponding user story, which fits nicely into an agile methodology. Using our app again as an example, we can create a user story like, “As a local runner, I want to find new routes to run.” You could then decide whether that user story is a validated user need; if so, you could transfer it into a design-then-build process.

When Does It Work Best? Link

I’ve successfully used this method in conjunction with others when I help startups figure out how to approach their user base, and also what they ought to build first. It fits neatly into methodologies such as the Lean Startup because it creates a structured basis for generating hypotheses. I’ve found it to be excellent both as a preliminary thinking tool to facilitate design decisions and as a synthesizing tool in the process of user research.

No doubt, as you explore this method, you may find other ways it works for you, or not at all. You could say that there is the right tool for every job, but sometimes the best tool is the one that gets the job done in the simplest and quickest way.

In this case, we have a very simple way to enable us to think about the ranges of user behaviors and motivations — while keeping their contexts in mind.

Further Reading Link

Acknowledgements Link

Many thanks to David Rollert, who sparked the idea for the approach described in this article, and who I hold wholly responsible for opening my eyes to better ways to achieve great user experiences.


Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21

↑ Back to top Tweet itShare on Facebook

Steph is a user experience strategist who loves maturing ideas and making things real. She has worn many hats, including a product lead for a startup in digital publishing and a studio director at a digital agency. She is also known for her grassroots contributions to best web practices through the Web Standards Project and the W3C. Well-travelled and living on her fourth island, she speaks several flavours of English, a few languages, and possesses an indecipherable accent.

  1. 1

    Thank you Stephanie for this excellent article! I’m always looking for new ways to increase my productivity, and simple to use yet useful brainstorming tools are far too rare. I look forward to trying this out… today, most likely.

    • 2

      Steph Troeth

      March 12, 2013 6:15 am

      Hi Tom, you’re welcome! I hope you find it helpful. Please do let me know what worked for you and what didn’t. :)

  2. 3

    Great article, I’ve been looking for good methods for the early brainstorming processes. It seems tricky to be come up with the axes.

    Here’s my attempt at applying it to a photo app using your format:
    Creative = “I like to modify the mood/tone of my pictures”
    Non-creative = “I like my pictures natural as is”
    Social = “I want to share my pictures and see other people’s pictures”
    Individual = “I like to keep my pictures to myself”

    Creative vs Non-creative
    Social vs Individual

    I hope I did that right!

    • 4

      Steph Troeth

      March 13, 2013 5:54 am

      Hey Steven,

      Thanks for sharing your attempt! Identifying axes will come easier the more you do it, and with more things you have built. It comes from making educated guesses about the nature of your audience/users. Frankly, I have generally found this easier to do through brainstorming with others rather than on my own.

      In your attempt, “creative” is probably too broad an expression for someone who likes to modify the mood and tone. It could be that the “natural” picture is just right as it is, and it doesn’t mean a user is any less creative. :) Maybe a more interesting set of axes is “maximizer ←→ satisficer”, based on people who want more choices or people who are more easily satisfied (see or search more for those terms).

      Also worth mentioning: it’s best not to think about it as “vs”, because we are addressing a range of behaviour. Someone who starts off being an “individual” type of user in your app may, over time, move towards being a little more social (e.g. following other users but doesn’t get involved), and finally to very social (comments on others’ posts). So I always express this with a double-ended arrow to remind myself:

      individual ←→ social

      Good luck, and thanks again for sharing.

    • 5

      ^ while the above is “tongue in cheek” -determining exactly which cheek is left as an exercise to the reader, it does perhaps demonstrate the difficulty of making this approach work if you do not have a valid method of choosing the axes in the first place!

      ….or perhaps I have my own axes to grind…

      • 6

        Actually I was legitimately trying to understand and learn about this methodology; I was not trying to make a “tongue in cheek” post. I’m always open minded to and curious about different techniques people have. Afterall, if there was a formula for UX we could plug information in and get the perfect solution everytime, everyone would be using it!

  3. 7

    Great article. I’m going to try it with the team tomorrow.

  4. 9

    I’m going to be honest (and perhaps prove how stupid I am) by suggesting that the article seemed like so much flowery, pseudo scientific gobblydygook. I mean, a matrix is all well and good, but without a scientifically valid process THAT DETERMINES THE ELEMENTS OF THE MATRIX, the matrix itself is then fatally flawed, AS ARE ALL DECISIONS DERIVED FROM IT!

    In short, we have only created a long winded way to justify “going with my/our gut feeling(s)”

    • 10

      Steph Troeth

      March 13, 2013 5:38 am

      Hi Albert, thanks for your comment, and I appreciate your note about axes.

      If you have constructed any kind of scientific experiment, you’ll know that your first hypothesis is always an educated guess or testable prediction. You then express this hypothesis clearly and then set out to prove or disprove it.

      When you have created many websites or applications, you do start to see certain characteristics with groups of users: a social app will always have users that range from those who are willing to dive in first to those who hang back and see what all the fuss is about. It’s from this kind of experienced premise that you can make educated guesses about what your first axes should be.

      The process of coming up with the matrices is equivalent to the second scientific step of expressing your hypotheses clearly — here we are getting all stakeholders to express their assumptions with everyone present. We then have a way to help us prioritise and plan necessary research to prove or disprove our assumptions.

      It’s worth noting that for any kind of effective strategic vision, it is important to first come up with a set of preliminary hypotheses from which you can then employ the scientific process of validation. Otherwise, the results you get from an unstructured research process, even if executed scientifically, are not likely to be very useful — and that’s a lot of time, effort and money you can’t get back.

      Hope this helps clarify things.

  5. 11

    Sorry but I disagree with the basic premise of this article that:

    “we group users according to who they are, rather than what the users want to do or what drives them.”

    I certainly have never done that and I find it vaguely insulting and arrogant that you assume many others don’t ask those questions. I think you need to do some user research on Smashing magazine readers before making these general assumptions…

    • 12


      I think the real take away from this article is the danger of basing “analysis” on vague unsubstantiated assumptions and biases.

      Note that this is not a failing of the author, but is a significant human (mis)behavior

      • 13

        1) You two haven’t really articulated why you think that way, just used Ad Hominem

        2) What exactly do you guys do for a living? Is it similar to what the author does, and if so, how long and how much/clients?

        What she is talking about is actually very tested, tried and true market research. And interestingly (and a bit ironically), these comments really just demonstrated her points.

        • 14

          1) I think I articulated my point pretty clearly. I suggest reading it again if you’re not sure.

          2) Why do you want to know what I do for a living? Would that invalidate my point if I’m in the ‘wrong’ job or had ‘too few’ clients? Sounds like you want to use Ad Hominem…

          It may well be tested, tried and true market research – I couldn’t comment as I’m not a market researcher – that still doesn’t invalidate my point. I’m not quite sure how you reach the conclusion that “these comments really just demonstrated her points” – perhaps you can articulate… :)

  6. 15

    It’s a shame that you removed my previous comment. It seems mild dissent is not tolerated. I think the basic tone and assumption of this article is flawed.

    Not all of us have been “grouping users according to who they are, rather than what the users want to do or what drives them”. To assume otherwise is arrogant.

    • 16

      A good article on how to determine what your customers want.

    • 17

      Perhaps your “dissent” was not mild enough?

      You have to remember that although SM occasionally ventures into pseudo-scientific articles like this one, they are not a technical publication, but an artistic one.
      In my limited observation, they are much more sensitive to critique and criticism and take such input more ‘personally’.

      Like any community, you have to take time to observe and feel the ‘pulse’ and ‘tone’ of the environment and conduct yourself accordingly. With that said, I still find them indispensable reading

      • 18

        Thanks Albert – I have been an SM reader for a while now and I agree there a lot of good articles here. That said I don’t take kindly to generalisations and assumptions about what I do and know – are SM users all the same? :) If the author had simply stated that this technique was a way to extend your UX toolkit then I would have had no problem.

  7. 19

    Chris Raymond

    March 14, 2013 10:43 am

    I enjoyed this piece, and I think the key value is, as you say, a way to involve stakeholders and uncover assumptions. It is a tool to help everyone be more thoughtful and explicit about “users” that could help guide the design, and I am going to see if I can introduce it in the academic setting I work in, at least for internal web design projects that often start out with really vague assumptions about users and a notion that “what we want to tell”= “what users want to read”.

    • 20

      Hi Chris, thanks for your comment. Looking forward to finding out how you go with introducing the technique in your context.

  8. 21

    Wow Stephanie! This might be one of the most, if not THE most brilliant UX piece I’ve read in years. Here’s why: you recognize that the power of this work is not in the deliverable(s) produced, but rather from insights produced by the work to inform and rightly focus thinking, questions and effort. Yes, technique trumps deliverable in the long run almost every time.

    And yes, you are right that many of the tools for UXers use for what I call “audience discovery” carry with them the legacy of a marketing mindset, where the focus of “segmentation” is more on messaging and positioning to encourage purchase/adoption vs what people need/want to do with a product/service and how that product/service should be delivered in ways that provide the most value/greatest reward in context.

    I have a way I have been doing/documenting my user discovery work, some of which leverages something similar to the dimension models you describe in your article. Mostly I use audience profiles (see an example here: instead of detailed personas to tease out the various faces/facets of a given segment. But what I like about your approach/technique is its open and collaborative nature from the get go. Unfortunately my approach requires that I/my team develop draft audience profiles and personas to use as devices to drive collaboration sessions/workshops, which sometimes are too big of a bite for clients to fully absorb in a single sitting. Your approach enables this collaboration to happen earlier, and at a much more fundamental level. Fantastic!

    • 22

      Steph Troeth

      March 18, 2013 2:54 am

      Hi John,

      Thanks for your kind words :) Your audience profiles are really interesting, thank you for sharing! I am sure these can be an effective way to document the output of a collaborative process such as the technique I have written about — just as I think wireframes aren’t always great for kicking-off a design discussion, but are perfectly effective as a way to document the output of a collaborative design process. There’s always the risk we don’t adequately document decisions made when we get excited in a collaborative process!

      Looking forward to hearing how the more collaborative technique works for you — and also if you found a way to adapt your own methods and approach. :)

      • 23

        Hey Steph,

        Yes, what I shared is more of the polished deliverable (i.e. the final Audience Profile that backs up the Persona set). The profile typically starts out rough and evolves into a prioritized and polished listing of representative people with differing needs and wants. The goal is to be “user-centered” and have a clear picture of the “theory” of the audience, so that things don’t wallow in the direction you talk about in your article (i.e. where various people involved in the effort have differing ideas and assumptions about users), but without having to develop personas that have not context around them (a problem you also talk about in your article).

        I see your matrix technique as a way to bring the stakeholders into my audience definition process earlier that I have been able to do, with the findings from the matrix exercises “formalized” in the first cut of the audience profile… at least that is how I’ll take a stab at working to implement this.

        One last thing. As I have refined my user discovery process over the years, the audience profile has made personas almost obsolete. This is almost entirely true for collaborative projects where ALL stakeholders are closely involved/following along the entire project life cycle (i.e. vision through to release and feedback loops).

        • 24

          Hi John,

          Your last point is very interesting. In the cases where I’ve used matrices I hadn’t found the need to work through specific personas; it seems that this technique, while rough, appears to provide enough basic common language for stakeholders to discuss and dissect the range of user needs. In the cases where personas had been created previously (not by me), the stakeholders can look at the matrix and say, “Oh hey, I recognise this persona fits into this group of people”, and also immediately identify where they haven’t collected any data. I would be interested to know if your Audience Profiles generate similar reactions — I also hope you can share more of your process in creating them!

          • 25

            Hi Steph,

            Yes, the audience profiles definitely bring out the recognition reaction you describe. They also help clients/project participants see the various “dimensions” of users that are in a given group/segment.

            Let me explain. I had a Federal client (in the United States) that said their site was for the “general public” and the professionals from the industry that they regulated. The 1st thing I did was develop a profile for the “general public” that I presented to the executive team in a presentation called the “The 7 Faces of the General Public,” showing 7 people (from the “general public”) with differing needs, motivations and familiarity/levels of expertise. The “a ha” moment for the client was that people in the same group/segment can have very different information/functional needs, and therefore a one-size-fits-all solution that tries to serve everybody will likely satisfy nobody if not conceptualized/planned/designed/supported properly. The Audience profile grew to 8 segments with roughly 45 profiles. No personas were necessary.

            All in all, I think the matrices and approach you describe in your article can bring the client/project team into the discussion earlier. And yes, I’ll definitely consider doing a write up of the Audience Profile as a tool for user research. Can you provide any tips as far as that goes. Thanks again for the great article :o)

  9. 26

    I love how you applied the matrix and axes here to better surface user motivations and facets. As a psychology-oriented UX professional, I’ve been advocating a focus on intention-based design for some time (see article: Intention can drive taxonomy, UX storytelling, user flow, content strategy, and much more, ultimately resulting in better design. Still, it seemed that the concept was adopted by people who had a knack for user psychology, but ignored by people who didn’t.

    Your approach looks like a great hands-on way to let designers unused to thinking in these terms surface not only motivation and behaviors, but categories for user-based taxonomies. I will definitely be applying this in the future. Thanks!


↑ Back to top