Apr 12, 2018

Get a app out in 6 weeks

So this is not the sort article that has a cheat code to be able to deliver an app in 6 weeks, but we did conceptualize, build and deploy an app in 6 weeks, and this article will be about the process I went through, and how we tackled it, and eventual issues during the project, and hopefully, there are some gold nuggets that can help you in your own process.

The team set up

A product owner
A project manager
2 developers
1 designer

Project case

The client wanted to create an insurance product made exclusively for students, which should be able to activate on-demand and instead of getting a whole package, they could choose in ensuring a single product, at the same time, rewarding the users with promotions relative to the students.

The app is only available in Norwegian.

Restrictions

  1. We needed to build something that would fit within all the necessary and current integrations, as we had to minimize dependencies on system changes for external parties, so it was “what you have is what you get”.
  2. The internal system was not mature enough to process user changes, and changing insurances, getting new or deleting old, this was in our opinion a deal breaker, so needed to work hard around this one.
  3. We had 4 weeks for everything.

Conceptualization during development

The first thing you need, is to trust and I can never underline this enough, know your team and allow them to know you, we were blessed enough with being the right team in order to hit the deadline.

We needed also to completely remove any external influence that would change the scope of the project so the whole weight and responsibility of the product fell on the team, departments normally have ideas that they believe would suit their interests best and therefore want to add their “touch” to projects, normally creating scope creeps which delays the project indefinitely.

At the same time, as I spend my time on trying to visualize how the interaction was going to be, development started immediately building certain interactions for trial and setting up certain dependencies as secure logins and so on… this accelerated a lot as I could also base my design around what they were able to build.

What wireframe? We went straight to design…

So being a time a major constraint we needed to remove a lot of what normally is part of the research, creating a thesis and validating them, we had no time for that, we needed to create something and it needed to be right on the first try (or as right as possible).

…no bots here, only humans.

Since the system was not mature enough we needed to work around the chat support, they would be the direct contact between the user and the system, as a lot of people are jumping on the chatbot trend, we decided we were not going to be a chatbot, but we would have direct contact with support, no bots here, only humans.

The main cause being that chatbots are getting good, but they are not quite there, they require a lot of training, which required time, time that we did not have.

Designing chat?

Who has done it? and who has done it right?

So I took Facebook’s Messenger and Slack’s design as a starting point.

So what are the main notes here?

  1. It’s completely fine to have a set of tools around the messaging, uploading content or creating triggers.
  2. Facebook alongside uploading content has these “plugins” that allows for augmenting the experience.
  3. Slack has these tabs to add dynamic content to the conversation.
  4. But when you message, that is the focus, the input area becomes maximized and everything else is superfluous.

What “tools” do we need to create with messaging?

  1. Access to insurances
  2. Access to student deals
  3. And to settings, that controls login and other personal settings.

Therefore we build something like this

Upon pressing on each tool we would activate that specific section

 

So now we have the main interaction defined, what now?

I have to say a lot of this was defined with the development team, we needed to make sure that we could have a logic that could support this, and that it could be set up in a quick manner, so nothing too crazy.

So now was time to connect the dots in regards to integrations, and everyone really pulled through to see how we could set up a working product, from third parties for providing deals, from the system managers making sure that products would be set up correctly and available for testing with the app, to the development team that quickly adapted and changed logic to match both requirements and technical difficulties.

How can we make this more interesting?

So we have the core functions set-up and available, the app would work perfectly with this alone, but from the client, we have a machine learning project with image recognition for creating estimates for damages. And we wanted to help it learn about the products that students use so that we can help them create an estimate of costs in the case of damage.

So we created a tool for recognizing these products and mark them as a selection for getting an insurance proposal, so instead of selecting your products from a list, you could scan them with augmented reality.

So what is the actual learning from this?

Personally I got a lot out of this project, it had a “let’s build something and see if it works” approach which I liked, and now that is has been out for a while, we now have the possibility of changing what does not work, and improve in where we can, such as more relevant deals for example.

  • It’s possible to build a product in a very short time, but not recommended, we did guess a lot which we hoped to validate with real data from real usage instead of being able to user test it in advance.
  • There were a high pressure and stress factor in order to make it work, bear in mind that Apple has a service level agreement of approving or denying an app within 2 weeks even though it could take less time.
  • It can be fun depending on how you approach the project.
  • You have to be comfortable in failing in order to succeed
  • You have to be comfortable in delivering a product that could feel unfinished
  • Important to keep a close eye on how the app responds on the market and be able to apply quick fixes.
  • This is a more generic note but, remember, your product is not done because you have published it, a good product evolves with time.

The app is only available in Norwegian.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Back To Top