Adobe Locale Mobile App

WHAT WAS THE DESIGN PROBLEM WE WERE TRYING TO SOLVE?

Adobe Locale is an expansion of the Adobe Creative Cloud Mobile App Suite, and is meant to play along with their current line of professional photo/video applications like Photoshop, Lightroom, and After Effects. By searching for keywords, specific cities, or areas of interest, this platform delivers remote scouting information to photographers/videographers, allowing them to easily identify the perfect spot for use in an on-location shoot. Locale will allow photographers and filmmakers of all skill levels to both locate and contribute to the world’s most robust resource of photo or filming locales, creating the perfect environment for their shots.

Throughout this project, we were specifically looking to explore app functionality and user experience, with a primary focus placed on the interactions within and between screens.

WHAT WAS OUR PLAN OF ACTION?

We approached this effort in a similar way that we approach all design problems, in four key phases: Preparation, Planning, Execution, and Iteration.

Phase 1: Preparation

In the preparation phase, we started out by drafting a project brief. This brief helped guide us when making user-based decisions throughout our design journey. Within the brief, we defined important criteria, such as who our client is, who our target end user might be, main functionality of the application, and platforms that the application might be available. We also conducted competitive analysis to understand what competing apps might already be available, determine their strengths and weaknesses, and build upon those ideas. Through this exercise, we also created a persona for our target user, discussing their background and preferences (shown below). Click here to view the full project brief.

Phase 2: Planning

In the planning phase, we took the ideas and functionality established in the project brief and created an outline for our screenflow. This started with hand-drawn sketches that allowed us to quickly maneuver and adjust screen placement as desired. We then expanded and solidified our screenflow diagram into a more polished and informational document. This document should be used by stakeholders and front end developers to visualize the user flow of the application, and allow for additional questions to be asked and answered.

After establishing a finalized screenflow, we moved on to creating the wireframes for our application. Again, through iteration, critique and user feedback, we developed a visual representation of each screen in the app. Alongside visuals of the screens, we added annotations to describe any intended interactions or special features. A single representation of those wireframes is shown below. Click here to view the wireframes in their entirety.

Phase 3: Execution

Throughout the execution phase, we developed a high-functioning interactive prototype, where users and stakeholders alike, can click, drag, swipe, ohh and ahh at an experience that should be pretty close to the app’s intended final functionality. One of the advantages of creating the prototype within Sketch and InVision, is that handoff to development is very seamless, with the added features of the Inspect Tool. Not only can developers see how an app is intended to function, they can obtain pre-coded components, directly from the platform. This helps with any communication gaps, lack of documentation, and bringing down the overall development time. This was the most time consuming portion of the project, but yielded incredibly valuable results (as referenced in the results section below).

Phase 4: Iteration

A good design sprint is never complete without multiple rounds of iteration. From this phase, we often cycle back into the execution phase, in order to solidify and improve the execution of our product. This project was no different, and was reviewed and critiqued by a team of design and UX professionals along the way. Although this adds to the timeline of execution, it is a valuable part of the process, allowing for diverse perspectives and additional creative input. Our iteration efforts caught several interaction misses or mistakes, that were quickly able to be amended before the final project was submitted.

WHAT WERE OUR RESULTS?

The results of our efforts concluded in an optimized interactive prototype, highlighting the primary functions and interactive elements of the Adobe Locale mobile application. A prototype of this type could now be used for product proposals, stakeholder buy-in, development assistance, customer feedback, or even usability studies.

Our prototype rounded out at 200 pages, and has been carefully crafted to represent what we believe is a solid user experience and potential product for the Adobe line of personal creative applications. Due to the fact that our prototype was created utilizing InVision Studio, we are unable to successfully embed the prototype within this post. A full demonstration of the interactive app is available on InVision. Feel free to click around.

WHAT WERE SOME OF THE LESSONS WE LEARNED ALONG THE WAY?

1. Knowing When to Say “When”

How many screens should we show? How many interactions are necessary per screen? Which screens and interactions need to be repeated? These are some of the challenges we faced when creating the Adobe Locale prototype. Although many of the screens and interactions throughout the app are common, expected, or understood, we decided to lean on the approach of “more is more” when developing this prototype. We tried not to cut corners and create a fully functional realistic prototype. This increased the initial load on the designers, but should decrease the backend development time. Some of the areas we chose not to make fully interactive were pages that exist on the Adobe Web environment. Were we to continue to iterate and develop a fully realistic app, we could link the prototype directly to those web pages. However, for the sake of time and consistency with the remainder of the prototype, we chose to redesign those pages in a scheme that followed the remainder of the app, and represent their functions in a minimal way, allowing users and stakeholders to focus on the primary intentions and functions of the Adobe Locale app.

2. Expanding Knowledge of Platforms & Programs

For this project, we utilized a multitude of Adobe products, Sketch, InVision Studio and the InVision platform to develop our product from inception to completion. One of the most informational portions of this entire exercise was the ability to review, demo and examine additional UX platforms and programs that our team was not as familiar with. Adobe XD, Axure, Proto.io, and Flinto were all reviewed and considered. Each platform had pros and cons, some with very enviable functions and features. In the end, we chose InVision for its expanded line of products, integration with Sketch, and the ability to quickly hand off to development.

3. The Value of Good Critique

As mentioned above, critique is a valuable part of any design process, however, good critique is a highly-developed skill. Good critique leads to open conversation and decision-making. Good critique is kind and offers suggestions for improvement, rather than disparaging design decisions. Good critique offers room for push-back, in the event that a decision was made for a specific purpose. Good critique always seeks to uplift the product and not cut down the designer.

If you have any additional questions regarding the Adobe Locale application or ChadCo. Studio’s services, please refer to our Contact page or email us at info@chadcostudio.com.