Sprinthacks@BASH

Recently, I participated in Sprint Hacks, a 5 day designathon held by DBS Bank and Infocomm Investments at BASH, One North. (BASH = Build A Startup Here) It was a design thinking workshop cum hackathon (in 5 days) where we were tasked to solve real life issues faced by some SMEs, in teams using Google’s Design Sprint Methodology. With that, lets begin with what design sprint is about.

sprinthacks_main

What is Design Sprint?

The Design Sprint is a structured methodology created by Google Ventures, defined as

A five-day process for answering critical business questions through design, prototyping, and testing ideas with customers.

So basically in a sprint, a few months of brainstorming and solving critical business issues is compressed into one week. This is rather useful as you’ll be able to test out your idea to see whether it is effective in answering the relevant issues. If it is, one can transform that idea into a full fledged product. If not, you can spend the remaining time re-evaluating your idea. (This will save one’s time as a week’s worth of a failed idea is better compared to a month’s worth of failed idea.)

sprinthacks_flow

So for this Sprint Hack Designathon, each day of the workshop is allocated to a part of the methodology:

  1. Mapping: Understand the issue & choose a target (define a specific problem to solve)
  2. Sketch: Ideation and sketch of ideas
  3. Decide: Choose the best Idea
  4. Prototyping: A realistic one
  5. Testing: Test with targeted customer to validate idea

In summary,  we’ll be identifying a specific part of the challenge or issue, coming up with a solution to solve it, prototyping this solution, and finally validating the solution where the targeted customer will be testing our solution.

Before jumping in to what we did, let’s do a brief introduction on my group.

 

The Team

Viz X (Group 4)

sprinthack_teamlogo

The grouping were assigned by the organisers, according to our personality and skills (Before the event, we have to take an aptitude test), and there are 6 teams in total for this event. For this event, I was allocated to group 4, which consists of 7 other individuals (One left due to school commitment, so there left 6). They are Chloe, Kenneth, Li Hao, Rui Mei, Vanness & Wei An, and they are from various polytechnics and backgrounds (Business, Science, IT).

We allocated ourselves different roles in the group, and I’m the CTO (Chief technology officer) of the group, responsible for the technical aspect of the solution.

 

Facilitator(s) & relevant individual(s)

There are facilitators for each group, to guide us along the process. However, the facilitator changes throughout the designathon.

Nevertheless, I would still like to thank these few facilitators & individuals for guiding us along (though some pop by occasionally):

  • Shi Jun
  • Kellie
  • Hoong Chun
  • And a few others (Somewhere  in my subconscious…)

 

Problem

The problems available for selection are actual problems faced by some SMEs. There are a few problems, some related to logistics, stock check, but we chose this particular problem, where the company is involved in the luxury goods bathroom industry:

  • Sales depends on sales assistant, but they are not always in optimum state
  • Customer have a Visualisation problem

 

Mapping

Before working on a solution, we have to first understand the problem completely. To do so, we started by mapping the customer journey map, then we came up with questions at each part of the process flow. After that, we interviewed the SMEs to better understand their problem and needs.

After much discussion & evaluation, we decided to focus on the visualisation aspect of the problem.

 

Solution

Sketch

crazy-8s

After gathering key information the previous day, we went on to sketch possible solutions that can be implemented to address the issue. What we did is similar to the procedure as shown above. One of the most interesting part of this process is the Crazy 8s part. For this, we are supposed to come up with 8 rapid variations (of the rough solution) every 3 minutes. (But the actual timing for the Crazy 8s is supposed to be 1 min per variation, which is as the name suggest, crazy.)

 

My solution – ARLS

img_20160906_170613

The final sketch of my solution is this: ARLS. (which is an acronym of Augmented Reality Layout Simulator) My idea uses Augmented Reality (probably the Hololens?) to visualise and simulate the products the customers wants to buy. The visualiser will allow users to “place” items in a physical environment overlayed by the augmented environment. The application would be navigated around using hand gestures, and the physical environment would be augmented with relevant windows for the catalogue, products customisation, and estimated quotation.

This would allow users to visualise their bathroom environment in the showroom of the company, which would solve the customers’ visualisation problem.

Side notes: After a while, I realised that we can use the mobile devices to implement this AR feature (like Pokemon Go style of AR) instead of solely depending on Hololens, which is currently under development as the time of this post.

 

Voting (Decision)

It is not possible to implement all the solutions we sketched, so here came the time where we selected the best solution to create the final prototype. Though my idea had an overwhelming number of votes, but due to technological and time constrains, we opted for another idea instead.

 

Final – Digiroom

Here is a summary of what the solution comprises of:

Ipad Application + Sims + Sketchup-like 3D Visualiser + Catalogue with Search +  Quotation system + Reference Order

It is basically a mashup of web like and game functions in an Ipad application.

 

Prototype

After selecting our final solution, we moved on to creating a prototype.

Platforms

invision_vs_proto

At the start, I wanted to code the prototype as a web-based application using bootstrap, but due to time constrains (~5 hours to prototype), a user interface prototyping software was used instead to create the prototype. Initially, I started out with InVision (a prototyping web app), but I switched to proto.io afterwards as it’s much easier and faster to use compared to InVision.

Why did i switch over?

  1. The internet connection was so bad at times (too many individuals were using the network, which is very common for this kind of event…) it was almost impossible to download the relevant UI toolkit or icon set that is needed. These UI toolkit & icon were meant to make the prototype look more realistic.
  2. I have to create every screen of the prototype, which includes the dialogbox, popup notifications, dialog boxes, etc. This is rather time consuming compared to a drag and drop type of prototyping web app. (Which is what proto.io offered.)
  3. There will be a problem uploading all the various screens due to the problem mentioned previously: Bad internet consistency. If I’m unable to upload the screens to InVision, whats the point of even using InVision to prototype our idea?
A screenshot of the proto.io web app interface

A screenshot of the proto.io web app interface

So with that reasons, I switched over to proto.io, which offers a predefined UI toolset, transitions, icons, drag and drop interface, if this, then function, and many more. It is also simpler to navigate around and faster to learn how to use.

 

VR View

To simulate the visualisation, we used Google VR View. Below shows the sample code that displayed the VR view as shown above.

More information on this can be found here:

 

Digiroom

The prototype, Digiroom, is an ipad application that includes the following features:

  • VR Viewer (To simulate Visualiser)
  • Product Catalogue
  • Estimated quotation.

For the prototype, it is not possible to come up with an actual 3D visualiser in the application, so a static image was used to replaced that.

You can try out the prototype at this website: [Coming soon]

Below are screenshots of the prototype:

The flow of the product is as follows, where:

  • Rectangular box -> App screens
  • Ellipse -> Prompt/Dialog
  • Curved rectangular box -> Action
  • Arrows -> Transitions between the different parts

digiroom_flow

 

Validation

The last part of the design sprint process, is where we let the customer test out the prototype. On this day, the targeted audience (in our case the sales assistant) were invited to test our product.

There were several flaws in our prototype, such as using very small icons to represent the toolbar, the tutorial is too short, etc. , but this normal as we may miss out certain parts they (targeted audience) notice that may be flawed.

 

Presentation

At the end of the event, each group has to present their solution for the selected problem. We decided to assign 2 person to present our solution, while I demonstrated using the prototype. Though the presentation was not up to my standard, it was still a good effort.

 

Conclusion

Here are a few takeaways that I gained from this workshop:

  • The Sprint Design Methodology on identifying a specific problem & working on a solution (Can try using it in future hackathons I attend.)
  • What the customers want may not be what they really want.
  • The way one presents their idea is more important than whether your prototype is working, or looks real to a certain extend.
Share this post:

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *