For a year or so I commuted by Ferry across the San Francisco Bay. It's a great way to get to and from work. They even have a bar on board. The "unenjoyable" part of the trip was timing your departure so you were not too early or actually missed the boat. This involved either memorising the schedule or constantly referring to the timetable. So, being the inquisitive, status quo bashing soul that I am, I set about to see if I could make this easier. And it all started by looking at tables.
Tables are a very traditional method for displaying data, and have been around way before computing. This is a good thing, as familiarity lowers cognitive load (Nielsen). The opportunity I saw was this... Yes, the table holds the information I want (when does the next ferry leave), but it also holds a lot of other information that is not necessarily relevant to me at the moment, which increases cognitive load. I am going to try and weed all of that out.

Traditional timetables:

---

---

What if there was a way to give the user the exact information they were looking for, relative to their immediate need, without making them mine a table for the answer.

My first thought was, these bits of data sitting inside these tables, they represent moments in time. So, why don't we try and represent them as just that. I sketched up this idea for a clock based schedule and thought to myself... genius?

I'm a fan of guerilla testing. Find whoever you can, as often as you can, and observe them. Don't script the questions too much, and let them lead. You will be amazed what you discover. After the first rounds of testing, one thing was clear...

---

---

People are very familiar with how a clock shows a singular moment in time, but putting multiple moments on a clock face did nothing but cause confusion. It wasn't quite back to the drawing board though. There were two elements on the screen that users immediately associated with. I was presenting "time to departure" and "distance to terminal" at the top of the screen. This was seen as very useful information. I started testing all sorts of variations of these two themes. The more I drew, the clearer the solution became.

As things evolved, the "time to departure" / "distance to terminal" idea became a solid approach.
The next step then was to get some working prototypes online. I chose proto.io as the tool of choice from many options for this task.

---

---

I'm focusing on ideas, not details. I can start filleting once I get it's head off. It's not the greatest analogy, but it's how I work.

Prototyping, like testing, should be approached like training for a contact sport. Just keep at it. You will get there with repetition, determination and clear thinking. In fact, you might as well consider prototyping and testing the same thing. As soon as I was satisfied that I had a design that met the goals of the project, tested well, and was refined enough, I jumped into Xcode. As I was developing the code in Swift myself it allowed me to be very agile, and small tweeks could be made easily throughout the development phase. I had never used Swift or Xcode before, so I was a little bit limited in what I could achieve.

---

---

The key for me was knowing when to stop designing. Thats a hard one, but I set a deadline and kept it. The final product isn't perfect, but it works, and it meets the initial goals of the project.

View inside Xcode. So, what's exactly going here. First I am detecting your location and from that identifying the nearest terminal. I then set a probable destination and calculate all of the times for that route. I capture the current time, and from all of the departures, I find the next one. This is then displayed as the time to departure. This will be correct most of the time but what I want to do is learn from your use and 100% predict your journey. Hopefully V 2.0 will include this feature and further enhancements.