- We design and build extraordinary applications for companies looking to make the next great idea a reality.
- learn more
Design Thinking
Hmmm … is design thinking going mainstream? A recent article in the Harvard Business Review and now this from the New York Times:
So pervasive has design thinking become in the last five years that Stanford University has created an elective program it calls d.school — more formally known as the Hasso Plattner Institute of Design — that has proved wildly popular with budding entrepreneurs from all corners of the campus.
It is a time in the spotlight for a process that historically has been relegated to the end of the business planning line.
Those of us involved in design already know that design thinking is one of several tools we use to help our clients stay competitive. Nonetheless, it’s nice to see major publications picking up on not only what design thinking is, but the importance of joining it with business thinking. Read the full article for a review of how this partnership works to create new solutions.
Topics: design thinking
Bullseye Diagram
In most projects, it’s easy to come up with ideas but more difficult to give weight to their importance since the client (and sometimes the team) think they’re all important. So we move onto establishing a scale (1 = must have; 2 = nice to have, etc.) and then assigning values to each task/idea/feature. Generally some good discussions come out of this exercise in determining exactly what is important in creating a successful project, along with defining exactly what “success” is.
At the IDEA 2008 preconference workshop, Dave Bishop and Paul Gould from MAYA showed us another way to prioritize project tasks: a bullseye diagram. It’s still a ranking system, but done visually rather than numerically. The team first lists out all the project tasks. These are then placed in the bullseye based on where they fall in rank; the critical items are in the center and the less important items moving towards the outer rings. If this is done on a whiteboard with the tasks on Post-it-Notes, then information can be quickly be moved around in relation to new tasks that are added to the bullseye.
Once the tasks are prioritized and in the bullseye, you can organize, arrange and add structure. You can start to see relationships, which may indicate a different priority. You can start to see categories, which may affect iteration planning. You can begin to add structure. The outcome of this exercise is an easily understood diagram showing the project’s priorities. For teams that aren’t comfortable assigning a number to a task, this is a good alternative to try.
IDEA - preconference workshop 06 Oct 08
The IDEA conference is being held in Chicago this year, and once again MAYA Design hosted the preconference workshop on Information Architecture. Some thoughts from the morning’s discussions.
- Why diagram? We diagram in order to depict the information space in such a manner that allows us to visually validate to the client that we understand their domain. So often as consultants, we’re thrown in to domains where we have no or very little prior knowledge and minimal time to come up to speed at the level we need to be at in order to understand the context of the problem. Diagrams are one artifact that we use to organize the information space and document the users’ mental model. They are an essential element in verifying that your direction and understanding are correct.
- Future proofing. Don’t just design for the here and now; don’t design a solution that locks you into one way of thinking; don’t create a solution that can easily be broken by another idea. As solution designers, we need to look at the larger picture and how the various pieces can fit into the whole, rather than at just one feature or one path. We need to allow for evolution so the solution can accommodate growth and expansion without extensive redesign. All of these are concepts we’ve heard before; but it's already good to get the reminder and hear them again.
- UCD - user centered design focuses specifically on making systems usable to people. It tames complexity. Having the user integrated into the design process brings a focus around which you can organize the solution and design a usable interface. The direct benefits are increased productivity, reduction in support costs, improved user satisfaction, etc. The usual suspects, but nonetheless important to bring up with your clients when you remind them why UCD is relevant.
For the remainder of the session, MAYA reviewed some diagrams they use in their IA practice, including some I hadn't seen before. I’ll have more on that later.
Use a Task Flow to Show “How do I ___?”
Although task flow diagrams (sometimes referred to as interaction flows, process flows or work flows) are a standard in most IA’s toolkits, it can be confusing for those unfamiliar with this particular tool to know when to start diagramming. When in the process is it started? How much information is needed before diagramming? How much detail should be added? When is it considered complete?
The short answer is to start diagramming once the task is identified because it’ll help in flushing out the requirements. The diagram starts to identify what the user and the system need to do. It delineates a repeatable pattern of activity. It answers the question: “How do I _____________”.
After you have an identified task (I like to use Use Case Diagrams to call out the high-level tasks), the start point and end point need to be established. For example, let’s say your business requirements state that the web application is only accessible by authenticated users; therefore, a user needs to successfully login in order to see the home page. The initial diagram has the user starting on the login page, submitting their information and viewing the home page after the system logs them in.
But wait … I did say *successfully* login, didn’t I. O.k., so we add a decision point to the diagram to show that only successful logins allow a user to access the web application. Don’t worry just yet what the details are for the system to successfully authenticate a user. The purpose of the diagram is to identify the process, not to define it. For now, all that's needed is to show that the login information must be vetted before the system allows access.
Granted, the previous examples are simplistic, but simple is where task flow diagrams start. This basic statement “How do I ____________” turns into an initial task flow, delineating the steps needed to complete the task from start to finish based on the information known at that time. The first iteration is generally the ‘happy path’ and identifies the main flow of a task. As more steps are uncovered through requirements, the flow is updated and modified to accommodate the new information and show the various decision points and/or alternative paths as they become known. The end result is a flow diagram that conveys both the overall structure of the main user tasks and the sequencing of activities to be programmed into a repeatable activity.
Topics: Best Practices, Information Architecture, Task Flows
Site Maps — Still Needed for Web Apps?
In a previous post, I talked about creating a Use Case Diagram as a means to moving the 60,000’ concept to a level of detail that’ll allow us to begin development. Since that diagram identifies the overall functionality, the team can use that to start designing the data model, writing user stories and generally working towards a more detail view of what we’ll eventually need to develop.
The site map is another diagram I’ve found helpful to bring further definition to the concept.
On some projects, usually those that were understaffed, the site map was typically drawn up after the project was in the end stages of development and only because someone in marketing asked for it. Oh, everyone on the team knew what was being built and the relationship between the areas, but it was all verbal -- no one had taken the time to set it down on paper.
At Pathfinder, we sketch out a site map early in the process to give a physical representation to the verbal concepts floating around the team. The ‘we should separate this’, and ‘let the user skip from here to there’ and ‘oh yeah, both these areas relate to each other’ kind of ideas that float around before requirements are actually written.
The very act of documenting work to further define the concepts and gives the team a visual artifact for future decisions. The site map, no matter how rudimentary, begins to identify and categorize the user activities into a relational hierarchy and provide a framework for the application. It helps in project scoping and planning because it begins to further identify the details of a project, which can then open a conversation as to what is needed now and what can be postponed to later. It is a concrete drawing that you can show the client and ask, do you agree? Is this what you want?
As with Use Case Diagrams, a Site Map gives you an overall view of a project -- not necessarily all the details but a high level view of the end goal. Both documents are relevant because both give you a checkpoint to refer back to once you’re in the details of a project to make sure that you’re still on track to meet the project objectives.
Use Case Diagrams
Projects start off at the 60,000 foot level -- the client wants a widget that allows their users to do X, Y & Z -- and need to be brought down to a level of detail where coding can begin. Something I use to start this process is a version of the UML Use Case Diagram.
For those of you not familiar with it, a Use Case Diagram describes the needed functionality in a system. Unlike flow diagrams, however, the use case diagram doesn’t represent the order or number of times the functionality needs to be executed and it doesn’t display any subroutines. Instead, it’s a high level diagram that identifies the primary tasks an actor/persona needs to be able to do.
The beauty of this diagram is that you’ve now captured the overall view of what the system needs to be able to do in order to allow the user to complete all their tasks. With the high level activities clearly identified, the diagram easily lets you communicate with your client and get their sign off that the needed functionality has been accurately captured. From here, the team can move onto further defining what’s needed to support this functionality: data modeling, user stories, task flows, etc.
Topics: Best Practices, Design, Information Architecture
It Starts with the User Story
Having recently been asked about the difference between a use case and a user story, I came up with this explanation:
Use cases detail the interactions between an actor and the system in a sequence of steps and are generally used to capture the functional requirements of a system before implementation. Because of their scope, i.e., they take in more exception scenarios, they can be too large to be used for iteration planning since they would be split across multiple iterations. Also, there is a bit of a learning curve to interpreting use cases which can leave the non-technical customer out in the cold.
A user story is a short description of a feature as told from the point of view of the user (generally your persona). They consist of one or two sentences written in the language of the user, and are used to estimate the degree of difficulty to implement (which ties in with iteration planning). At Pathfinder, we also include acceptance tests when we write the user story as a way to set out the criteria that determines when the story's goals have been met. Again, written in plain English so that both technical and non-technical team members understand what success means for that feature.
For our Ruby on Rails projects, we're writing our user stories in a format that'll help the developers convert them into automated tests using the Rails framework:
As a [role]
I want [feature]
so that [benefit]
From here we create the acceptance criteria, which we write as scenarios in a specific format (givens, events and outcomes) in order to help with writing the automated tests:
Scenario 1: Title
Given [context]
And [some more context]…
When [event]
Then [outcome]
And [another outcome]…
We'll then go on to create flow diagrams, requirements and wireframes to further flesh out the details of this feature, but it all begins with the User Story and Acceptance Tests.
DUX2007 - Ubiquitous Computing
Adam Greenfield of NYU’s Interactive Telecommunications Program gave a great keynote presentation at DUX07 on ubiquitous computing -- embedded devices that are wirelessly networked, imperceptible, mobile and post-gui. Devices that are not perceived as computers by the people who use them, but rather as a facet of their lives. An example he cited is the Nike+ product for runners, which pairs with an iPod to give you feedback on how you’re running while you’re running and records info such as distance, time, etc. You can then sync your workout data to either iTunes or the Nike site, where you can then become part of the Nike+ community. It is a computer, but to most people it's just a piece of plastic you put on your shoe.
Ubiquitous computing. Existing or being everyware. Perceived as a facet of the user’s life. Eroding the distinction between product and service
Consider the automobile. When the first Model-Ts rolled off the assembly line, the car was a product. You drove it here and there and that was basically it. With the addition of On-Star, the car’s autonomy eroded as it was now networked with a diagnostic tool, roadside service, emergency contact, etc. The perception of a car as only a product began to erode as well; the car began to evolve to a platform. Fast forward a decade or so and we now have car as a service -- the Zip car. Glimpsing into MIT’s Smart Cities project, we begin to see the car as an interface to the city and not the engine.
As designers, then, our challenge is to design for these product/service ecologies.
Back to the Nike+: although the device is basically a pedometer it only works for runners, not walkers. In addition, participation in the Nike+ community requires Flash because that's what the Nike site uses. This is a closed ecology and by their very nature, closed ecologies are brittle. Greenfield, therefore, advocates designing these products/services to use open frameworks because of their openness, their ability to be flexible and extensible. The downside of an open framework is a loss of control and for companies heavily vested in controlling their brand, this option may not even be considered. His argument, however, is that open frameworks aid in a product’s long-term viability.
Some final thoughts from Greenfield:
- As designers, we can no longer assume that the product we design will be a standalone product.
- Everything that can be networked, will be.
A final thought from me: it's an exciting time to be designing.
Technorati Tags: Design, User Experience, Usability, DUX07
Topics: Best Practices, Design, Ideation, User Experience
DUX2007 - Data Visualization
Data visualization was touched upon a number of times throughout the DUX07 conference.
In David Pescovitz’ keynote address on Monday, he mentioned that since the 1980s we’ve seen three waves of technology: PC Computing, communicating, and sensing. We’re now in the fourth wave which is sense making -- how do we make sense of all the data that’s out there. How do we deal with search queries that return hundreds of thousand of lines of results. How do we start to make connections between the data.
One way we deal with sense making is through data visualization -- a concept which is starting to filter out beyond the research labs into the commercial space. Through data visualization, we can take huge sets of information and present them in such a way that it:
- allows us to immediately see how items are related to one another;
- gives us a more immediate way to see patterns;
- becomes a default to try and understand huge amounts of information.
In addition to visualization, Pescovitz touched a bit on how we're using collective filtering to try and make sense of all this data. We turn to social networks we may trust, such as Digg, to take advantage of the filtering layer created by that network’s society. Anything to help us get a head start on parsing the data.
Later on in the conference, Nick Cawthon talked about aesthetics and efficiency in visualization of data. His talk referenced research he had done using different types of data visualization in order to determine what participants thought of the graphic (pretty or ugly) and whether or not it worked (they could complete a task such as finding a file). An interesting outcome was that the higher the user-rated aesthetic, the more reluctant the user was to abandon that particular data visualization. At a basic level, if the interactive graphic was perceived as “pretty”, the user was willing to spend a bit more time trying to learn how to use it.
Fascinating ideas and I know we're just scratching the surface of its potential.
Technorati Tags: Design, Information Architecture, Usability, DUX07
Topics: Design, Design Patterns, Information Architecture
DUX2007 - Simplicity
Too often, the overarching requirement we hear from clients is that the product must be simple to use. As designers, we nod our heads and agree that yes indeed, simplicity is a worthy goal for this project, without ever defining what is meant by simplicity.
At the opening night of the DUX07 conference, B. J. Fogg, from Stanford University's Persuasive Technology Lab, talked to us for a bit via video about his recent explorations into simplicity. What exactly does simplicity mean? What are the determining factors of simplicity, i.e., what am I looking at in order to rate whether or not a product is simple to use?
To Dr. Fogg, simplicity is not a characteristic of the product but rather a perception of the experience. From his studies and research, he's determined there are six elements of simplicity:
- time - can I spend the time learning to use a new product? no? then it's not simple
- money - can I spend money on a new product?
- physical effort - does it require exertion beyond my usual effort?
- brain cycles - do I have to think for a long time?
- social deviance - does it go against the social norm?
- non-routine - does it break my routine?
These six elements vary by individual and by context and there are trade-offs. For example, if I'm a college student who has time but not a lot of money, I might be more willing to invest my time in learning a new product than, say, a business executive who doesn't have the time but would be more willing to spend a little more money on a product that doesn't require a lot of time.
Simplicity, therefore, is a function of the user's scarcest resource at the time. To state it another way: a product, task, etc., is truly simple until it requires a resources that's not available. But remember, Dr. Fogg said that simplicity is determined by the perception of the experience. Which means a task can be perceived as simple if it uses less resources than expected.
Now I'm not saying that from now on we market our products by setting the expectations high to guarantee the perception of simple .... but it sure is tempting.
Technorati Tags: Design, Information Architecture, Usability
Busy. Busy. Busy.
I've been a tad bit busy lately starting up one project and entering the UAT phase of another. More importantly, though, I'm still alive in my Pick a Loser football pool (for those of you keeping track, Arizona kept me in the game). In the meantime, here are some links you may or may not find interesting -- click away at will:
- Too often, implementing search engines within a project are an afterthought rather than a well planned feature. Read up on Strategies for Improving Enterprise Search to prevent having a "neglected orphan" in your project.
- Not sure how to break it to the Marketing Director that the approved brand colors just don't translate well on the web? Don't Let Branding Kill Your Brand gives you some useful discussion points for extending the brand experience.
- It's all about the Experience, my friend. Peter Merholz explains it best in Experience IS the Product.
- Designers Rule! 'nuff said.
iPhone and Air Travel
I just might need an iPhone. Let me back up a bit. When the iPhone debuted, our CEO purchased one for the office so we could take turns using it, playing with all the features, admiring the GUI and generally looking cool at the local neighborhood hangout. I loved it but not enough to buy for various reasons (couldn’t use one hand to hold and type, didn’t fit in jeans pocket, too nice to just throw in the bottom of my purse, no iChat). So, I looked cool for a weekend and then turned back into regular me come Monday.
Well, the other week I was 'lucky' enough to once again experience early 21st century air travel which, as you know if you’ve traveled lately, means delays, delays, delays. The plane is late, the crew didn’t show up, the gate changed, the gate changed again, it’s sunny outside, it’s the third Tuesday after the fourth week following the geese flying south, etc, etc.
Luckily I was traveling with my CEO who had the foresight to bring the iPhone. Which led to my iPhone epiphany: when you’re stuck on the tarmac hoping that #49th in line isn’t really as bad as it sounds, surfing the web is a much better distraction than counting the planes as they’re taking off. And surfing the web on a cool device just adds to the sweetness.
Thanks to the iPhone and EDGE network (as slow pokey as it is), even when sans wifi I can still waste a considerable amount of time checking email (personal not work), checking faa.gov (for further delays), catching up on some reading (love Safari Books), using the widget to check random cities forecasts (because I can) and generally doing most anything to avoid pulling out my laptop and doing meaningful work. Beautiful! If I continue to travel (which really means sitting on tarmacs bored to tears), I just might have to pull out the old credit card and contribute to Apple’s bottom line.
For an actual review of the iPhone, check out what my colleague had to say.
Technorati Tags: iPhone
Get in the Flow (Task Flow that is)
Call them what you like (task flows, work flows, process flows), flow diagrams are an important part of any software project. As a developer, you may be more familiar with sequence diagrams, a nifty way to visualize an exchange of messages between different processes and the order in which they occur.
Well another useful diagram is the end-to-end task flow. This handy dandy diagram shows all the steps necessary for a user to accomplish a task. Buy a pair of shoes? Select shoes, select size, add to cart, go through checkout process. Simple and easy.
And yet, what is it really telling you? Well, a flow diagram gives you an overview of the end-to-end process, the start to finish if you will. It lets you know what the user needs to do in order to start a task (select those really cool shoes) and what defines that the task is completed (display order confirmation). In between those two points are all the necessary steps to go from start to finish.
Initially, the in betweens are very high level (as evidenced by the above diagram). As more information becomes available, the flow is modified, added to, subtracted from and generally redrawn to show not only the user tasks, but also the system tasks (return error message, validate and continue), alternative routes (continue shopping, display upsell message) and decision points.
I've found flow diagrams to be very helpful because they let team members know how their stuff fits into the big picture. Let’s face it, on most projects the end-to-end flow is never developed lineally by one developer. Instead, it’s broken down into pieces and parts and assigned to various people. Seeing the end-to-end diagram up front gives you the overall picture of how an entire feature will play out and, more importantly, shows you how and where your piece fits into the whole. It'll get you thinking about potential points where code can be reused (sweet!) or better ways the data can be used at the presentation layer.
End-to-end diagrams let you see that what you're working on is no longer a lonely story in isolation, but rather something that’s part of a defined sequence that contains a beginning and middle and end. It ties what you're doing into the whole and brings a coherency to the process. This is especially valuable for large features that are spread out across teams and even iterations.
Technorati Tags: task flows, information architecture, diagrams
Personas and Football
This year I’m once again in the Pick a Loser football pool*. Each week, I pick an NFL team that I believe will lose and if they don’t lose, I’m out of the pool. So, for example, the first week I selected my team, the Chicago Bears, to lose (so much for fan support). They complied so I'm still in play. I can only select a team once; therefore, da Bears are off limits for the rest of the season (even though I’m fairly confident they’ll lose another game or two).
My point here is not to kvetch about our quarterback (don’t get me started) or our running back (oy), but to mention that once you Pick a Loser, you start experiencing the NFL games a bit differently. It’s not that you’re actually outright rooting for them to lose (poor sportsmanship, old bean, not at all done), but you begin to look at which team excels in mishaps, penalties, and/or position weakness, or which team is thrown off stride by an unexpected change in personnel, and how you can exploit that to ‘win’ that week.
In other words, when picking a loser I am adopting a different persona than when I pick a team to win. I have different goals and objectives, looking at the stats (data) differently and end up going down a different path (workflow) to make my selection.
This, my friend, is the point of having personas on a project. You use them to identify the different ways a user needs to interact with your product -- their point of view determines the different paths and interactions they need to take in order to achieve their goals and objectives. Once you know the different points of view, it’s a lot easier to design a flexible workflow that accommodates your users. A win-win for all.
As for me, I survived week 2 (the Chiefs in case you're interested) and now need to figure out my week 3 loser.
*disclaimer: naturally for all the kiddies out there, you should never try this at home because gambling causes your hair to fall out
Technorati Tags: personas, user experience, design
Powered by ScribeFire.
Design Doesn’t Just Mean Color
In discussing our SDLC process with some colleagues, I pushed for having a separate phase between Discovery and Development; a phase where we can take the knowledge gained from Discovery and begin sketching out high-level solutions in order to get a handle on the scope before going into iteration planning. In other words, a Design Phase.
I quickly discovered that some people hear the word ‘design’ and automatically associate it with the look and feel of the GUI, regardless of what else is being said. Until I understood that, their argument that there was no need to call out an entire phase for design made absolutely no sense. To me, using design in this context means to figure out how to do something at all levels, i.e., taking the requirements (Discovery Phase) into high-level schematics (Design Phase) to better understand their relationships, dependencies and impact in the end-to-end process. Obviously, I hadn’t explained that well.
Much conversation ensued, including the standard weeping and wailing and clutching of the pearls when passionate people get together. Amazing how we were all speaking English and yet totally missing what was being said. Until someone (the former English major, of course) effectively put us back on track by saying “Ok, but what do you mean by ....”
Ah-ha! Define the terms. With a BA, IA, and Tech Arch conversing, we found we were using the same terms to mean different things and different terms to mean the same thing. Well once we started speaking the same language, we agreed there is merit in having a separate phase specifically for design and revised the diagram accordingly. As a team, we were then able to define what that means to our process.
I could say that as a team we designed our SDLC process, but I’m not even going to go there.
Technorati Tags: SDLC, Application Design, Design Phase
Topics: Best Practices, Design, SDLC
About Pathfinder
Recent
- Firefox Plugin Malware ‘Trojan.PWS.ChromeInject.A’
- Pathfinder releases version 1 of the its Flash Platform microsite (codename Mica)
- Pimp my Rails: Five Plugins & Gems to Make Rails Better
- iPhone: Using Pre-processor Directives for Device Testing
- Subtle OpenGL Projection Matrix Difference Between iPhone Simulator and Device
- App Security: Throw Out the Org Chart!
- Pimp my jQuery: Five plugins to replace the features Prototype and Scriptaculous users expect
- Thanksgiving 2008: What We’re Thankful For (In Rails)
- iPhone SDK: Testing with TextMate & GTM
- GWTQuery - JQuery-like Syntax in GWT
Archives
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006
Topics
.NET
2d physics
3d
3D GPS
3D physics
37signals
Accessibility
actionscript
activerecord
acts_as_ferret
Add new tag
Adium
ADO.NET Entity Framework
Adobe
Adobe AIR
Advertising
agile
Agile Development
AIR
Ajax
Ajax Applications
Ajax Bookmarking
Ajax Components
Ajax Development
Ajax Examples
Ajax Experience
Ajax Frameworks
Ajax history management
Ajax Intervention
Ajax libraries
AJAX Obfuscation
Ajax Performance
Ajax Products
Ajax Tools
Ajax Widgets
Amazon
Amazon CDN
Amazon Web Services
amf
Analysis
Android
Announcement
Announcements
antennae
Apollo
apple
Application Architecture
Application Development
architecture
AS3
ASP.NET
Asynchronous Processing
authorization
awards
Azure
Back Button
bandwidth
bandwidth profiling
Benchmarking
Best Practices
BitmapData.draw
BJAX
Blaze Advisor
blog
blogging
Books
Browsers
Business
Business Reasons for Ajax
Business Rules
C#
caching
Canvas
Case Studies
Charles
chess
Chesspresso
Chicago
Cloud Computing
CloudFront
CMS
COBOL
code
code art
Code Generation
Color
COMET
Conference
Confluence
Consistency
Content Management
CRM
CruiseControl
CSS
Custom Flex Component
data visualization
Degrafa
Design
Design Patterns
design thinking
Desktop
Desktop RIA
Developer's Notebook
DHTML
Diagnose
Dojo
Domain Knowledge
Drools
EC2
Echo2
Echo3
Editorial
ERP
Ethnographic Research
events
externalinterface
Ext JS
Facebook
ferret
FileReference
Firefox
Firefox Extensions
fixtures
Flash
flash awards
Flash Platform
flash player
flash player 10
Flex
flex css
flex skins
flexunit
Flickr
Flock
Flow
Frameworks
FriendFeed
front end
front end development
fulltext search
Games
Gauge Component
getting things done
Git
Google
Google calendar
Google Gadgets
Google Gears
g phone
Grails
Graphics
Greasemonkey
Groovy
GStreamer
GTD
Gwittir
GWT
hardware
Healthcare
Hibernate
HTML
Hudson
IDE
Ideation
IE
IE6
IE7
IE8
iGoogle
illustrator cs3
ILOG JRules
importing graphics to flex
Information Architecture
Innovation
Instructional Design
Interaction Design
interaction patterns design
Interview
iPhone
iPod
iTunes
Java
Javascript
JavaScript frameworks
Javascript Libraries
JBoss Rules
Jess
Jetty
JIT
Jobs
jQuery
JSF
JSON
JSP
JSR-94
JsUnit
laptop
Lazlo
Legacy Systems
lightweight
LinkedIn
LINQ
logging
Logical Model and Conceptual Model
Low Pro
Mac
Malware
Mash Note
Mashups
Meebo
MetaWidget
Methodology
Microformats
microsite
Microsoft
minimalism
Mobile
modeling
Mootools
mouse
mouse scroll
mouse wheel
Mozilla
Music
MVC
MySql
NetNewsWire
notebook
obj-c
Object-Oriented
Object Relation Mapping (ORM)
Office
OOP
Open Screen
OpenSocial
Open Source
Opera
Oracle
ORM
osx
pagination
Pair Programming
papervision3d
Patterns
Peer Creation
Performance
Personas
PGN
PHP
physics
physics engines
plugin
preloader
process
Web/Tech
Product Definition
productivity
Progressive Enhancement
project management
Project Website
Prototype
Prototyping
PV3D
QA
qooxdoo
Radiant CMS
rails
Really Simple History
References
Requirements
Requirements
Alice Toth
Requirements Visualization
resesign
Restlet
RETE
Review
ria
Rich Interactions
ruby
rubyamf
Ruby on Rails
Ruby on Rails testing role
S3
SaaS
Safari
San Francisco
Scalability
Scenarios
Scriptaculous
SDLC
Search
Security
Selenium
Semantic web
SEO
Server Side
Silverlight
skins
SOA
Social Networking
Software Processes
Songbird
SpiderMonkey
Sprajax
Spreadsheets
StageScaleMode
Standards
Startups
STI
Story Telling
Struts
Tamarin
Task Flows
Test Driven Development
Testing
textmate
The Ajax Experience
throttling
Tilt Component
Tools
TraceMonkey
Training
Trends
Tumblr
Tutorial
Tutorials
Twitter
UI
UIViewController
unit testing
Unit Tests
Usability
Usability Testing
User Experience
user experience design
user interface
User Interface Standards
User Research
UXD
Venture Capital
Video
Vision
Visualization
VLC
Volta
Web/Tech
Web 2.0
Web Design
Web Development
Webkit
Weblogs
Web Services
Web Standards
Widgets
will_paginate
Windows
Wireframes
WordPress
workflow
work life balance
xcode
XML
XML Metadata
XUL
Yahoo Map AS3 API
YUI
Zeigarnik
Zeigarnik Effect
ZK