Hold on to Reality: Restrain Your Creativity And Your Feedback

Limit Yourself

Tip 1: Limit Your Possibilities

Based on our experience with our newest project, Bubble Browser, a visual browser for Evernote notes, we wanted to present our approach to implementing innovative solutions in applications. The assumptions we held throughout the development process allowed us, a group of five, to create a stable, and in our opinion, conceptually revolutionary, product in a little over six months.

What advice can we give you to help you efficiently deliver a program to the market that features an innovative solution? If you want to be creative and complete an application within a given timeframe, you have to establish clear and strict limitations on every level: analytical, functional and, most of all, creative.

Tip 2: Watch Out for Excessive Creativity

Many software designs share a problem we don’t like to admit: the impossibility of their completion. We can only make guesses based on our experience, and that of our colleagues, how many promising concepts were scrapped during various stages of development, testing and functional verification. It is not uncommon to hear bitter conversations amongst application designers in which they complain about failing to deliver their products to the market because of this. No one records the statistical data on unfinished projects, but, being a part of the application designer community, we know that it is a common problem.

It’s obvious that technology offers us virtually unlimited creative possibilities. Everybody knows this and everybody gives in to its creative potential. Tools that are used in application development (we chiefly use OmniGraffle, Slicey, Skala, Trello; occasionally Basecamp; and, of course, Adobe CS) are increasingly intuitive and relatively simple to use. We have – and have always had – many talented software engineers, developers and designers (and, contrary to the theory of “the age of creativity”, this hasn’t changed in recent years – we’ve always been surrounded by talented individuals).

Tip 3: Don’t Give in to The Terror of Innovation and The Allure of Technology

Used as a buzzword to describe any nonstandard idea, constantly emphasized, imprecise and unclear, the word “innovation” tempts and increases the feeling of partaking in something special – ultimately, we’re creating contemporary technology, and the need for innovation is the basis of all our good decisions. However, it is also the basis for many of our mistakes.

Why is it that, despite a favorable work environment, we (as the software designer and developer community) do not finish so many projects or cease working on them half-way through? How can we fight the terror of innovation and creativity that slows us down? What can we do in order not to allow our desire to create a “total application” to change our design into a multi-headed monster that will eat us up along with our budget, emotionally burn out our coworkers, and, finally, will force investors to change their line of business and return to “safer” and more traditional solutions, which have worked in the past?

Quickly Create a Prototype and Get Feedback From Actual Users – The Origins of Bubble Browser

Bubble Browser is an application that was created for the purpose of Evernote’s international Dev Cup 2012 competition. Naturally we wanted to win, but we knew from the beginning that our primary goal should be providing of a working prototype as soon as possible in order to get feedback from our users – even if we risked releasing a partially unfinished product.

Tip 4: Limit The Number of Innovative Features to a Minimum

Nothing is more frustrating and damaging to a team as a period of time-consuming work that yields no visible results. We knew from practice that in order not to burn ourselves out when perfecting a product for a longer period we should minimize the amount of solutions we wanted to include from the start.

Although we had many ideas for additional features, we decided to limit ourselves only to one main purpose of the application: browsing notes. Bubble Browser was always supposed to be a browser – nothing more, nothing less. As we had time restrictions and did not want to get lost in creative concepts we decided only to introduce one innovative element unknown to users previously, that is bubble browsing.

Six weeks after we started working on the app, we had a fully-functional, though still underdeveloped (both creative- and design-wise) prototype. Version 1.0 was accepted by Apple and included in the Mac App Store, and within three months it circulated the globe and was tested by hundreds of users.

Actual users provided us with feedback that allowed us to impose the precise limitations we desired. Thanks to our decisive work process and the fact that we purposefully left the software’s functional side and design incomplete, we managed to skip the time-consuming phase of testing the application’s functionality.

On February 20th, 2013, Evernote published a shortlist of the best Dev Cup 2012 projects. We are proud to have been featured on that list. This also convinced us that the project is worth perfecting. http://blog.evernote.com/blog/2013/02/20/the-best-from-devcup-2012/

Tip 5: Limit Creativity, but Make The Work Process More Flexible

It’s very important for us to keep the work process flexible and to allow for the fast change of priorities. Project management is a primary issue, but, for efficiency’s sake, the work process cannot be rigid and linear.

In order to maintain the flow, flexibility and nonlinear quality of the work process we used Trello, an Internet-based tool for project management. Trello allowed us to objectively keep track of our work progress, the number of various concepts and the flow of information between developers and designers. As a program that originated from the Kanban method (a scheduling system for production), Trello ideally supported our idea of limiting creativity and making the work process more flexible. It also could be used as a visual aid for the GTD (Getting Things Done) methodology.

Furthermore, as followers of the Manifesto of Agile Software Development, we tried to employ its four principles (the fourth point was not a focal concern in this case, as there was no direct client):

  1. Individuals and interactions over processes and tools;
  2. Working software over comprehensive documentation;
  3. Customer collaboration over contract negotiation;
  4. Responding to change over following a plan (in this case Evernote was our indirect “client” and, in practice, the supplier of data).

When designing Bubble Browser 2 the following points were most important for our tasks:

  1. Analyzing user feedback and prioritizing it according to the difficulty level, time consumption and innovativeness (meaning a solution that the users have not considered) of the proposed changes;
  2. Determining the bare minimum of changes that would render the application more efficient, so as to not revolutionize its concept;
  3. Deciding on flexible project management tools;
  4. Distribution of responsibilities amongst the design team, and designating one person to keep track of the creative constrictions and to manage the flow of the project’s progress.

Tip 6: Don’t Employ Every Suggestion You Get When Designing an Application

After receiving information on the needs of our users we could revise the assumptions of our project and proceed to the main work phase for version 2.0.

The feedback we got showed us what features were expected, but we decided to minimize the number of changes and improvements, and not to give in to the pressure of creating an app that will unquestioningly address all user needs. Listening to user opinions naturally is important, and it gives you the chance to broaden your perspective, but it nonetheless is imperative to distinguish between high-priority needs and those that can wait. We considered those most important that allowed us to streamline the application, but without drastically altering its concept.

How to Introduce Innovative Solutions?

Tip 7: Introduce Innovative Solutions Only in an Environment The Users Know

Most of our solutions related to user experience are based on the guidelines developed by Jared Spool. Jared Spool demonstrates how a designer should think in order to create a useful, intuitive product. The main issue that Spool emphasizes is that it is not the design that is supposed to be intuitive – it is the users who act intuitively when using the software. The design has to be thought out in such a way as to help in this matter, and, if the need arises, to inconspicuously train users.

The user’s intuitive activities are an individual issue and, according to Spool, are closely related to two issues:

  1. What people already know when they start using the program; in other words, their entry knowledge;
  2. Previous similar experiences and how do they impact their perception of the application.

Taking into account the fact that the perception of most users is normally limited to what they are already acquainted with, we, as designers, have to predict which elements the users will recognize, and which they will have to be taught.

Jared Spool discerns two types of user knowledge: current knowledge, that is the knowledge a user already has, and target knowledge, the knowledge one needs to use a given program or application at full capacity. The space between them (the knowledge gap) is to be covered by a well-thought-out and intuitive product. Assessing the current knowledge of users, that is recognizing and analyzing their previous experience, can greatly help in the determining of the required target knowledge.

The purpose of this analysis is to minimize the amount of new knowledge that the user has to obtain in order to use the application. Obviously, an ideal situation would be one, in which this comes naturally, and one’s previous knowledge would be employed when using the application. So all the new elements of Bubble Browser 2 had to meet two basic goals: improve the prototype and make use of the elements and environment that the user is already accustomed to. Users can’t start from scratch, and we had to help them navigate through the application with their current knowledge. One of such elements that makes use of this is, for example, the omnifield, a text-based query box at the top of the screen similar to that in which users type in website addresses or submit queries in Internet browsers. We made the assumption that users will quickly understand the principle of the omnifield by analogy to similar solutions. An additional element that supports this connotation is the use of the term “browser” in the program’s name itself.

We considered three elements of the UI as relatively well-known and facilitating the use of our app:

  1. The omnifield for browsing, an element known from internet browsers;
  2. Thumbnail previews of note content;
  3. Note content presented in a linear way common in browsers, word processors, and Evernote itself.

The use of accessible elements in an environment that users were acquainted with allowed our innovative use of bubbles to browse data to be a straightforward means of conveying information and facilitating navigation for those, who haven’t used Bubble Browser previously. In this way, even more so than in version 1.0, we created an accessible environment for learning how to use the application efficiently and intuitively.

Evaluation

Tip 8: Analyze Application Reception and Its Assumptions

On the 21st of March the newest version of Bubble Browser was made available in the Mac App Store. Of course mistakes were made, both in the application itself as well as in the work process. But we handled them promptly with a frank and direct attitude that allowed us to complete work without significant delays. We believe that the system of extensive limitations we imposed allowed us to develop an efficient way of delivering a product with a limited number of people on the design team without any holdups and without overinvesting.

As we care about feedback and how people evaluate our software, we would like to hear from you. Take our app for a spin and let us know what you think. We would like to verify whether our assumptions work in practice and whether the aesthetic and functional minimalism allows for intuitive use of the software.

This post was first published on UX Pin Blog. http://blog.uxpin.com/2009/hold-on-to-reality-restrain-your-creativity-and-your-feedback/

Bubble Browser for iPhone/Sensus and How We Designed for a Device We Had Never Seen