How We used Rapid Prototyping to Make Offshore Software Development Efficient & Easy!

This story is about how we switched from a traditional development approach to rapid UX-first prototyping. It’s about arguments, the threats and the successful impact this had for our customers, our own team and business.

It was 2003, and we had just won a project to build a software solution for a large physician network. It was a typical project for us, and we would have approached it in the typical traditional way.

Except that I wanted to try something different…

Let’s Make this Process Easier, Efficient and Fun

In traditional, specifications-based development, volumes of specifications are written, which no one reads carefully. These specifications are then handed to developers, and they get to work. We worked this way back in 2003, mostly because this was the industry standard, and because we did not know any better.

If the old way of doing things worked, why did I want to disrupt this approach, our team workflow, and our culture? Furthermore, we had been doing quite well working this way. We were developing complex web solutions for Fortune 500 companies and our clients loved us.

I wanted to disrupt the traditional approach because it was hard and it wasn’t transparent.

For example, from start to something a customer could demo always took several months at a minimum.

• We were relying on large spec documents which nobody wanted to read nor understood.
• Customers would get nervous when their spending huge money and they can’t see demonstrable results for so long. (This was before agile of course)
• We would get nervous going so long and deep without any feedback
• When we would finally deliver the first demo customers would love most of it but be confused by parts of it.

Such confusion occurred because the customer would not see most parts of the UI until the Big Reveal. Customers loved 70 percent of the user interface but were not sure about the remaining parts!

When they did see it, the first thing they said was, “We love it but why did you make this part like this?”

What mainly caused this disconnect between customer expectations and delivered features was the over-reliance on written requirements vs user interface design. Just reading requirements made it very difficult to understand ‘how’ something would be implemented.

Considering most systems we worked on had over a hundred screens, you can see how this was a problem! To me, this wasn’t acceptable, so I went looking for a better way to deliver results our customers would love.

Rapid prototyping using Axure.com was the answer.

Some of the questions I needed to address with Axure prototyping included:

• Can we eliminate customer user interface confusion?
• Can we reduce our over-dependence on burdensome requirements documentation?
• Can we provide customers, through wireframing, multiple UI versions they could give feedback on?
• Can we start with Axure rapid prototyping to meet customer expectations and then follow up with specifications to match the approved wireframes?
• Would ux rapid prototyping level out expectations so everyone visually knew what they were working on and how it would work before graphic design and development started?
• While these questions seem clear and straightforward now, back in 2003, they set the stage for a bruising cultural tug-of-war.

It’s a No Brainer, Our Team’s Going to Love this, Right? Nope!

You have probably heard this phrase before, “We’ve always done things this way.” When I shared my vision of using rapid prototyping with the team, there was an instant push back. No one on the team had ever worked with rapid prototyping or Axure, the tool I wanted to use.

Everyone was upset with me for wanting to make this change!

Our senior project managers at the time were adamant that this new method would not work.

They said it would introduce bottlenecks, increase costs, present challenges with offshore development, and result in less than satisfying results.

I stood my ground.

However, I understood where he and the other project managers were coming from. You see, when a culture becomes deeply entrenched in a company, it’s only natural that anything new and foreign is met with resistance.

After several impassioned discussions on the matter, and with none of us relenting. I told them that they had to use rapid prototyping on the current project or they were fired. If they didn’t like it after this project they wouldn’t ever have to use it again.

The ultimatum solved the impasse and we got to work.

The project manager who was most against this approach ended up being the person who would build the first prototype in Axure. Amazing how things work out.

He told me it would take about 4 weeks and then he went away into a cave and didn’t show us anything for about 3 weeks. Not exactly transparency but at the end of the 3 weeks, we have a very functional prototype of the entire solution.

We met with the customer to review the prototype. They clicked through it, ask questions, and made some suggestions but ultimately they LOVED it! After a few days of back and forth with some minor updates to their feedback and we signed off for development.

Less than 4 weeks from start to finish with our first interactive prototype. The customer was excited and very confident in what we were building. They had NO doubts.

Our developers were super confident in what was being built. No confusion at all. And that project manager that was at first so against this approach? He was completely sold. He experienced the interaction with the customer and quickly felt like a hero and he really was.

The Results of Rapid Prototyping Were Shocking

Before I jump into how rapid prototyping impacted the project, our agency and ultimately our future, I need to point out that our primary goal for doing this was to improve the product end result for customers. To make it so they always knew what to expect and always got what they expected. This part was a slam dunk. We couldn’t have asked for better results.

As far as other metrics we were expecting marginally-better results than our old way of doing things. We expected maybe 5% savings on the budget, perhaps an improvement of 10% in lead time.

Instead, we got the surprise of our lives!

Overall, rapid prototyping saved the customer 40% of the original estimated total project cost.

While we were ecstatic about this, what we found after digging into the project delivery details totally blew us away!

How Rapid Prototyping Benefited Our Customer

Speed

We originally estimated that it would take about 6 months to deliver the final product. By using rapid prototyping we were able to deliver it in 4.5 months.

Customer Involvement

Using rapid prototyping led to faster acceptance and higher user engagement. Because rapid prototyping involves the customer at the UX/UI design stage, once development starts, it is clear that the features delivered will enjoy higher user-acceptance rates.

No More Unwanted Surprises

Usability and user experience were fully vetted right in the beginning during the prototype review. The results were exactly what the customer expected.

Expectations

The prototype made aligning customer needs and expectations a LOT easier. Developers were able to do things as expected faster and without any rework.

Scope Changes

Scope changes were handled during the prototyping process when it was cheap. Almost no scope changes came during development. This saved a lot of money in the development process.

How Rapid Prototyping Changed BIT Studios

Project Managers

• Our project managers found the process and communication with the customer much easier and more rewarding.
• This resulted in clients being a lot more engaged from the beginning
• Clients were not worried since expectations were strongly aligned in a visual prototype
• Easier to explain/show developers’ requirements & needs

Developers

• Developers also don’t read or many times fully understand requirements. Especially from a holistic perspective. The prototype made understanding the project very easy.
• Frustrating rework was eliminated
• Developers were much happier and felt rewarded by how happy the customer was with the first iterations.

How this experiment with Rapid Prototyping changed Our Company

• The rest of the company heard how positive rapid prototyping was they were eager to try this approach.
• The overall mood of the company improved. With offshore, customer engagement can be limited or almost non-existent. This process changed that.
• We started selling process first & winning 80% of real projects. Customers would immediately see the benefit after a quick demo of how the process works.

With the Experiment Over, What Was Next?

After reviewing the process, we realized rapid prototyping is not only a development method but a way of thinking. As a typical custom software development company, we always did things the same way, which severely limited us.

Using rapid prototyping led to an internal renaissance where we were now each asking, “How can we continue to improve?”

We also committed to the following:

• Implementing this new way of thinking and rapid prototyping as a workflow method in all departments.
• Getting customer feedback right away with updated reviews of prototype progress every few days so the customer is really part of driving results.
• Using rapid prototyping with all our future customers.
• Focusing on selling the process and not a product.

Why this Story Matters

Although today we use rapid prototyping and other modern software development methodologies to great effect, the effects of that experiment are evident today. Right across the entire company, the lesson echoes as we continue to ask, “How can we do things better?”

Software development is not easy regardless if you’re working with onshore or offshore software teams.

Rapid Prototyping can help your organization’s development efforts.

If you’d like to talk about how we can help or how to implement this within your company please get in touch. We’d be happy to help.