Ghost in the Pixel

Found this interesting post describing a successful approach to rapidly designing multiple concepts within a short time period, at Autodesk:

http://dux.typepad.com/dux/2009/06/speed-racer-collaborative-sketching-saves-the-day.html

I’ve encountered this scenario a few times in my career thus far, most recently at Netflix (we actually just had ONE week!) and last year at Cisco (also just a couple weeks) with an outside vendor flown in from Taiwan. While each effort was for different purposes (sales pitch vs. concept exploration vs. new business ideas, etc.) inevitably the experience was a kind of “trial by fire” bonding moment for the team. Such projects really showed off our “true colors” so to speak as inventive, committed, multiply talented designers trying to work together intensively. Also surfaced in a very real and powerful way the notion of “shared responsibility” for the project and relaying that with non-design peers (coders, managers, etc.).

Found another thought-provoking post on the Autodesk UX blog, this time about the core values that actions that shape a positive, successful, effective design practice:

http://dux.typepad.com/dux/2009/07/values-in-software-design-practice-.html

Basically there are two lists: one of right actions and one of relative values.

Right Actions:

* Setting Goals before Taking Action
* Understand Problems before Generating Solutions
* Designing before Writing Design Documents
* Validating Designs before Investing in Code
* Steak before Sizzle

Relative Values:

* Validated Data over Expert Opinion
* Quality of Data over Ease of Data Collection
* Complete Workflows over Long Feature Lists
* Achieving Results over Writing Reports
* Collaborative Design over Design by Referendum or Design by Fiat
* Ease of Use over Ease of Coding
* Well-designed Critical and Common Workflows over Complete Coverage of Every Possible Workflow

I really like the wording and intent behind most of these lists. I have some quibbles with Data vs Expert Opinion (sometimes the expert opinion can be right, defying user’s input, particularly for dramatic innovation) and sometimes Design by Fiat does work (if the fiat comes from an informed, talented, visionary/leader) or is needed due to severe dysfunctionality, chaotic processes, etc. Just depends on your culture and context…But overall good stuff!

Set of basic foundational questions to help a UI designer (or user researcher) get up to speed on a project, focused on understanding the core functionality, primary user goals/tasks, and targeted scenarios of use. These questions are meant as a good baseline starting point, and are not comprehensive nor exhaustive!

---

USER SCENARIOS: A summary of the common “story of use” of the product by the aforementioned typical user

* What circumstances start the product usage?

* What drives the usage? What sustains using the product?

* What decisions happen at what events?

* Where do things happen?

* When do things happen?

* What is the pacing/timing of events and decisions?

* What is the social life of the information? (meaning who else is involved, other actions outside the product that occur, etc.)

* What are the artifacts in the system (or resulting from using the product) and what do they do or indicate? Who else uses them?

* When is the usage complete? What is considered “done”?

Set of basic foundational questions to help a UI designer (or user researcher) get up to speed on a project, focused on understanding the core functionality, primary user goals/tasks, and targeted scenarios of use. These questions are meant as a good baseline starting point, and are not comprehensive nor exhaustive!

---

USER PROFILE: A quick sketch of the typical user

– Job title
– Job function
– List of responsibilities
– Departments, units, divisions
– Years of experience (min/max)
– Turnover level: wks, months, yrs
– Domains of expertise
– How much experience expect to have: none, several yrs, at least 5 yrs
– Core domain tasks expected to perform
– Percentage of time spent doing tasks
– Task frequency
– Task sequence
– Amount of training expect to have
– Min education level
– Basic computer tools expect to know/familiar/use
– Specific competitive products expected to use
– Size of companies

Set of basic foundational questions to help a UI designer (or user researcher) get up to speed on a project, focused on understanding the core functionality, primary user goals/tasks, and targeted scenarios of use. These questions are meant as a good baseline starting point, and are not comprehensive nor exhaustive!

---

FUNCTIONALITY: What does this product actually do

Below is proposed a more granular breakdown of PRD-itemized functionality, beyond “Mandatory” and “Highly Desired”, with more meaningful terms (for designers)

** Priority **
P0 – Non negotiable. It isn’t a functional product without this feature.
P1 – Critical. Product can initially exist without this feature but not for long.
P2 – Differentiating feature. May provide significant usability/marketing value.
P3 – Nice to have.
∅ – Considered but dropped.

** Function Name **
The unique identifier by which a task will be known. Best stated using verbs like: Maintain, Search, Review, Modify and Initiate.

* Internal FunctionName – The name given in development.
* External FunctionName – Optional – name given after the fact by marketing.
* Competitor’s Names – Optional – Competitors names for like functions so that readers can research them.

** Description **
* Basic – Text stating what data and actions are required as well as results.

* Reason – Statement if functionality needs clarification outside of the Mission Statement. Motivation, rationale, purpose and goal.

* Dependencies – List/description of other functions required for this to exist.

** Other Measures **
While not necessarily assisting in the design process the following are useful in understanding the functions relevance.

* Person Hours – Effort involved
* Requirement Categorization – Functional, Usability, Marketing, All
* Version – If something gets pushed, what version it is expect to be put in.