Task At Hand

My partner and I established rules as we thought through the process - all based around the hypothesis that the interface should only show necessary options for the task at hand. As our client’s consumers were asking for more features - we were attempting to keep the experience simple. How do we offer all the features that consumers want without flooding/crowding the workspace? The tasks were broken down into four parts of a mental model:

• Seek - Users are looking for an asset/folder. We broke this down to browsing and searching types.

• Select - User select or engage with an asset, groups of assets, or section.

• Review - User looks at the collection of assets to upload/download/edit.

• Finish - User completes the action.

The interface, architecture, and flow of the product followed this, almost literally.

Simplification

Throughout the designing process, we modeled the experience after principles that allowed us to keep a action-oriented interface without compromising the constant request for more features that would only satisfy a small population of the client-base. These principles were:

• Combine - Some features had very similar functions and could either be combined or put into a deeper menu of similar tasks.

• Conform - For some features, we conformed to existing industry standards, or found parallels in other product types that could inform us.

• Omit - Really looking at analytics, we were able to omit or hide features that were not being used for particular tasks

• Organize - We would look for patterns or recognizable standard behaviors to model the interface after.

• Enhance - We looked at the high-traffic features and built them up. For example, the DAM system houses mostly visual assets. It made sense to us that the search feature should be able to search by asset color.

The interface, architecture, and flow of the product followed this, almost literally.

A Moment of Ambiguity

Throughout our research/discovery process, we continuously looked at our competitors’ products. In them we couldn’t find the answers for one particular problem. We searched for instances of the problem in other industries and it was difficult to find parallels. Should the experience be the same for users who are transferring small assets (e.g. 10MB), opposed to user who were transferring large assets (10TB)?

With no precedence, we role played the scenarios in an attempt to make the experience scalable. Some findings were:

• Expectations Management - There should be some sort of warning to show that user is about to undergo a large undertaking - to manage expectations - we designed a color-coded meter to show load size.

• Noticeable Progress - A load bar for a 20TB moved too slowly to show progress - we needed another method of visual queues to show constant progress.

• Time Wisely Utilized - A user is not going to sit idly by as they wait for this upload/download to be finished - so some sort of alert was needed, and/or the function of being able to input meta data for the files while they waited.