Matt is working at the story wall. He is looking at stories that equate to task chunks. IxD sketches of components that support the user in doing various tasks are pinned to the wall next to the stories

I am grateful to be working with Matt Hixson on some really neat tools that will help people realize the power of social media for their business.  I won’t say a lot about that — but  do check out Matt’s blog here:  http://www.thestudyofsocial.com/.

He and his scientists are working on some crazy maths that surface some data that will be visualized.  He’s spent a bunch of time thinking about what those visualizations could be.

As we are working on building an enterprise application,  am concerned with designing a framework that supports intuitive workflow for the people who need to administrate the tool.  If I learned one thing working on enterprise applications, making mundane tasks easy and intuitive goes a long way towards driving more use of a tool.  To that end,  I am thinking about how I can help Matt think about supporting tasks in the various contexts different users will have for meeting their goals.

I know we can get to a scalable solution — a component approach to design.    Our approach to this is to take the context scenarios we wrote a few months ago and break them apart into  types of work the user is doing along the way to meeting goals.    As we break the scenarios into stories, we have a conversation about the type of task the user is engaged in.   Is the user adding/editing?  Is the user combining elements to make something?  Is the user Is the user opening a layer of detail?  Is the user sorting results? Is the user culling a list?   Is the user focusing on a specific data point?  Is the user pivoting a view?   Is the user looking at the big picture?   Once we have a list of tasks we need to support throughout the application, we can design a set of interaction patterns that will support them.

In parallel we have to be thinking about the   framework of the application.  How do all these components hook together to support the context scenario we wrote in the first place.    When we start organizing the little tasks we are supporting building them back up into domain stacks, we start to get something that looks like a mental model.

This is a model of a huge enterprise task -- broken into stacks and mapped to types of work done by various project specific personas.

This is when Matt and I back up from the  detail of the task , look at the whole wall and ask….  Where  is the navigation that supports users in finding things?  How do users get to tools?  Do they go get a tool….or does it appear as they need it as part of the general flow?

Once we get this nailed down,  we can go wild with data visualization.

For those of you who are interested in Agile, here is something totally awesome!  Peter Saddington,  put together a list of the top 200 Agile blogs (UXSuccess was #158 when he posted in June)  http://agilescout.com/top-agile-blogs-200/

I didn’t see much UX love represented in that list….  Surprised not to see Jeff Patton’s seminal work in UX Agile Product Design  http://www.agileproductdesign.com/  ….

Interesting project … not only in culling blog feeds, but in how the list was computed.  (the web and social media analytics geek in me is fascinated)

I am cutting and pasting straight from his article, but go there to see the list yourself:

HOW THE LIST IS COMPUTED

1. 864 blogs were reviewed in a preliminary screening to determine if their statistics are competitive enough to be ranked.
2. 383 blogs were selected to be ranked.
3. Data was collected for each blog from all 7 measured criteria (Alexa Rank, Compete Visitors, Google PageRank, Google Reader Subscribers, Yahoo Inlinks, Twitter Follower Count, Klout Score).
4. For each of the 7 measured criteria, each blog is ranked in comparison to all other blogs being evaluated.
5. A composite rank for each blog is determined by averaging each blogs ranking from the 7 measured criteria + partial Power 150 Weighting + social media influence mapping.
6. The top 200 blogs are published.  

I was sitting next to someone at his desk last week, watching him go through the laborious task of cutting and pasting from his policy repository, into another tool, and then into a spreadsheet and then into a power point … and he turned to me and said  — “I want this to be easier”.

“Automagical”  *  – even.

So me, being the “UX Lady”, I like to find patterns and paradigms outside of the subject matter domain that I think relate to the cognitive work domain.  (Like, when we were working on a tool that would help  people do a better job in managing their risk assessment task needs by tagging their assets so that they could have flexible visibility into what they are managing, — we didn’t look at IT asset management tools, we looked at iTunes).

I have been looking for comparators that have “automagic” goodness.  And I have found one that I particularly love.  Minty, minty goodness…..

In my research, I came across an article that resonated.  It’s written by Mark Hedlund who,  in November 2006,  launched Wesabe as a site to help people manage their personal finances.  In less than a year later, it shut down — losing out to www.mint.com.  Here’s what he said about why he thinks Wesabe lost — and I have a ton of respect for his honest assessment BTW -  (italics mine) :

“Mint focused on making the user do almost no work at all, by automatically editing and categorizing their data, reducing the number of fields in their signup form, and giving them immediate gratification as soon as they possibly could; we completely sucked at all of that. Instead, I prioritized trying to build tools that would eventually help people change their financial behavior for the better, which I believed required people to more closely work with and understand their data. My goals may have been (okay, were) noble, but in the end we didn’t help the people I wanted to since the product failed. I was focused on trying to make the usability of editing data as easy and functional as it could be; Mint was focused on making it so you never had to do that at all. Their approach completely kicked our approach’s ass.”

That’s automagical.

So, that’s what we are working towards here in UX land as we look at systematic methods for evaluating and monitoring security properties of large-scale networks.   If you are interested in helping. having us visit you, or participating in remote usability sessions,  please look us up.

http://www.tripwire.com/uxlabrat/

HAPPY THANKSGIVING!

*http://en.wiktionary.org/wiki/automagical

“Automatic, but with an apparent element of stage magic. Commonly used in computer and other technology fields, referring to complex technical processes hidden from the view of users or operators. Includes a connotation of specialness and often implies pride on the part of the process creator (especially when the person using the word is the process creator). Sometimes, also used in sarcastic way, ironically implying an impossible process. A one-size-fits-all approach to automatic controls that replaces rather than supplements manual control, resulting in a product that is less flexible and more difficult to use.”

http://blog.precipice.org/why-wesabe-lost-to-mint

NOTE: This post was originally published here:  http://www.tripwire.com/state-of-security/it-security-data-protection/security-controls/the-minty-good…ity-automation/

The Names Have Been Changed To Protect The Innocent”

These were the opening words of every episode of the series “Dragnet”.

I loved  loved loved to watch “Dragnet” when I was a little girl.

But it was on past my bedtime.

Going into the last commercial, the announcer would always say “The results of this case in just a moment”.  Sometimes I would sit on the staircase landing, watching the TV  over my parents shoulders while I was supposed to be asleep.  I would be tingling in anticipation — waiting to see the results before my folks would catch me and order me to bed.

Full disclosure, I have been out in the field and forgot I needed to blog a UX post today.  So, I’ve decided to share a snippet of a recent ethnographic visit — learning about security professionals so that we can design better user experiences for them as they manage their daily security tasks.

10:30: Wanda the Watchdog

Wanda’ cube is right under a white noise machine. She likes it because she can concentrate. She is turned around looking at me expectantly. … I ask her to do what she does every day — she is relieved because she thinks a lot of work stacked up when she was in the meeting with us earlier.

Wanda has three monitors. One is super old school. It has email opened. The center monitor has an events mapper. It is purple and has something that looks like a network architecture diagram. There is a list of events. That screen stayed up the entire time I talked to her.

Wanda is celebrating her 5th anniversary as an employee of Company X. I know this because there is a big monitor that flashes messages to the cube farm up high on the wall above and the right of Wanda’s cube. There is a message that flashes up … “this network brought to you by … and then a bunch of logos. Tripwire’s logo is on that sign.

I point it out, and Wanda shakes her head. “I object to that.  Displaying what vendors we use because that’s the first thing a hacker would look for is, what technology do you have in here.  That’s part of reconnaissance.  My job is to think like a hacker so I’m in constant hacker think mode and that’s the first thing I would do is say, okay what technology do you have, what versions are you running, are those versions vulnerable, what vulnerabilities are against them, what exploits are against those vulnerabilities and then I found the hole and I’m in.”

I ask her about her background. She has a master’s degree in security from a big school.  I tell her that I didn’t even know there was a masters in security.

“I didn’t either until I took an interest.  The previous job I had, we had viruses going around and I personally spent nights cleaning out systems because I used to be management.  I used to do what these guys did and I got tired of that and I’m like, there has to be something we can do about this and I started taking an interest in security and I found this degree and I’m like, awesome, I’m going to do this cause I’m going to fight these guys.  When I graduated I’m like, okay I’ve got this degree, what can I do?  The company I worked for was not interested in security at all, they didn’t care.  So I started looking for a job and found this one.”

Wanda describes herself as a “watchdog”. Her job is to watch and alert people.  I believe that she cares about her job. — her cube is decorated with motivational messages . I mention one in particular about how security people need to remember a business is being run. She laughs and tells me that she has that there to remind herself to lighten up. “I am a stickler”

Sometimes her boss tells her to let some issues slide, but Wanda is uncomfortable with that.  The stuff that has happened in the past two years has just taken the hacking and breach to a whole new level.

“it’s incredible.” Wanda sighs, “Unfortunately the bad guys are winning.”

(The story you just saw is true.  The names have been changed to protect the privacy of those who are participating in the Tripwire UX Lab Rat program.  http://www.tripwire.com/uxlabrat/)

Note:  This post was originally published here: http://www.tripwire.com/state-of-security/it-security-data-protection/watching-the-detectives/

The therapy tent at #occupyPDX looks like a good place for stakeholder interviews....

Pressed to explain that context scenarios don’t just come out of thin air — I put together a list of questions we need to have answered before we can write some narratives about users solving their problems….

So pull up a chair with your favorite stakeholder and start digging in…..

Product Manager Interview Outline – User Experience Requirements Gathering
(the goal for this interview is to elicit enough information to derive a set of context scenarios to begin elaborating)

Product (or Project) Name:
Who is being interviewed?
Who is doing the interviewing?

Business Objectives:

• What is  THE  primary business objectives (for our company) for the product — ( the number one reason why  it did or should be funded?) :
  Other business objectives for the product?:
• Please identify the main business problem for our primary buyer you hope to solve by offering this product.
• Please identify the main business problem for our primary user you hope to solve by offering this product.
• How do you plan to measure the business success of this product?
• Known Business requirements?
• Known Technical requirements?
• Key differentiators that will make us successful?

User Goals:

List all the different types of users you think will interact directly (configure, view data, generate reports) with this feature / function / product.
1.
2.
3.

List all the different types of users you think will interact indirectly (get reports, tell people to do something with…) with this feature / function / product.
1.
2.
3.
For each direct (and indirect)  user, do as many of these as necessary:

From your perspective, describe user type ____________ interaction:

1. What is this user’s primary goal?
2. Is this a critical goal for them?  For us?
3. What does success look like for them (when they are finished using this feature/function/product what have they accomplished?)
4. What feature(s) are they using to accomplish what they set out to accomplish ?
5. How long do they spend meeting their goal?
6. How much time elapses before they use this feature, function again?
7. How frequently are they using this feature/function to accomplish this goal?
8. Is this something they are currently doing?
9. How are they doing it now?
10. How you think they would like to be able to do it?

Repeat questions 2-10 for another goal…….

The Tripwire R&D Team celebrating product launch with Willamette Jet Boats - (The author is in the background getting hosed)

First the fun part — here’s what we do for team building after a product launch …….  a two hour speedboat ride on the Willamette up to the abandoned paper mill in Oregon City….

http://www.flickr.com/photos/65122491@N06/sets/72157627672561802

I’ve been reflecting on the Agile principal:  Responding to change over following a plan…

We have revolving-door UX sessions weekly with user surrogates face to face. We have 10 people who are committed to 15 minute sessions on the half hour every Monday. That way, we can divvy up the projects and each of the 3 scrum teams gets at least 3 sessions. We also swap our participants around to avoid fatiguing them with the same project. Generally, we are validating IXD concepts with Balsamiq Mockup click-thrus that represent our “happy path hypothesis” We record those sessions with Silverback. The UX person gives the report out immediately when the sessions are done and archives the recorded sessions so that we can do further analysis later.

Every sprint we strive to do one longer  session with Real Users — (customers who have signed up to be “UX Lab Rats”.  )  In a nutshell, these are 45 minute sessions — remote testing. I use WebEx and share an application — live code (working behind) or a prototype (working ahead). We record it — but also encourage developers and product managers to dial in (stay mute) and observe real-time.

This program has been the most influential in getting people to understand that what UX and UCD is all about — people using the stuff that we are building to solve their problems.

I believe the UX validation cycle be the single most important contribution we have made in working towards a delightful product experience for our users. Last week I got some feedback from the field that was  music to my ears.  A customer wrote a note back to the sales rep after upgrading and using the new feature :
“Side note — upgraded our console to 8.1 and am having an absolute blast setting up tag sets (and tagging profiles, to automatically apply tags).
It’s already giving me so much more visibility to the nodes.  LOVE IT! “

This is the kind of feedback UX lives for!   The success the field is seeing  is directly related to having UX sitting on those SCRUM teams  — designing solutions for developers to execute on – yes,  but most importantly, conducting consistent revolving door UX sessions with customers and folding their feedback directly and incrementally into the product — from lo-fidelity conception all the way through to code freeze.

here’s the link to the press release:
http://www.tripwire.com/company/news/pressrelease/new-release-of-tripwire-enterprise-delivers-smart-scaleable-and-strategic-security-configuration

When I joined Tripwire a year ago to “do User Experience (a.k.a.UX)” — literally right off the road from designing mobile freight logistics management tools for truck drivers,  I knew I’d be jumping into something different and challenging.  But I really  had no idea.     What I did not fully realize,  is that in the IT security and compliance business there is not just  “lots of data to make sense of “.    Oh, no….. there is a constant broadcast of sound and fury in the form of event logs that may or may not signify something, plus a ton-and-a-half of  other STUFF – devices, platforms, applications, policies, owners, geographies, compliance requirements *phew* – that administrators have to keep track of.  No wonder, that people who are responsible for controlling the security of their IT infrastructure can get totally hassled and overwhelmed.

I’ve learned a lot about IT security and how people interact with massive amounts of information in that context this past year.  The upcoming release will mark a product I started working on last June — a product that was informed by a consistent, methodological UX practice from design through release.  The resulting  product  has been consistently and iteratively designed and tested with people who are or might be users in sessions focusing on  accommodating some of their IT security management and administration needs  through a (dare I say it?)  pleasurable user experience.   The fruit of our efforts has sprung up from the seeds of genius planted by our product team  into fertile research and development soil that is cultivated through constant user validation.

1. We establish some high level goals for what we want to test.
2. Write a “happy path” story.
3. Build screens that mimic the actual behavior of the application.
4. Put together a “happy path click thru that matches the scenario.
5. Invite people to participate .

Note: This post was originally published on the Tripwire Blog : The State of Security found at this link- http://www.tripwire.com/state-of-security/off-topic/ux-lab-rats-dont-race/

Hacker stock art – Boing Boing

Lately, I’ve been thinking about “cybercrime” as I have been learning more about Information Security and the people involved.  Cyber Security is a pretty top of mind topic — seems like there is a news story every other day.   Even my pal who is a Wall Street investor (bad week for him) — and a self-proclaimed “Tech Luddite” — sent me a MarketWatch post last month about how for bank robbers, data has replaced guns.

Right here, in Portland — just up the street from us, an entire floor of the federal building is filled with FBI agents who spend every day surfing the Web, ferreting out crimes ranging from petty scams to child pornography.

This month the UX team has been working on user personas as part of our ongoing effort to understand the people involved in Infosec.  Ferris, here,  is an example of a user persona we are working on as we think about how people need to be able to make sense out of the data they get from their log files.  Ferris’ primary goal is to proactively  detect potential security threats so that he can protect his organization’s sensitive data.  He ferrets out suspicious, malicious or unusual behavior.  (I think this stock image represents him quite nicely)

Persona: Ferris the Ferret

• Corporate Goal: Must investigate alerts to prevent potential data loss and deliver the right information to the right people so they can protect their systems
• Pragmatic Goal: Needs to quickly ferret out relevant suspicious, malicious, or unusual behavior  in a sea of change and event data and deliver grokable reports
• Personal Goal: Cybersleuth Hero

Ferris has been doing integrity checking faithfully. He has a daily practice that incorporates analysis into daily operations so he can identify threat trends and patterns.  His ferreting out suspicious, malicious and unusual behavior has paid off.

He has discovered his system has been compromised. He is a trained professional so he DOES NOT PANIC.  He lovingly clutches his copy of The Hitchhiker’s Guide to the Galaxy to his bosom for fortification. Ferris needs to be able to think clearly about what  he is doing.

Ferris needs to figure out who the hacker is, how he got in,  and what vulnerabilities were exploited — (not necessarily in that order).
To further analyze the intrusion, he uses a tool to look longitudinally at the data so he can do a “post-mortem” system analysis.

When he finds the problem he prepares to inform system or network administrators who might be affected — both his own and those on other  networks.  Ferris might even report the incident to the Computer Emergency Response Team (CERT).  If he does, he will need to provide report information related to the cybercrime activities he noticed, including the means by which he noticed, the host systems and networks involved in the attack, and any other data he has gathered from log files, network activity analysis, and use of forensic tools.

Funny story.  I was looking for some stock images to represent our personas.  Mark Little, one of our interaction designers, sent me this link from Boing Boing on “Hacker Stock Art”.  It is so hilarious, I laughed for twenty minutes.  Go here you won’t be sorry.

Note: This post was originally published on Tripwire’s blog – The State of Security at this link: http://www.tripwire.com/state-of-security/it-security-data-protection/cyber-security/ux-research-ferreting-out-cybercrime/

Audrey is a dependable guardian. Mostly, she is responsible for getting things done and making sure nobody screws it up.

I wondered if I could start mapping personality types to our UX design personas. Here’s this morning’s stab at Audrey. She is a design persona we developed out of our research and experience with people who work with some of the Tripwire products.

As a part of her daily responsibility, Audrey is responsible for configuring, monitoring, and maintaining the technologies associated with Information Security.

She is interested in clarity and knowledge. Audrey prefers to observe and listen, and has a particular interest in facts and information which helps her to develop as clear a knowledge as possible. She likes to know where she stands — in other words — she needs clear goals to which she is working. She also needs to know that what she is expected to do is achievable. Audrey values her direct experience — that guides her decision making.

Even though Audrey has to interact with people, she prefers to focus on her own inner world? Like many people who are have careers in Technology — computer programmers, specifically, we think Audrey has a preference for Introversion(I). From a product standpoint, she appreciates tools that allow her to communicate efficiently and remotely — with simple explanation that does not require face to face contact or lengthy discussion.

She very much prefers to focus on the basic information she take in rather than interpreting and adding meaning to the information. She is pretty black and white about rules and regulations. When she gets data, she has a mental list that she checks off before she makes a decision. She is not likely to make exceptions to rules. This trait is common to people who are prefer Sensing (S). From a product standpoint, she needs data delivered in a way that allows her to quickly see only the information she needs to see so that she can act on it.

It follows that when Audrey makes decisions, she prefers to first look at logic and consistency before considering people and special circumstances. This is called Thinking (T) — interesting for HER since this is the only trait that is Male biased. (Females are 60% more likely to be iNtuitive).

Audrey is also very structured in the way she has dealings with the outside world. She prefers to get things decided — it makes her uncomfortable to stay open to new information and options. This is called Judging (J). From a product standpoint, Audrey is not likely to dig around looking for clues like her colleague Ferris.

Audrey has goals.

So we think Audrey is an ISTJ.

Applying what I read in David Keirsey’s book, she is probably quiet and serious (we picked a good image for her). She earns success by leveraging her natural thoroughness and dependability. Practical, matter-of-fact, realistic, and responsible, Audrey decides logically what should be done and works toward it steadily, regardless of distractions. She values traditions and loyalty. She takes pleasure in making everything orderly and organized – her work, her home, and her life. Let’s hope she meets a nice ESFP!

Take the Jung Typology Test: http://www.humanmetrics.com/cgi-win/jtypes2.asp

Some thoughts about starting broad and narrowing in....

JB adding some details to one of our design personas

A few months ago our UX team had an opportunity to share the persona work we are doing with a larger group at our company.

Part of a presentation where we introduced our personas

It was Sales Kick Off and we had all the field people coming in to our Portland office.   Folks who have been visiting the 7th floor where we live have gotten used to seeing every available bit of wall space being taken up with persona work in progress.

We wanted to a way to introduce the concept of representative users — tools for goal driven design.

We wanted a way to talk about what personas are and what they are NOT.

We also wanted something fun for the field folks to carry away from our visit.

Deck of persona cards laying around waiting to be used to help create good in the world

An episode of Pawn Stars where the “collectibility” of baseball cards was the topic, spawned an IDEA.   So we scraped together some budget to license some images and sweet-talked some our our friends in marketing to help us produce cards that would represent our design personas.

We distributed them to  everyone attending the kick off event.

Archie's goals are displayed on the back of his card

We also left them laying around where people could find them.

It was pretty good to have an opportunity to talk about personas.  That they are models that represent archetypal users by representing patterns of users’ behavior, goals and motives, compiled in a fictional descriptions of a individual.

Katie loves her some persona cards

Our IA has taken a wall and is making user flows using persona cards

Heeeeey.....where did this guy come from?

I had a goal:  recruit some non-customers for user research.   I thought it would be reasonable to talk to 4 or 5 people a day for 15 minutes each in a structured 10 question interview that would be fun and not too intrusive (these guys are super freakish about security and privacy — go figure)

I enlisted the help of the team to tweet enticing messages — like:  @uxsuccess is giving away cool #UX Lab Rat T shirts if you can find her #rsac

The Tripwire Twitter Feed at RSA 2011

Soon,  I had some people tweeting to meet me to answer my ten questions in exchange for a really sweet shirt:

1. What is your job title?

2. What is your bosses job title?

3. If you were at a cocktail party and someone asked you what you do for  a living, what would you tell them? (Probe here)

4. What do you do first thing in the morning (job related)

5. What do you have to get done before you break for lunch (what?  you don’t break for lunch?!?)

6. What do you have to do before you clock out for the day?

7. Tell me a story about a time you proved your value to your boss and the company.

8. What do you hate most about your job?

9. What do you love most about your job?

10. Anything else you want to tell me?

I also stalked the outskirts of the conference  with my trusty LiveScribe pen and a backpack full  of UX Lab Rat Shirts to give away to interviewees…

Really Sweet UX Lab Rat Shirt

I made my quota!  By 2PM yesterday I had talked to 25 people, handed out 15 shirts, and promised to mail 10 shirts to people who had no more room in their luggage!

All in all,  it was a pretty good experiment.   I learned quite a bit about these folks that will be digested and fed into our Design Personas when I get back to PDX.  I also collected enough business cards and twitter followers to start a data-base of UX research participants.   If people were interested,  I signed them up in a Survey Monkey form  that lives on the corporate site (but you have to know the URL to get to it)    www.tripwire.com/uxlabrat

OK!  I’m gonna get out in the Fog for our last day .

Last post I discussed the general problem from the agency side – and talked about internal tools that would help to create a process.   Recently, someone reached out to me and said “WELL – What is the rest of the story?”  This post is about what we give our customers.

1. Research Memo
2. Dashboard (Scorecards)
3. Observations

Research Memo

What is it?

Exactly what it sounds like.  This is a memo that tells the customer what they are agreeing to in the way of Web Analytics for their site — this could also be done as an SOW, but sometimes when you have a project in place — adding an SOW is tricky.   It is important in this memo to lay out all of the events, milestones, and deliverables.  Include what you will be measuring and why.  This is your chance to let the client know that you understand their business and can tie their goals to things people will do on their site.

Who owns it?

PM

When do we use it?

After we complete the business questions matrix.

What are the outcomes?

Permission to design the reporting dashboard and carry on with implementation.

Dashboard

What is it?

So this dashboard is actually a spreadsheet that surfaces data to the customer in a more consumable package than the reporting tool.   Eric T Peterson a certified Web Analytics genius in my book put together the first KPI Dashboard spreadsheet back in the 80s.    OK,  I lie.  It was more like 1999.    He has a bunch of resources on his site and you might want to get it there if he still makes it available.   He is offering his seminal ” Web Analytics Demystified ” for free.

The point with this deliverable is to make something for your customer that makes sense of the confusing  dashboard they can’t take action on with their web analytics tool….

Who owns it?

Your Web Analytics Guru

When do we use it?

Monthly or quarterly depending on the contract.

What are the outcomes?

Opportunity to do analysis.

Observations and Analysis Reports

What is it?

A report out that surfaces important data and trends with observations and recommendations for optimization.  This my friends is the bread and butter.  Here is where you get to apply your genius in analyzing data to drive continuous improvement for your customer — and work for you.

Avinash Kaushik is a expert in Web Analytics and the author of the top rated blog Occam’s Razor.

He also has an AWESOME book that goes beyond Web Analytics concepts and definitions to provide a step-by-step guide to implementing a successful web analytics strategy  -  http://www.webanalyticshour.com/ Give it to your clients as part of your engagement with them.

Who owns it?

Strategy and Analytics

When do we use it?

Every time we deliver a dashboard or… when we are called upon to do analysis on the data — (ask for a bucket of consulting hours to use for this).

What are the outcomes?

Hopefully some continuous improvement and web site optimization work.

Note :  If you would like to have some file  templates for these deliverables,  I am happy to share them with you.  Please tweet me @uxsuccess or just send me mail at jb@juliebooth.com

Until next time –

Simple.  No different from any design and development life cycle,  and scalable to accommodate any budget.

OK, maybe not simple.  Nothing ever is…. my point is – don’t treat web analytics as an afterthought and tack it on at the end of a project.  Use  your agency process to make web analytics part of your engagement from the very beginning of the project.   Define the problem — design and develop the solution.  I’ve used this method in my own practice with success,  I have consulted with agencies to help them put this method into their own practices, now I give it to you.

Most agencies that I have worked with  have a documented  method that looks something like this:

1. Discovery: find out everything you can about the thing you are making
2. Define Requirements: document all of the business, functional, and technical requirements
3. Design and Validate:  in various fidelity, plan and demonstrate the solution so that everyone on the team, the client, and some representative users understand what is being built.
4. Develop and QA
5. Deploy

During those all those phases,  different contributing practices and disciplines have deliverables, internal and client-facing,  that they contribute to the process of building the site, marketing campaign or application.  “Web Analytics” as a practice and discipline can be incorporated  into the development process.

Note that this process resembles a waterfall method — with phases and dependencies.  This doesn’t represent Agile — in my experience, the agencies I worked with were not using the Agile method with clients.

When working with agencies — as a third party independent consultant or part of an internal “web analytics team, here is what we did during each of the phases:

Business Question Matrix

3. Internal Technical Kick Off Document

Internal Memo

What is it?

The document that goes to Development to lock down the technical requirements for getting the site ready for analytics.

This document provides the developers with this information:
The application that should be tagged and tracked
The URL
Parent Site
Site Description
Launch Date

And answers these questions:

Is there a campaign driving to site?If yes, list start and end dates.
Drivers to Site
(TV, online media)

Where will each driver send traffic?

And lays out other important technical information that we know at this time.

Internal Memo - Important Metrics

(note: we consider all “pages”  of application when determining metrics, including involvement with forms, tools, and games within)
Are any special tags needed (for instance, flash movie intro, mid, and end tags?)

Who owns it?

PM and Analytics and Development

When do we use it?

When we are ready to talk tech with the developers.

What are the outcomes?

Agreement on approach and ready to do a technical specification or tagging manifest.

Tagging Manifest

This list is good because it is short, will get you started on crafting a strategy, and you can send it out with your Account Managers to slip in during early discovery meetings — often before they want to invite you to the party. Every time I have asked these questions — even stakeholders who think they are “doing analytics” or “don’t need them” walk away thinking “wow — there are a lot of good questions here that I haven’t considered in this context.”

These questions are divided up in categories that can be associated with a business question worksheet that will drive your web analytics dashboard strategy later.

Business Objectives

1. What are the current business objectives of your web site? (How does your web site contribute to your business?

2. How are you currently measuring the success of your web site (i.e., KPIs, scorecards, etc.)? Are you currently collecting measurements on your site?
If so, what is being collected? May we see samples?

3. What is your team measured on? How do you know when you are successful?

Outcomes

4. What do visitors on your site need to accomplish for the site to contribute to the business?

Later : list and prioritize each OUTCOME and map to overall business objectives.

Acquisition:

5. How do people find your web site now?
If it doesn’t exist, is there an existing plan to promote it and drive traffic to it?

6. What types of media do you currently use in your current web site marketing program (i.e., paid search, organic search, e-mail, online advertising, online lead-gen providers, outdoor (billboards), print, radio, PR, etc.)?

Please describe what media(s) you use and how each is measured Are there any new initiatives that you are launching that we  should consider?

Behavior:

7. What do you know about what visitors do on your site?

Prompt them here by asking questions like : a. What content do visitors look at on your site?,
b.What is your ratio of new to repeat visitors? c. What is your conversion rate? d. How much time do people spend on your site? What else would you like to know?

Engagement:

8. What do you think  it means when visitors are ” engaged” on  your site?

9.  Are visitors successfully participating in activities that are important to your business success?

10.  What do you know about how satisfied visitors are with their web site experience?

Enjoy!

Besides lots of fish-oil, Emergen-C, and coffee, here were the gadgets  I carried in my cargo pants.  These little guys really  made this trip productive  (in no particular order):

1.   Flip Video Camera:  I love my Flip better than any spendy camera I have used.  It’s small and unbreakable :  I’ve dropped it twenty times on concrete and it still keeps on going.  It’s is also plug and play.  I keep a private YouTube account where I immediately upload and make notes and can share those videos back with my team.

The main thing I love about this camera, is that it is so unobtrusive; people forget they are being filmed.  It’s just point and click.  I can hold it casually in my hands or set it on a counter and we are good to go.

2.  Pulse Smart Pen: This pen is freaking magic!  I don’t even know what I ever did without this thing.  I have a small little black notebook that looks like a moleskine – but it has teeny magic dots that are read by a camera in the pen.  I can record all of my notes digitally, plus get voice recording along with what I write — I got really creative about using symbols to capture notes, so I could make eye-contact and do better prompting during interviews.  I didn’t have to bury my face in my notebook.   As a practice,  after every shift, I would upload my pen notes to my Mac and turn them into text that I’d augment while listening to the recorded voice transcript.  I emailed those notes to myself and back to my team periodically.  This is a lifesaver now as I am needing to start reporting out.

I also used the pen to do participatory UI sketching with users.  This will be a whole ‘nother post.  IT ROCKED!!

3. Blackberry Curve: I love my Blackberry.  I took  pictures and emailed them to my gmail account.  Every time I collected a paper artifact, I’d snap a picture and MMS it with a reference note to myself.  Now that I am combing through a pile of paperwork trying to figure out where everything has come from I have help.   I also kept my gmail account hopping with frequent notes updated to myself when I was away from the computer.   IMHO, the blackberry keyboard wins hands down of any I have used on a mobile device.  That being said, my little pink curve died on the road, and I just got my new every 2 Motorola Droid from Verizon.    I have to say,  love the apps.  HATE the keyboard so far.

Freight Operations Supervisor's station : he is planning for the outbound dispatch late on a Friday night.

5. Garmin Nuvi: Perhaps this little guy will be replaced by the fancy new Droid Google Map feature on my next trip.  I have trust issues with connectivity though.  My Garmin got me from Baltimore to Seaford Delaware, to Arlington, VA, to Hagerstown MD, to Allentown PA, and Newark NJ without a hitch.  I love the way she talks to me.

AND a few non-gadgets of note.

6. Balsamiq Mockups: (on my MacBook)  Invaluable for doing participatory sketching with users and sending back click throughs to the team.   I will be demonstrating this at UX Show and Tell PDX on March 30.

7. Safety Shoes:  These are not gadgets.  I owe my comfort and sense of well-being to my Hytest shoes.   Arch support – check. Steel Toes – check,  Padding – check, Oil Resistant tread – check.  And, they were slip-ons.  I breezed through airport security.

I will be posting more about this trip.   For an in-person report out, join me at  UX Show and Tell PDX on March 30

Suzanne Kimble shares user requirements documents to our group of PDX area UX practitioners.

Well, last night we kicked off the first Portland UX Show and Tell event here at Con-way Freight.

Fifteen UX practitioners and enthusiasts gathered at 5:30 for pizza and networking — and lots of hugging (we do that in Portland).  Psyched to see tweeps  @thisKat, @marniepw, @evamill and @storywoman  — and jazzed about making a few new friends @jean_marie and Jenine from New York.

….. and then we got down to Show and Tell.

Mark Little kicked us off by sharing a report out that included wireframes for a dashboard to be used by freight brokers.  He explained how he used the RITE process and participatory design to get to the wireframes that form the basis of  the product requirements that will be turned into Agile stories.

Next, Eva Miller @evamill wowed us with three examples of how she documents and communicates the user task flows that feed design requirements.  She brought us a question:  “which of these examples works best for what audience in your experience?”  Her example for a grant writing data visualization tool sparked lively discussion.

Johnny Levenson showed us wireframes for a brand asset management system dashboard he is working on.    We all nodded and laughed  a lot and shared his pain and triumph as he shared some effective strategies for collaborating with designers and developers.

Johnny Levenson shared some effective strategies for collaborating with designers and developers.

Suzanne Kimble ended the sharing with a bang by sharing her success in slimming down a massive written product requirements document into a very usable and consumable deliverable that includes visuals that designers and developers “get”.  Her project is to design an interface for CAD systems to be used by apparel designers.  We are going to start hounding her for PDX UX Show and Tell T shirts .  I look forward to sharing with Suzanne as we continue to navigate the Agile Waters in our respective jobs.

I had no pre-conceptions going into this thing except that I was psyched to meet up with some cool peeps I haven’t seen in awhile.  A few things struck me as take aways from this session:

1. Requirements – we all want to know “how do we do a better job of communicating requirements?”

2. BA and UX and Design and Development  are closely intertwined and collaborative in the most successful cases

3. UX builds bridges – in all cases we were the ones who communicated “what this thing is that we are making” and we did it by showing how our users would do their jobs better by using the thing what we are making.

I am super energized and grateful to be a part of this community of awesomeness!

Looking forward to next month’s event!  Join the PDX UX Show and Tell Group on Ning.

The Boss  threw down a challenge last week.  He asked our team to put together a preso for brass outlining what should be our vision for Institutionalizing UX in Enterprise Services.  He asked for a 1, 3 and 5 year plan.   Someone has  had a wake-up call  and now IT wants to know how we are going to help our organization go from a focus of building lots of functions to meeting user needs — and how does that play with the Agile method we have adapted?  Sheesh.

Of course, the first thing we did was to go to Neilsen’s treatise on the stages of usability maturing.  The gist of his writing:  to truly become a user-centered organization, companies almost always progress through the same sequence of steps, gradually increasing their levels of commitment to usability.

Stage 1: Hostility Toward Usability
Stage 2: Developer-Centered Usability
Stage 3: Skunkworks Usability
Stage 4: Dedicated Usability Budget
Stage 5: Managed Usability
Stage 6: Systematic Usability Process
Stage 7: Integrated User-Centered Design
Stage 8: User-Driven Corporation

According to JN, it takes about twenty years to move from stage 2 to 7 and another twenty years to reach the last stage.

Links:

• Corporate Usability Maturity: Stages 1-4
• Corporate Usability Maturity: Stages 5-8

Right now, I am trying to figure out what stage we are in.   I am going to say off the top of my head that we are in Stage 3.  However, if we can actually get UX story points added to our projects, we might look like we are in stage 4.

We are in various stages depending on what project you are talking about.  I think we  are definitely in Skunkworks UX .  We still have a whole bunch of Stage 1 and Stage 2 thought and practice going on……

Some other things that I came across in my mad Googling:  HFI User Experience (UX) Maturity Survey.  HFI developed this survey to capture a comparative view of the maturity of usability operations around the world.  http://www.humanfactors.com/UXMaturitySurvey.asp

The good news is that HFI’s UX Maturity Survey 2009 seems to  indicate that usability has transformed from a business differentiator to a routine component of business practice — at least in the companies surveyed.   According to the blurb on HFI’s site:   “Stable, visible, internal usability and user experience groups with executive support have become significantly more prevalent since Eric Schaffer outlined the elements of a mature usability/user experience practice in his book, Institutionalization of Usability, A Step-by-Step Guide (2004).”   (I admit that I haven’t read this book – I just received it.  Thank you Amazon.com)

Also came across some articles that I have bookmarked as interesting  from my new fave UX resource site:  UXMatters

Gabriel-Petit, Pabini. “Sharing Ownership of UX.” UXmatters, May 28, 2007.

—— “Specialists Versus Generalists: A False Dichotomy?” UXmatters, February 9, 2009.

Jones, Colleen. “When ROI Isn’t Enough: Making Persuasive Cases for User-Centered Design.” UXmatters, May 7, 2007.

Nieters, Jim, and Garett Dworman. “Comparing UXD Business Models.” UXmatters, July 10, 2007.

Sherman, Paul J. “Connecting Cultures, Changing Organizations: The User Experience Practitioner As Change Agent.” UXmatters, January 20, 2007.

As we are figuring out what we want our take away to be when we present, we’ve come up with these bullets which are now attached to my cube on post-its:

1. Focus on the user and all else will follow (see Google)
2. Our company is HERE on the scale of UX Maturity and we want to be THERE
3. This is going to require both a cultural shift and a tactical shift

What took you so long??

Indeed.

“Critical to obvious application interaction design is the element of familiarity – so that end users’ learning curve is decreased and productivity is increased. The discovery and documentation of design patterns, common interaction solutions to common interaction problems, is an emerging best practice for internal application development  efficiency.  Familiar patterns help users learn new applications quickly by allowing them to draw on their experience and use it while they learn new features and functions.  We know design patterns  emerge when a pattern proves to be effective over time.  When it works on one site, or application, others emulate the interaction pattern and when it succeeds across many common applications, users start expecting the familiarity of that type of interaction.

Unlike style guides and guidelines, patterns explicitly focus on context of use and tell the designer when, how and why the solution can be applied. Patterns capture a common structure, usually a very familiar one that is easy to recognize, without being too concrete on the details, giving the flexibility to be creative, unlike style guides.

Discovering  and then documenting internal design patterns will reduce the design time for engineers if we develop a reference point for them to  solve interaction design problems.  An added benefit  is  that this practice will  ensure consistency in the application user experience……”

He asked me how we would do this, and here is what I thought we’d try.

1. Discover existing interaction solutions to common interaction design problems found in web and mobile applications and document their use in an Interaction Design Pattern Format
2. Document anomalies to those patterns and make recommendations for improving consistency
3. Develop a searchable, scalable library of interaction patterns  for use throughout the enterprise

Just because I am a musical theatre geek and this tune has been running around my brain:

“I love you madly, madly Madam Librarian…Marian …”

Does anybody out there have any experience with this?

Will you share how  interaction pattern libraries have helped you in:

• Teaching best practices and common approaches by showing rather than telling
• Capturing collective wisdom of designers/developers  across many uses and scenarios
• Making usable designs the “path of least resistance”
• Eliminate wasted time spent “reinventing the wheel”
• Ensuring users have a consistent and predictable experience within an application or service
• Giving teams a common language, reducing misunderstandings that crop up from different·vocabulary use
• Reducing time and costs in the design and development lifecycle

Please write.

As developers start to build the functionality, the individual pieces look and work OK, but the software feels like “Frankenware”–lots of pieces bolted together into something that neither looks nor feels good.  Our business owners, who are proxies for our end users,  acknowledge that the software has all the features they prioritized as high, but the features are not exactly useful in the context of the daily task.

It’s like I was saying to my buddy Mark just yesterday — if we were designing a tool that would help someone do everything they needed to do to get out of the house in the morning, we’d start with a story that we’d plop in Mingle.  It would say something like:  ” The user wants to get out of the house so that she can go to work.”    The BA would look at that story and come up with all the functional requirements to build a door that opens — so that the user could get out of the house.  There would be another story to close the door … and to lock it.

What I said was – “there is no way I am getting out of the house without coffee.  That’s a requirement.”

What we need is one big story that makes sense of all the little user stories.

A User Context Scenario is the connective tissue story we are looking for.   This is a narrative description of a person using our solution to successfully reach a goal.  In the course of telling this story, we select a persona who needs to use a number of the features (represented by stories) that our software has in scope for this iteration.

We work with our existing personas.   In this example, we meet Betty, an HR generalist.

Betty is an HR generalist. We've identified her persona through research. This is an "agile" persona.

Betty has goals.  GOALS are important to the context of the story.  Notice that Betty’s goal is not ” Find a user in the database”.   Her goal as a networker and ambassador for her company is to “Put a face to Vijay’s name”. The context of that goal implies features and functions that should be considered in the application.

This is where we articulate Betty's goals in the context of some features we've identified in stories.

Notice that sprinkled throughout the scenario are the goals of the software’s primary user (Betty) and its secondary user (Vijay), along with commentary that gives us an idea of how often this process occurs, how long it might take, and what’s going on in the real world while the Betty is using the system. These things make the scenario tangible and memorable.

We can use concept wireframe sketches to describe the activity visually.

The best way I have found to work through these stories is to pull together a group of people that includes end-users and those familiar with the features in scope. A group of three to five people is a good size. Start by discussing the user and the context . Describe the person, the place, and the situation, and then proceed to describe the scene that plays out. As we discuss it, we work through the context scenario  on a whiteboard where everyone can see it. Once it is drawn there, we can take pics and then sketch it up using In Design, MS Visio or Balsamiq.

We talk about specifics in the story. What happens if there are a bunch of search results?

Context scenarios are pretty awesome  for building and validating a lo-fidelity UI prototype.  A UI prototype set to a user scenario is referred to as a storyboard — for this purpose, I will sometimes put together a power point click -through like you see in this example.

Try to write the scenario in such a way that it doesn't restrict any options in the UI and get bogged down in the technical!

By walking through stories at the beginning of a release cycle when the team is choosing stories for development, providing a context view from the user perspective is critical for uncovering out some of the little things, like “how to get back to the beginning of a process”  that will crop up during development.  Scenarios make good test cases for lo and hi-fi testing.  If we can get our training folks involved during the creation, it makes it easier for them to start their work earlier in the release cycle.

A lot of good things happen when you write a scenario. Those implementing the software clearly understand the context of use--where the user is and the kinds of features that need to be in the software

As a creative person,  I admit that it’s tempting to engage in creative writing  for the sake of story-telling.   At times the scenario can draw attention to a feature or detail that is actually insignificant.  All in all, I have found context scenarios to be really helpful in communicating to  the team.  They are also nice in that they help us connect the stories into usable flows.

Now, how do I do that as an “Agilest”?  I’ve done it a bunch in long-drawn out processes — where I could Ideate all this stuff and then hand it off.  Now I am trying to work ahead of the curve.

Right now, it looks like in iteration ZERO while developers are figuring out the data model, I am putting together context stories for iteration One.

Any ideas / examples are welcome.  Please share what y’all are doing!

Where is user experience relevant?

Why am I obsessing?  Because right now — at this second — I am working in that scribbled pink area.  Let’s look at the product I am supporting — mobile device software for  managing freight shipments.

Compelled use? Check.

Internal use? Check.

Reduces cost? Check.

Totally PINK.

Does this bug me?  Check.

Wait.  Not really.  It doesn’t totally bug me.  Because deep down inside I KNOW the relevance of user experience.   These past few months, as I have been out in the field — riding along with drivers who pick up and deliver freight for our customers,  the most  striking thing that has registered for me is NOT so much how they handle all the paperwork and the phone calls, and the reading of the maps.

These guys are the ambassadors for our company.   If they aren’t confident, at ease, and generally kind of happy about what they are doing,  the company’s customer experience is going to suffer.   To put it another way –  I watched one of our drivers filling out his paperwork walking back to the cab after spending 3 minutes BSing with Mildred at the auto parts warehouse — (she’s a regular).  I asked him why he filled out that paperwork while he was walking back to the truck.   “Well,  if I don’t,  I won’t be able to talk to Mildred.”  he paused “So whatever kind of paperless thing you make, I better be able to walk, and talk and fill it out all at the same time while I am walking back to the cab, or it’s not gonna fly.”    “That is, unless it’s too slow.  And then, it’s going through the window.”

“Yellow” is close to :  FFFF00   and  “LT Yellow” is close to: FFFFBE  if you want to check them at a really cool site : ColorCombos.com.   This all started with the need to “zebra-stripe” a table in a handheld UI to make it easier to discern a list of data.    I looked at the colors available and suggested that we use “lt yellow” since it was the most subtle of the colors — I just wanted a slight hint of something to make it easier to see another line.   Somewhere, someone – before testing — decided that “lt yellow” was way too subtle “you can hardly see it!! Users won’t be able to”  — so we tried “yellow” instead.

Watch what happened here: ( it’s short)

“Yellow” was too much.  It was misread as a highlight — something to pay special attention to, rather than just a background color.

• Define Usability engagement and approach
• Define / Pull together user personas
• Establish initial UI vision

Until now,  the only task for UX in iteration ZERO has been to define how we will be working with the team.

Oh,  and QA and I are co-locating with the team !!

Last week, just after presenting our section on “UX” to the people in the “Agile Training” class,  I received the Urban Dictionary Word of the Day .  Groan!  Yeah… I used the tired metaphor to  explain what Mark and I do as the only two  “UX” people here — each of us supporting a number of agile teams and projects.

Here is who I told them we are when we wear our different hats:

The User  Researcher is the person who uncovers  insights about users and their tasks.  We observe, listen, and learn.

The Interaction Designer is the person who is the discipline of defining the behavior of products and systems that a user can interact with.

The “Usability” person is the person who makes sure the product is usable – a term used to denote the ease with which people can employ a particular tool or other human-made object in order to achieve a particular goal.

We went on to explain that there are multiple UX methods and deliverables that we use to help the team Understand, Solve and Evaluate components of the end user’s experience with a product.

In old-school agency days back in 1999, we had a long, drawn out water-fall process where User Research understood and communicated the user goals, their personas, what’s important to them, and how they do stuff.   The  IxD and/or  Information Architects solved the problem of how that experience is manifested in the User Interface.   Then hopefully someone would validate usability at the end of the project just before launch.

In the agile process, we do all of those things too — but at the story, iteration and release level with the software developers.   We no longer go off into our caves and write a huge usability manifest that we hand off to designers and developers.  Our tests don’t take a month to plan, execute, and report out on.  We don’t draw coffee-table books of wireframes that are out of date by the time the project launches.

Chris Nodder and Jakob Neilsen provide a diagram in their paper:  “Agile Usability: Best Practices for User Experience on Agile Development Projects” that shows how UX work can and should have impact thought the development cycle:

Neilsen Norman Group, to purchase a copy of the report, download from: http://www.nngroup.com/reports/agile

On our team, we interact with both the business (customer) representatives and the development team. As such, we think of ourselves as bridges. Early involvement in a project helps us to guide the team in thinking about the right users and their important tasks. In our case, we can clear up assumptions development makes about how the customers are currently doing their jobs with an existing product.

We do our up-front understanding work in iteration 0 or before. This consists of site visits, interviews, truck driver ride-alongs and such activities. Throughout all the iterations we help to solve problems from the user perspective and validate that the solutions are usable. Below is a sketch I drew with a few team members to explain what we do during our iterations.

This sketch shows UX activities during iterations.

As we get started in an iteration planning meeting, we help the the team better understand how stories link together into user goals. We might draw user flows that link several stories together during this time. UX also owns the wireframes. A low fidelity set of screen states that can be linked together as a prototype lets us walk through what we are building during the sprint.  These along with the narratives become the specification for the developers.

During this time, UX is busy testing these prototypes via RITE sessions with folks who have agreed to be part of the “revolving door team.” These people are second tier support — so they are already aware of user issues.

Because I am working on the mobile device team, we have a set of technical hurdles to overcome to get to a prototype on the device. Testing click through screens on a desktop before integration lets us get at many of the problems with the interaction model before the solution is coded. This happens several times during an iteration. When we get results, we put on the IxD hat again and work with the BA and developers to tweak the interaction design..

When we have a build deployed on our device development environment, we can take it out to the field and test with users. This usually happens once during an iteration — just before QA.

Finally, before a release, we do more formal usability testing before deployment. Generally here we are focused on consistency and standards between features and functions. I will write more about these test sessions in the future — for now, I am off to an iteration planning session!