Learning Well, Simple and Fast

September 23, 2009

Attended the UPA NJ meet last night. Alice Preston talked about her UX work for non-profit. She was charged with creating a digital library of materials from and about Africa, in a number of subject areas, from botany through cultural heritage to political history. We heard many of her challenges and I know many weren’t mentioned!

My takeaway from the talk was that no matter how practiced we are as designers, managers, researchers, developers, leaders – being a “quick study” is a skill that is often assumed but critical to our success. This is especially true with UX practitioners who need to turn on a dime focusing on any given topic (finance, healthcare, enetrtainment and media, business operations, etc.) at any given juncture. For me, I am constantly asking:

1.) How do I learn best?

2.) How can I refine my learning ability to simplify and yet maximize? (agile learning?)

3.) What are the resources and subject matter experts that can expedite my understanding (more signal and less noise at faster rate)?

I recently observed some of the smartest people I know carrying around a book titled “Pragmatic Thinking and Learning .” I am ready to give it a read.

For more on Alice, the fruits of her labor can be seen at Aluka and the same data re-surfaces at JSTOR.

No time for User Research?

September 15, 2009

Unless All of the ingredients are clearly present- the risk of not researching, modeling, and defining user requirements is one not worth leaving to chance.

I attended the NYC UPA event tonight, hosted at Razorfish: “The Razorfish Transformation of Billboard.com”  – Bryan Hamilton, UX Lead, gave a polished presentation on his impressive work.

He mentioned “due to time limitations there was no time for User Research” to an audience full of … well, UPA is THE Usability Professionals’ Association… and he wasn’t crucified!? So what did he rely on instead of User Research for validating his design concepts?

He answered:

1.) A Killer Killer Team, 2.) his experience and design Instinct, and 3.) strong data provided by his trusting client.

What struck me was the confidence in his ability to deliver without the users voice and the trust in his team that they were on-game every step of the way. The solutions he shared were smart and strategic, the visual design was sharp, and the bullseye of revamping the information design was well thought through.

So was the solution effective? It seems so with metrics that are hard to argue.

Sure, Razorfish is brimming with expertise in advertising, branding, and compelling web experiences. I mean that’s their specialty, right? They have Entertainment and Media on lock-down with top staff and a client roster that any shop would envy.

So is it an act of hubris to say we’re good enough not to generate requirements through user research?

Bryan’s message was that it’s a rare occasion not to engage users and succeed in a transformative design process. Some of the rare ingredients were:

1.) A compact, seasoned all star team composed of technical, UX, and creative. He called them “allies” and commented how special to have it all.

2.) Strong focus and trust from the client to have him lead and make decisions. No layers of overhead for approval. Just drive, man.

3.) Time-boxed (a challenge and asset all in the same)

4.) Strong , objective data (gained from a wealth of info from client, Nielsen, Comscore, and Alexa)

5.) Insight to revenue stream

6.) Open mind from all (no pretense or set expectations of solution- just very clear and ambitious goals)

Lastly, he shared that the technical and design efforts ran in two parallel waterfall streams to get it all done on time. This is something I would love to hear more about. Though, he did hint that it was a point of contention internally and that Agile was proposed as the right tool for the job.

Check out the new Billboard.com

Use Case or User Scenario

December 13, 2008

I’ve heard both tools referenced a number of times. It seems there is confusion between the two. Here’s my understanding. Please feel free to share common experiences and any further clarification.

User Scenarios

  • Keep the team speaking the language of user needs and connecting design decisions closely in with the implementation process
  • A rich narrative of user interaction with the product that also incorporates persona and environment
  • Meant to show how a typical user (persona or constituency) would use a specific option or action
  • Documents what the user may do before and/or after they interact with product
  • The scenario helps drive the use case … it explains that the user is, for example, typically working on a site or application or blog in a busy office with various distractions, and may have to save progress before publishing and return — and then the use cases would need to reflect that
  • Scenario is a good place to point out motivations, distractions and more
  • Can be a bit broader, move into how a person got to the site /application and why
  • Scenario based approach to design integrates well with Agile’s use of story cards :)

Use Cases

  • A bulleted user – system talk which follows action-response pattern.
  • It does not talk about the user’s demographic profile, technical awareness, and environment or context.
  • Detail every possible option or action on the site – each result and each variable
  • Take user out of the picture to document the system responses to any single action
  • Don’t take personal environmental & habitual context into account.
  • An intermediate step between the context-rich story the scenario provides, and the cold logic of the developer’s code & “business rules” of the application.
  • The people designing the UI, labeling the controls, links and fields, developing the aesthetics and writing content need to know more than just the mechanics of what the user will be doing.
  • Descriptions of system behavior, not user behavior. It doesn’t focus on a particular user or kind of user — it focuses on what situations “of use” the system may encounter and how it should respond
  • Documents every possible feature and how it should work
  • Yes, use cases are flowcharts in words …
  • The distinction becomes really apparent (and problematic) when use cases are expanded from ‘functional specifications’ into ‘real life stories’ to explain things to the lay audience
  • Use case is a conversation between the system and the user
  • A very detailed back and forth of what happens at each click
  • Use cases can be done by a developer as well as the designer and often leads to refinement of test cases and QA plans.
  • Writing use cases can drain creativity of a designer. Reading them can inform the designer

Clive Thompson In Ten Minutes

December 10, 2008

The School of Visual Arts has a new program offering a MFA in Interaction Design. The program markets itself as “training students to research, analyze, prototype, and design concepts in their business, social, and cultural contexts.” Honestly, I am excited for the program and the faculty round up is impressive.

In an effort to continually promote the program and feed the the NYC community there’s a monthly lecture series. November was a focus on sketching and this months topic was “The Interviewer.” There were four speakers given ten minutes to present about interviewing:

  • Gary Hustwit, Director, Helvetica, Objectified
  • Jason Severs, Principal Designer, frog design
  • Clive Thompson, Contributing Writer for New York Times Magazine and columnist for Wired magazine
  • Elisabeth M. De Morentin, Illinois Institute of Technology, Institute of Design

What I found interesting and useful were the ten minutes offered by Clive Thompson. His talk was sharp and, thankfully, on topic. If you’re not familiar with Clive, check out his New York times article ( one million dollar NetFlix prize for solving the recommendation engine’s “Napoleon Dynamite” dilemma ) :

If You Liked This, You’re Sure to Love That

He explained his professional focus is rarely on the specific success of innovators (”that’s not interesting”) but really what took place before the “break through.” He wants to understand what they didn’t know and how they got there.

So he strives to grasp the process and the thoughts through all of the things that didn’t work. He mentioned some terms for further thought like “linear order” and “genius thinking.” It is the “state of absence and failure” that drives Clive’s interviewing and writing.

For me, there’s a great deal going on here that can benefit those of us interested in design thinking and innovation.

In just ten minutes, Clive provided us with valuable insight for improving the process of gathering data during interviews and reminded me to remain intrigued on not the results but the process.

Resonated quite a bit with my fixation with Pixar … I like watching the behind the scenes of their amazing creative process maybe even just as much as experiencing the movie.

I am deciding to take a step and commit to sharing my voice, resources, and experience ‘here’ for consumption. I remain open to where this might lead, how this space will be shaped and take this step with pure intentions for assisting and learning from others on their inspired way.

10 years of producing, managing, designing, coding, driving, teaching, leading, hosting, supporting, consulting, tweaking, streaming and architecting digital solutions – all while advocating standards compliant web practices and naturally prioritizing the experience of the user:

I am committed to shaping this space and applying the very principals that I practice and preach daily for those that might be charged and can benefit from the outlet.

Just what the world needs- another blog, right? Most important – I will continually ask if it is adding value :)