Prototyping With a Framework

framework
author avatar

Paul Lopes

In a traditional systems development life cycle (SDLC) project, sometimes the end result does not successfully meet the needs of the user, even though it does meet the requirements set out by the business requirements document. The reason why is simple: no one tests the requirements with real users. Instead the product is released and users experience a sub-par product. The feedback at this stage is deflating to the team and the outcome can be costly, often in the form of lost customers and angered clients. Fortunately, this outcome is easy to avoid. There is a solution that is quick and painless to implement. What is this miracle? Prototyping!

We use extreme prototyping (yup it's a real thing dude), but any type or any level of prototyping works. Prototyping gives a realistic representation of how the end product will look, feel and function. More importantly it is developed quickly and then tested with real users, which is the ultimate goal. Requirements documents imagine a future. Prototypes make the future real.

 

The car industry has realized and enjoyed the benefits of prototyping for years

 

So why doesn't everyone prototype? In our own experience and observations, it's because people don't understand it. It's perceived as something extra on top of a huge pile of work already needed to be completed. Isn't an expert required to create prototypes? It's only an expensive luxury which most teams don't have time or money to invest in. Plus it introduces feature and scope creep. Right? Wrong.

In our experience:

  1. It can be done by almost anyone on the team, even the humble visual designer, well in advance of the actual development phase
  2. You don't need to install databases or development environments or compile code. It can be straight HTML with CSS.
  3. Changes can be made quickly and re-tested with real users almost immediately
  4. Good ideas are quickly confirmed and bad ones quickly and easily discarded
  5. Hidden issues not identified in your requirements documentation come to light
  6. The code produced by the prototype can be re-used or built upon by the developers

On your mark, get set, choose a framework!

So you're starting to see the light when it comes to prototyping, but which framework should you choose? We like Bootstrap, in fact this entire site was prototyped using it. Bootstrap is an HTML/CSS framework originally created by a designer and a developer at Twitter. It's become one of the most popular front-end frameworks and open source projects in the world.

With clients from the federal government however, we use the WET4 framework, a collaborative open source project led by the Government of Canada. It's built on top of Bootstrap but includes an arsenal of useful jQuery plugins and conforms to WCAG 2.0 level AA accessibility standards. There are other frameworks of course, like Zurb Foundation, Skeleton, CardinalCSS and many more, so the key is to find one that works best with your project needs.

Build it and they will come

Next take your requirements documentation and build. For example, for one project we converted a standard pdf form into an HTML guided wizard. The WET4 framework provided all the UI and we were quickly up and running with a better than high-fidelity prototype.

The level of functionality you want to implement will depend on your time, budget and available skill level. But we're a proponent of the fake it until you make it methodology when it comes to prototyping. Again the true benefits of a prototype are only seen when you get it in front of real users. It does not need to be perfect.

Release the hounds!

Next start scheduling users to run through the prototype. In our experience, we give them a scenario (you're a stay at home mom looking for information on tax returns) and a then give them concrete tasks (where would you find line 101 on your 2015 tax return). Then we sit back and watch them validate your design decisions, or completely trash them because your product does not meet their needs.

 

Using tools like WebEx helps share the test results with your team.

 

We record this entire process with WebEx (after getting written permission from the users of course) then share that information with the project team. Based on where the users had issues, we tweak the prototype and then test again. We continue this process until we are satisfied with the results. If we've run out of time then we make a record of the issues and try to revisit them in the next development cycle.

Finally, we take the prototype code and literally hand it over to an engineer to be integrated into the working files in version manager.

It's too good to be true

We know, it certainly feels that way, but the pros greatly outweigh the cons when you start receiving real user feedback that praises how easy your product is to use. Why would you want to inflict real users with an initial product that is overwhelmingly frustrating to use? That's the true cost of NOT prototyping. It makes much more financial sense for any organization or business to present their clients with a product that is human tested and human approved!

Thanks for reading! If you would like to know more about how prototyping can help your business or organization, email us hello@thinkingbig.net or tweet at @thinkingbiginc.


More articles

Communicate Early and Often

Jennifer MacIsaac

People hear and interpret things differently. You need to adjust to your audience, share the message through different avenues and repeat your message until it has been understood.

Continue ...

Please Don't Forget the User

Brian Ansems

Plain and simple, software and services are used by people. And the user’s experience with those services will decide the success or failure of the enterprise that creates and owns them.

Continue ...

Business Process Re-engineering for Digital Enablement

Kent Harrison

Customers become frustrated with an online service that goes as far as filling out a form, then they click on submit and end up waiting for days, weeks or longer for their transaction to complete.

Continue ...

Clear, Concise, Common Language

Jessica Bruce

Over the last few months working at Thinking Big, I have encountered small, yet important issues which have taught me lessons on the value of challenging familiarity and thinking, well, BIGGER.

Continue ...