When launching a new software product, the tendency can be to go for a ‘quick and dirty’ approach. And often, too much attention is paid to development and product design, too little to marketing. You get products that work really well, but don’t address key needs and requirements among the target market. Or you get products, sometimes high-quality ones, that launch in perfect silence and disappear the same way.
When most people think of “computer software,” they think of applications that are used to interact with a PC, laptop, or mobile device. These programs display icons or information on a screen and take input from a keyboard, pointing device, touch screen, or game controller. But interactive software represents only a fraction of the software that’s out there.
“We need to build a mobile app!”
“Sure, boss. What exactly should this mobile app do?”
“Doesn’t matter! All our competitors have mobile apps, so we need one too!”
This is exactly the wrong way to launch a mobile app project.
Yes, you probably do need a mobile app because an increasing number of people do a majority of their computer activities on mobile devices. And yes, most or all your competitors have mobile apps available on app stores. These are necessary but not sufficient conditions for building a mobile app.
We’ve discussed extensively the concept, advantages, and tools of rapid prototyping. It’s central to our development process here at AndPlus.
Whenever any new product is designed, the designers should spend a good deal of time and effort on the product’s user interface. “Should” is the operative term here; sometimes it doesn’t happen adequately if at all.
Today we start a series of blog posts that dive into the design and development process we use here at AndPlus.
Our philosophy at AndPlus follows the Agile development methodology. By way of review, Agile breaks down a development project into short (one- or two-week) mini development cycles called sprints. A fundamental principle of Agile is that at the end of each development sprint, the team should have a working (albeit not necessarily complete) version of the software product.
