Posts Tagged ‘prototype’

From Idea To Business In Three Days Using Minimum Viable Product

Wednesday, May 19th, 2010

I have been reading a lot of Steve Blank articles at the moment and I was really looking for an opportunity to experiment with his idea of Minimum Viable Product, so we invented an internal project to work on over a long weekend. What could we achieve in just three days and how would the process work? It was a pretty crazy experience and this is a quick overview of what we did and how we did it.

You can see the final product here: http://hosting.djangofoo.com/ not bad for three days work!

The idea

We are a Django shop and find it hard to get simple hosting for clients. What we needed was a simple point and click solution for people with no technical knowledge at all, so that is what we built.

Planning

The first step was the planning phase which took an hour and we did this one week before we started the project. Each person in the team was assigned an area of responsibility and the planning was around the high level design, features, investigating the technology and the existing competition. Then for the next few days we all did some thinking about our areas and let the ideas distil in our sub conscious.

Day 1: High level structure

Day 1 Design. The first iteration of the design has all the elements and a global design but the messaging hierarchy does not flow, it appears too jumbled.

The first day started at a crazy pace as the enthusiasm was at its highest. We had a quick briefing session in the morning and then we all set off to our assigned tasks. We had documented the high level features in advance so we all knew which tasks were our responsibility.

We were a three person team, spilt into three areas:

  • Liza (an incredible designer) worked on the brand and the global styles of the interface
  • Davo (super coder) worked on solving the huge technical problems of how to set up the server, permissions, limited file space, writing bash scripts to create accounts
  • Me, I designed the data model, bootstrapped the project, wrote the models and set about coding the application

We communicated mostly by IM even though we were all in the same office, this helped us keep focused and keep our concentration.

Defining the features, proposition, wireframe and setting up the server, bootstrapping the code base, code snippets

By the end of day one we had completed:

  • A rough interface and brand
  • Wireframed all the pages
  • A feature list assigned with priorities
  • High level marketing messages
  • The skeleton code structure
  • The data model
  • Server set up and configuration
  • The ability for users to change Django version
  • A basic auth systems for users to sign up and login

Day 2: The detail

Day 2: A more polished design with better message hierarchy. There is a real visual style that can be carried across the rest of the site.

The day started with the same amount of energy and we spent the first part of the day validating the logic we had come up with on day one.

We also made some changes to the data model based on the design decisions we have made whilst coding. It felt like more of a details day, there were lots of questions that came up and lots of small issues needed to be addressed.

A large part of the day was spent working on the visual style and making sure that the right messages and visual cues were delivered to the user.

By the end of the day we had completed:

  • A more polished design, visual identity and brand
  • All the text pages content
  • All the user login pages, recover passwords etc
  • The content and elements for the logged in user pages
  • The ability for users to sign up and create their hosting environment, logins, FTP passwords etc
  • Bash scripts to create new users and folders
  • The base HTML and CSS styles
  • Mod WSGI reload when changes are made to the source code

Day 3: The launch

Caption here

In true MVP style we have not yet implemented the payment system, we merely get an email if someone attempts to pay.

Throughout the project we decided that we wanted to be the “easiest Django hosting in the world” so this totally guided our decision making. For every feature we asked ourselves if that will help to make the app the easiest Django hosting in the world. I think the project was defined by what we did not include rather than what we included.

By the end of the day we had completed:

  • All the HTML and CSS for all the pages
  • Integration into PayPal
  • Admin functions
  • Manage.py tool
  • View live logs
  • Security patches

Lessons learned

I think the main lessons learned were actually nothing new but they re-affirmed a few things:

  • Be ruthless with your features if it is not essential then move it to the wishlist
  • If a feature is taking more than about 2 hours then find another way or abandon that feature
  • A framework is a must, you do not have time to reinvent the wheel
  • Small team (ideally two developers and one designer)
  • It is very important for someone to co-ordinate the project
  • Don’t worry about not meeting all your users needs you can always add things later
  • Think of clever ways to get feedback and save time. When we looked at our tasks and times we thought payment integration would take quite a while so we skipped it and simply have an email alert if someone tries to upgrade

One of the biggest lessons I learned was to build your decision making around your core proposition, for us it was “The easiest Django hosting in the world’s”, anything that did not fit into this philosophy was removed, even at the cost of alienating more advanced users. Be bold and focus on your core customers don’t worry about being the solution for everyone. We knew from early on that people who wanted a high level of customisation and were advanced users would not want to use our service, that is ok we are not building a service for them.

How We Developed A Protoype All The Way Through To IP Spin Out

Tuesday, January 12th, 2010

Over the couple of years I have been working on a very interesting collaborative project for Nesta and Oracle. The project started off as a small prototype based on an idea that was designed to encourage innovation at large corporate companies, and over several stages turned into an IP spin out of Oracle that is now being used as a business development tool.

The initial idea

NESTA and Oracle wanted to design an online collaborative tool to make it easy for participating companies to brainstorm ideas and invite suggestions from their colleagues.

The project started with a group of large companies to pilot the scheme. Arup, BBC, BP, BT, Cancer Research UK, the Department for Transport, Interbrand, Lloyds TSB, NHS, Pfizer, Rolls Royce, Unilever, Virgin Atlantic and Vocalink.

Senior executives from each of these companies met at a kick off dinner to decide on the main themes for the project. They decided to focus on brand, digital identity, networks, and personalised information provision. This formed the structure for the programme. For the next eight weeks the companies used the Open Alchemy platform (which we designed and developed) to innovate and share ideas. They would then between them pick the best ideas which would warrant further development.

How do you get corporations to innovate more?

This is the big question. We spent a lot of time working with stakeholders and innovation experts, Innovaro, to come up with the best workflow and incentives for employees. Getting employees to take time out of their day to post ideas and innovations is not an easy task.

Along with Nesta and Innovaro we decided that the application needed to be:

  • Really easy to use (almost no learning curve)
  • Different, a funky design that is fun and engaging
  • Multiple methods to pull people back to the site; email alerts, daily digests, RSS feeds etc

The prototype

We had multiple iterations for the prototype, each time the workflow was tested with users to gauge their response. Quick iterations, fast feedback and short sprints were the key to meeting the tight deadline.

This project was more than just technology so we spent a lot of time on the design. In fact overall we probably had an even split in terms of design and programming resources. Innovation is about people; the prototype should support people and their ideas giving them the freedom to innovate.

We developed the first beta version of the prototype in less than six weeks.

Software evolution

At the end of the Open Alchemy project, which spawned some very interesting spin-offs (including WellBe, a points-based wellness programme designed to incentivise the public to adopt healthier behaviour which I am also a part of), what would become of the software now?

It was decided that as the software had proved so useful within Oracle that it should be deployed internally within Oracle and developed further. Over the course of the next year the software was improved, stress-tested and enhanced to meet the needs of a corporate giant. It gained a lot of traction and as such justified extra development.

IP spin out

Since deploying within Oracle the application has trialled internally within: Nesta, BT, NHS and other large corporates. Oracle made the decision to spin the IP of the software out into its own vehicle, which was a bold move. There was a lot of legal work in order to do this, but late last year it became a reality. The Open Alchemy platform will continue to grow and evolve, whilst providing strategic opportunities to the original creators Nesta and Oracle.

This project shows an interesting approach to technology business development. The Open Alchemy platform is not an expensive product but one of the software requirements is that it runs on the Oracle database and middleware stack. This embedded software approach means that every software licence means opportunity for Oracle.

You can read the full article and press release on the Nesta site (click here)

How To Wireframe

Monday, April 6th, 2009

Wireframes can be a great way to visualise your concept and get the client engaged with something other than a written spec, but what are the best practices? Wireframes are supposed to show where items will be placed, and the general layouts of the page. Doing this will save you a lot of time before you start the time intensive design phase. Using wireframes is a great way to begin a project, as it allows you and your client to focus on layout without the distraction of color, type and other design elements. Concentrate on what goes where on your web pages and the percentage of space that each element takes up, which can be determined by your client’s needs. Design is not important. Think about layout, functions and navigation. Think about who the wireframe is for:

  • Developers?
  • Client?
  • Designers?
  • Management?

We tend to build wireframes in HTML, but doing them on paper or in Photoshop is fine, the process is the same, to work out the layout and general structure of the site.

Wireframe Example

Wireframe Figure 1: Wireframe example (click to enlarge)