Menu

uxd

Notes on Creating a User Experience Strategy

, , 0

These are some notes I put together for my team last year. They are based off of a few books I was reading at the time and when I can remember those, I’ll post them for reference. We never made use of these due to reasons other than want and need, but others made find them useful.

These are just notes. Feel free to fill in any gaps as needed or ask questions if you have any.

Creating a User Experience Strategy

Goal:
An experience strategy is a guide for verticals / projects to be referred back to and updated as the vertical and/or project matures. It is a way to maintain focus on the end goal, providing the user with an experience, and is to be shared with and used by everyone on the team. For our purposes, they would likely live in confluences and our bullets would be numbered so we can refer to a specific portion of it when needed. Personas and journey maps as well as other UX artifacts (research before release / usability tests after the fact) would be parts of the experience strategy.

Reasoning:
A strong plan will guide decisions about how the business executes, maintains, and manages experiences to create value for the customers and the business. These should be invested in and managed as well as cultivated and nurtured. A strong experience strategy not only makes it clear what to do, but also what NOT to do.

Start with:
An expression of the experience you hope customers will have. A statement.

Build up:
Bulleted list of experience requirements (not ui / developer requirements, not tasks / goals – it’s all about the EXPERIENCE)
focus on:
user behavior, motivations, context, meaning
usefulness / desirableness
how does it help the user accomplish what they want to get done
how is it (or can be) different / innovative

Big questions:
What do people want to accomplish?
How does this activity fit into their lives?
How can we help deliver on those desires?

Craft:
Hypothesis based on
personas – which are project based, but stem from our basic set
research – which is project based, but builds on all other research – must be actionable and durable
previous testing – which can come from anywhere, but should help craft project based
experience
best practices
analytics

Test:
Against user stories
Against designs
Against prototypes
With Users / Analytics

Iterate and Evolve:
Take all previous information, build on it, then start over if needed.

Strategy should bring clarity and should act as a sign post to show the company where ewe are going and what we need to do to get there.

Consider making it visual when possible.

Leveling Information – so we all start out with the same definitions.

Behaviors:
activities in which people engage

Motivations:
drive and shape behaviors
– understanding the basic drives that lead people to do certain things in certain contexts

Contexts:
help provide meaning to the motivations
learn by doing

Meaning:
worthwhile? important? necessary? required? needed? changes based on context and motivation

Consider:
A user’s experience emerges from:
Motivations
Expectations
Perceptions
Abilities
Flow
Culture

Perception is preceded by sensation and followed by cognition if bottom up, if bottom down – then knowledge influences everything (Gestalt).

Ability – consider memory, it includes sensory (get attention), working and encoding (requires heavy attention), long-term and retention (storage). Recall falls off dramatically after 1 day – this is an issue for users who do not / would not / don’t need to / shouldn’t have to – interact with us or a particular tool / experience on a daily basis. Always something to consider. Reduce memory load / ability requirement whenever possible.

Flow – form follows function. Affordance means there is no need to learn. Avoid multi-usability (modes).

Form hypothesis – test hypothesis whenever possible early and then test again with analytics later. (See my pyramid)

Users / Personas in terms of behaviors, motivations, context and meaning:
Who? – are they
What? – do they need, want, use, are they trying to accomplish and is there a better way to do it
Why? – do they need it, want it, use it, like it, dislike it
Where? – do they need it, want it, use it, expect to find it / access it
How? – do they need it, want it, use it, does it fit into their workflow

Complexity:
Theories should be as simple as possible, but no simpler.
Acknowledge and embrace the complexity
Look for differentiators here – avoid parity, novelty, and trying to “be the best” at everything – just boil it down to the essentials, and then go a step further into the murky and complex chaos of the user until you come out on the other side with something that resonates with the users behaviors and motivations while considering the context and meaning

On Anthropology and User Experience Design

, , , , , 0

I get a few inquiries each semester from students looking for information on how to get into user experience design, especially those with an anthropology background. I generally try to respond to each of these separately as they each have their own perspective and needs, however, this semester I am trying to get my dissertation defended on top of my every day job as a UXD (which is getting more complicated by the minute). So, rather than leave these unanswered, I am providing a public response here that includes the most common things I share. If you have comments or questions, please leave them! It will be easier for me to respond to those here than individual emails and you may help someone else who has a similar inquiry.

Response Below

Thank you for reaching out to me. Let me start out by saying that having a background in anthropology will lend itself greatly to UX design, however, it is only one part. My suggestion is to consider opportunities where you will be asked to learn to program or script (even just HTML/CSS) and have real users use what you create. This is not necessarily where your career path as a UXD will take you, but creating something, having users use it, and then having to “fix” it to make it better for them, will provide you with insight that no degree program will ever do.

After that, I suggest looking into classes in cognitive psychology and information architecture or information behavior. Adding those to your anthropology perspective will help you find out what users want and then understand what they really need – which may be two separate things. 😉

As for internships, consider looking into the agency world. What I mean by that is marketing/creative agencies that do campaigns for other companies. Not that you want to go into marketing, I prefer the high tech/application world myself, but it allows you to see how UX is applied to multiple groups of people and projects in a short amount of time. A lot of times you can find UXD or IA (information architecture) opportunities – both of which would be beneficial to you.

I also suggest looking into these authors: Steve Krug, Don Norman, Jakob Nielsen, Jesse James Garrett, Luke Wroblewski, Lois Rosenfield, and Peter Morville (These are just off the top of my head, they will give you a good introduction to user experience design – but there are plenty more out there to learn from!)

And I suggest taking a look at the UX Slack channel that has UXers from all over the world lending their perspectives to the field (and it may lead to internship opportunities).

I hope that helps!

End Response

There is a lot that could be added to this, however, I feel it is a great place for people to start. I definitely recommend everyone going into user experience design have some sort of programming or scripting background where people have had to use what you create. My biggest failure as a developer led me to becoming a UXD and in my particular field I use skills I learned as a systems administrator/developer all the time. Not that I do those things anymore, but my past experiences and my understanding of those things definitely help inform me how to make those things easier for others to do. And really, that’s the best part of being an anthropologist and a UXD – being able to use your own experiences to inform your designs. That is, after all, what participant observation is all about!

To learn more about my professional experience, please visit my design and ethnography site.

p.s. This may be edited and updated as I have time. If you have questions/comments – please post them!

UX Pyramid

, , , 0

Every now and then my work bleeds over into my blog here and this is one of those such occasions.

I was recently tasked with creating a slide deck to help spotlight all of the things that User Experience (UX) Design could do above and beyond wireframes. As a part of that process, I collapsed a previous slide deck I had crafted about 5 years ago into a single infographic. Though it is a stacked pyramid, it should be thought of more of a cycle. The pyramid was built to illustrate how giving a user experience design a solid foundation would help inform the experience throughout the entire design process, which starts well before any boxes and arrows are placed on a screen. Once you get to the top of the pyramid, the analysis of the design should feed back into the discovery process and reinform the strategy for improvements.

This is hardly news for most of us, however, I always enjoy a simple, concise, and useful infographic – so I thought others might as well. Please feel free to share and iterate on this. I always appreciate the feedback.

UX Pyramid
UX Pyramid

UX and Agile – A glimpse into our process

, 0

So, I know this has been a widely written about topic from multiple sides of the equation. I have to say though, if there is one thing I’ve learned from Agile – and from Organization Behavior in general – there is no “one best way” to do anything. That said, I’ll give a short explanation of our version of Agile, what I do, and how I work within our Agile environment as a UXD.

Let’s talk about Agile:
Agile is defined as iterative incremental development methodology. What? This means the product we are working on has new features and bug fixes released, in our case, every two weeks. Everyone involved in the process works together within those two weeks to make it happen from graphic designers to quality assurance testers. This is different from waterfall where the discovery, architecture, development, design, testing, and release phases are all very separate from each other, happen in a specific order, and in the end the product is “final”.

While that may not sound revolutionary by any means, people moving from waterfall to agile tend to have a rough start. Biggest reason why? Things change, nothing is solid, it’s not final, and the team needs to be agile enough to roll with the punches. Let’s put it this way, I haven’t seen a statement of work or product requirements grid for nearly 4 years and I’ve never been finished with a project.

That brings us to the next part. What is it that I do?

User Experience Design:
Well, my official title is User Experience Designer (UXD). In short, I design user experiences.

So, what is a user experience? A user experience is what the user sees, feels, hears, touches, uses, understands, believes, and comes away from any application with. This means I’m a bit of a business analyst, information architect, interaction designer, art director, user researcher, usability expert, heuristic reviewer, and decipherer of languages of developers and business processes past.

But, what do I actually do? My main function is to do all of the above to create wireframes and application requirements from which developers take direction and create an application. Then I go through continuous reviews and revisions throughout the development cycle with the developers where we have to make changes and compromises due to time, resources, and hardware / software (API) restrictions that do not surface until we are already neck deep in the iteration. During that process I’m researching features for the next release and working those into wireframes which include processes and interactions that are then translated into stories. Let’s just say where people normally have peaks and valleys in their work, my work tends to run at a constantly high level.

Our Agile Process:
The other part of the Agile process is the use of stories and tasks by the developers which help direct how they spend their time and what they spend their time on for each iteration. A story is basically the development requirements for each piece of development occurring during an iteration. Each story has a set of tasks and subtasks that developers then divvy amongst themselves. Each story / task / subtask has an amount of time the developer thinks it will take to do, then as they work they report against it the actual amount of time it took. This gives us an idea from iteration to iteration what can be accomplished by the team given the tasks at hand. This helps for planning and keeping the team on task.

Our original process included a meeting to come up with the stories based on the wireframes for the devs to follow. This meeting was important because the stories had to be understood by the developers and had to capture all of the specific dev particulars that a wireframe doesn’t necessarily convey. After that meeting there were meetings to decide tasks, subtasks, and time allotted for each.

Getting Agile with Agile:
During the last two iterations we’ve change it up a bit where I wrote out the stories while I was doing the wireframes and we now use the story meeting as a brainstorming meeting for the devs. This was an important change which allows the developers time to actually collaborate together on the thinking part of development rather than just banging away on their separate pieces of code. It also makes the meeting less mind numbing and monotonous as they actually get to throw ideas out there and bounce concepts off of each other whereas before they had no time to do so. While there are specific Agile processes, we go with what works and the best part about that is it allows us to be agile with it.

There you go! Not the most earth shattering ideas or methods out there, but I think it’s always nice to document what works and to share what you can when you can.

My take on ‘Guerrilla Research’ as an anthropologist and UXD professional

, , , , , , , 0

I’ve been avidly following a discussion on the anthro-design list about guerrilla research and thought that perhaps my reply as both a traditional researcher and a guerrilla researcher may be useful to those who follow my blog. So, here it is!

Little about me:

Academically, I am finishing my masters degree in applied anthropology in 3 weeks where I focused on cyber anthropology – or studying culture online and using virtual research methods (as long as everything goes according to plan). Additionally, I am starting my PhD in 4 weeks in Human Computer Interaction.

As far as work experience I have 13 years in the computer industry and over 10 years in the fields of software development (JCPenney internal marketing applications that serviced over 5000 internal employees and over 1000 stores), graphic design (various jobs over the years from traditional print to web design), and user experience including positions as interaction designer (school information systems), information architect (at an interactive ad agency), and user interface engineer (designing HR software) / designer (designing mobile, desktop and web tools).

My Experience:

In all of my experience I have rarely ever been able to properly conduct user research. Even the one time I was given the go ahead to do so the recruitment methods which were performed by the product management team were so awful we only had a total of 6 people participate!

This means I’ve had to utilize any opportunities available to me to conduct ‘guerrilla research’.

Methods I’ve used include:

‘Participant Observation’ – I sat in on and participated in training classes where support people were being trained on current versions of software and were able to voice their concerns for themselves and their customers. I was able to take this information plus a heuristic review of the software’s current state and use that as my basis for what challenges needed to be tackled in the new interface and process design.

Subject Matter Expert (SME) interviews. Here is where I went deeper than the stakeholders or even those that called themselves SMEs and ferreted out those people who had to be SMEs not because it was their job title, but because their positions within the company required them to be. I found a great source to be the Sales department (and sales engineers) of all people. Why? These people are the ones on the front lines trying to sell the software. They are the ones that do the most competitive research and are asked the most questions by both potential customers who are shopping around (so I saw in this demo by this other company they did it this way – why do you do it different?) AND existing customers looking to upgrade (so why should I upgrade to the new version when the version I have does everything I need it to – or the current version is no longer meeting my needs and I’m not sure the new version will either – why should I stay with your company when I need this, this, this and this that you have yet to offer). Additionally, these people are GREAT to reconnect with after you’ve done your job and they are selling the software you’ve designed as they can give you both potential and current user feedback on it that they receive during demos!

Developers, developers, developers… They get such a bad rep because they are seen as the ones that just do the behind the scenes plumbing and aren’t as concerned as how it should operate on the front end. This, for one, isn’t necessarily true and in most cases is a simply out dated notion. Though many aren’t sure what to do on the front end, once you give them prototypes or wireframes and actually talk to them about your ideas they can help you expound on them 10 fold because they know how the system works, why it works the way it does, the current pitfalls, and ways to not only improve the front end based on all of this information but also ways to improve the backend which also has implications for user experience especially in terms of things like errors and page loads etc etc.

Online forums! Getting out there and seeing what people are actually saying about previous/current state is a huge help. Though it can be damaging to the ego once they start talking about YOUR contributions to the project, it is definitely a place to gather at least unabashed criticism and sometimes helpful suggestions to the product.

Stakeholders – really, I go to these people last. Especially in terms of product managers. They have too many people to answer to, to be in the right mindset of user experience most of the time. Though I’m not their adversary, I look at myself as the user advocate and the person that has the user’s voice when things come up where they might want to sacrifice usability and accessibility needs for niceities/unnecessary features/timelines.

More traditional methods done in a guerrilla way:

Site visits – can’t stress this enough. Though we only got a chance to visit two offices, just being able to see the tools they work with (monitor size, the size of their browser windows, how busy their office is etc etc) were very insightful.

Phone interviews – these were most helpful when the user already answered a set of predetermined questions up front and the phone call was used to expound on them.

Journals – having users take screen shots of problem areas and talk about them prior to our visits or phone calls was very helpful in that it got them thinking about where their problem areas were and it saved us time in that we could jump right into issues they were experiencing in the WAY they were experiencing them even if we couldn’t be there to see how they got to the issue, why they got there, or how they had to satisfice their way around it at the time (and all previous times).

Card Sorting – we had several different types of people across two offices take a stack of cards with navigation points on it and asked them to sort them in what they would most navigate to in terms of top level navigation and where they’d classify the rest of the cards beneath that top level. This was very insightful and helped our client see that yes 13 top level super cats was a bit ridiculous.

Shadowing internal users – when you have the opportunity to develop for in-house clients shadowing them is one of the least obstructive and most informative research methods I’ve been able to perform.

Examples of work:

If you’re at all interested you can find out more about my work via my resume, and my portfolio, which doesn’t include anything from my current job – but you can see an example of the work I’ve done for them here.

Let me know if this was useful!

My first release here at work!

, , , , 1

Our first agile iteration was end of January. So, in two months we created this application from beginning to end.

http://www.theplanet.com/The-Planet-Introduces-iPhone-Application/

http://www.theplanet.com/orbit-for-iphone/

I was the user experience and interaction designer for the entire application. What does that mean? I am the person that takes all of the requirements and sets out the initial vision of the application through sitemaps, flows, and wireframes. Everyone takes my work and uses that as the basis to start all development and QA testing. Then I go through and work with the developers as they are developing the app to make all of the inevitable changes that will occur along the way and update my wireframes as this occurs. My work is what comes first in the process but also carries everyone through to the end. I am the architect that provides the blueprints then ensures that the building follows the guidelines I’ve set forth.

It all starts out like this.

Pretty cool huh? Hah, well I think so anyway. 😛

Back To Top