Argo Nav

• Fab implemented as a way to drop pins on the map.
• Depth detail page that also provides valuable information even if you do not have a course laid in.
  • Page also intended to incorporate other APIs for weather & tide information.
• An extremely simple interface for basic directions. There are no roads and we wanted to provide verbal directions but it was out of scope.
  • We also wanted to adjust ETA’s and directions based on an averaged speed. The initial ETA would be based on what the user put as their average speed in their profile.

• In our research, we noticed that many other app maps were cluttered resulting in a cognitive overload for users.
  • Users wanted information but not to be overwhelmed. By creating categories we let users organize and filter their maps to provide them only with the information important to them.
• We decided to store the “voyages” the user had taken and the “places” they had gone.
  • They then had the option to share these or simply select a voyage or a place and go there again!
• Manual routing was something we planned out but did not implement until much later.

• The prototype was tested in Maryland only.
  • About 1/3 of users signed up and where remote while the rest were split between users at urban & more rural marine stores.
• Prototype feedback was generally positive.
  • People found the technology interesting, fun, and easy to use but in general, there was not a sense of need or urgency around the technology and it’s capabilities.
• Many users simply explored with no navigational aids even if they were available.
• Many users also expressed that they had regular spots they had been going to for years and would not somebody finding their, “secret spot.”

Communicating the importance of setting up the needed tools to acquire user data was no small tasks and took time but was well worth it once implemented. Not only does the team now have access to valuable insights, but we are also able to send out automatic notifications when X amount of time has passed between certain events leading to a better and more connected user experience.

The term MVP gets used alot and many entrepreneurs who have read the book, “The Lean Start Up” do their best to implement the ideas put forth in this book.

Like many things, the concept and the idea of an MVP are much easier said than done. On this project I learned a ton regarding how to implement minimal features and iterating upon those features. I learned enough to know I did not always get it right and found that communicating these ideas to stakeholders successfully also requires communicating exactly what we will learn from doing it a specific way and why it is better than the other options on the table. Communicating an idea and the data that supports it is simply not enough. A story must be told for each possible way of doing it with each eventuality with your pros and cons hopefully extremely clear. Depending on situation and resources however, this is not always possible.

I also found that if you know part of the experience needs to be. It can be best to implement it 100% or as fully as you can. Not doing so can make it difficult to learn from your users. If you make an experience 1/3 of what it should be, then you know exactly what your users are going to say about an unfinished experience. At this point you are not learning much if anything at all and it is best to get it to point where you can learn something new, or test and assumption or hypothesis.