A good tool should solve problems without creating new ones, but the more tools we implement the less likely they are to play nice together. Dirk Swart led development of Cornell’s Digital Well interface to solve this with a simple, in-house developed application that today allows Cornell’s numerous marketing professionals access to a full collection of multiple asset repositories from a single page. In his presentation, Dirk reveals not only the lessons learned from designing the project but also offers insightful tips for how to work with users to be sure you’re creating the best tool for their needs.
The Challenges
Multiple information sources about a subject may exist in multiple repositories and formats, and the parts that need to be together may not always exist together. A photo may be found in an image database with image exif data or basic meta data, but the caption information of who is in the photo, the context of where it was taken may be in a word document in a press relations archive, and the print use history could be in a separate database somewhere else.
Users may not know where resources exist, or even that they do exist in the first place, and each repository system likely has its own unique login requirements which further slows or possibly prevents access for users. For marketers on campus who are pushing information to all forms of media all the time (blogs, news agencies, social media) if it can’t be passed on easily then facts can be missed which leads to inaccurate press releases or stories in the wild.
“Nobody cares where it’s stored.”
The first real “a-ha!” revelation of Dirk’s presentation was making it clear that users really don’t care where their assets are stored or even how. Only two things really matter to the user trying to piece together marketing stories:
- Can I find it?
- Can I find it again?
The Digital Well solves this by connecting to information that is already out there. It doesn’t store any assets itself but rather strings related assets together into any kind of collection a user wants. Building an updated story about the chair of the history department’s new book? Search their name, or just the history department. Grab the previous bio document on the chair here, grab their headshot here, bring in the book cover image here, and add the link to that video of the chair’s lecture on the book subject last spring from over here, and do it all from one single-page interface using simple drag and drop and tag operations. When your story is published online and the press release is complete, those will be new assets that others can use the next time they go into the Well.
Dirk points out that despite prevailing practices, the user interface for these tools do not have to be the same for putting information in as it is for retrieving information. They are two very different operations, and because the Digital Well is not a meant to be a storage utility, why not focus on a simple to use interface optimized just for retrieval? Users think differently about retrieving information than about submitting information. We retrieve information 1,000 times more frequently than we contribute – just consider how many times you’ve looked up information on Wikipedia versus how many times you’ve contributed to Wikipedia.
Dirk is also adamant that developers should never ask people to enter information that you can enter yourself. You can already fill in who a user is, their title, their department, what they’re uploading and when, how large it is, what format it’s in. There’s no need to waste a user’s time filling that out. The first time a user logs into the Digital Well, it recognizes their ID and automatically creates their profile, groups them in with others who share their title (photographer, writer, editor, etc.) and gets out of their way. Welcome to the Digital Well – what are you looking for?
Develop From User Stories, Not Feature Requests
Dirk’s team avoided a lot of development headaches by taking a different point of view from the start of development:
“Don’t ask the audience what they want in a tool; ask them what they need to get done everyday and build that.”
Dirk’s team reached out to some of the potential users and simply asked them to share a story about how they currently do the work that they do. It’s hard for users to envision a future different from the present accurately, so what may seem like a good feature idea could in practice end up being a distraction. And designs that are objectively better are still not going to make people use them if their used to a subpar convention.
“It’s even harder to change peoples preferences than you think it is.”
Ask people to tell stories about the issues they have, share their difficult scenarios. “Tell us what you want to be able to do in an abstract level and we’ll worry about how it works,” Dirk told them. Then his group simply collected these stories and built a simple chart that extracted the similar features from multiple narratives to define the features needed for their application.
Ease of Use Trumps All
Once the key needs and features of the tool were identified, the application development was is not out of the ordinary from a programming architecture view, working with the system APIs of various repository systems to allow dynamic links to be made and stored and their relationships coded.
Dirk points out the recent rant on making information findable from Google programmer Steve Yegge that covers a lot of important thoughts about what should be taken into account when approaching projects like this, but when it came to the GUI development and user operations involved the Digital Well had to not only work easily but also exist simply.
“If form doesn’t follow function it follows fashion” is an old phrase that really works. The Digital Well is just one page. No top top navigation or pop up menus or tabs. Side bar tools and filters are quick to implement and the center content area can scroll endlessly as a user builds their collections. No navigating from one page to another for actions, no cutting and pasting. Just clicking, dragging, dropping, or typing search terms is all that is needed. Results are found through popular tags, filtered keywords, personal tags and ratings.
Another powerful feature is the ability for any user to select other users to follow. This means a writer can follow the photographer who will be taking the shots you need of that new building, and when the photos are posted that new status will be at the top of the writer’s feed when they log in. The total number of users currently in the system is limited to marketing team staff of ~220 at Cornell’s 78 units. And everything created in the system is visible to all users in the system to use.
Digital Well has proven to work for as a tool for communicators, providing efficient reusable content for directly from the source. Dirk hopes that they can work with Cornell’s legal team to allow sharing an open source code for others to start using.
Lessons Learned
Most people think they know what they’re talking about and think they know what they want. Learn from the stories they share instead. Remember the KISS rule (Keep It Simple, Stupid) – 95% of the time can keep all information on one page or you’re doing it wrong.
Remember that changing the way people work is HARD but results can be “so much win.” Dirk gave his boss talking points regularly that he could use for evangelizing the project among administrators and get buy-in. Given the 2-3 months of a typical attention span, the printed talking points helped keep momentum going on the development.
