At Waverley we believe that magic happens when buyers and sellers of a software development project integrate their knowledge to create combined know-how greater than the sum. Assuming the buyers, or clients, know their business well and that the sellers, or providers, know how to design, write and deliver great software, the magic happens when two parties figure out how to bring their experience and knowledge together to get the job done. They need to listen to one another and brainstorm to find the best possible approaches for solving problems, which technology to choose and what processes to employ in design and implementation. When a vendor has specific domain experience it can be reassuring for the client – but is domain experience really such a critical component of a successful project?

We feel there are several considerations that trump domain experience. Care, attention, intelligence and trust for starters. Granted, trust is something that results from successful outcomes so trust takes time. But the others are there from the very first phone call. Care and attention mean prompt and thoughtful responses: “digging down” to get to a deeper level of understanding. Intelligence means bringing smart thinking to a problem, sometimes by those who are looking at the problem in a new way, and are in a position to question assumptions, challenge supposed limitations and take a fresh look at how the problem is framed and then solved.

Naturally the process used to build the solution is important. Agile is great, we use it on every project, but Agile is only a process; it’s the people who implement the process that make it work. Creating an environment where the team works together and solves problems well is also crucial. Environment is perhaps an over-used term. At Waverley we believe it covers everything from the physical work environment to the tools used to communicate over distance and the quality and bandwidth of that communication, down to the accessibility and readability of documents used to share ideas.

So when shopping for a software developer, we suggest looking beyond domain experience. Otherwise you might miss the magic: a chance to build a great working relationship and the clean design, solid engineering and top results that come with it.

The leaders among business services organizations are embracing a new global delivery concept, which KPMG calls “Extended Global Enterprise” or “EGE”. EGE includes end-to-end processes, with internal resources and outsourced service providers working together towards the goal of delivering high-value services.

As a result of this paradigm shift, client expectations are changing. Service providers need to adjust or become irrelevant. Forget about transactional long-term mega-deals with the emphasis on back office and TCO metrics. Labor arbitrage is more and more out of the equation. Some argue that even location matters less. All of which begs the question of whether outsourcing is dead or is instead evolving into something broader and wider than the traditional ìmodel? I think that the latter is true.

According to the survey the support for Agile with outsourced projects has fallen significantly from last year. Only 49% of respondents said they use, or plan to use, Agile methods – down from 77%!  Given our success with Agile methods this trend surprises me. Unfortunately the results report doesn’t go into any detail about why people are struggling in this area, I would have loved to get into the details of this one.

We have found that Agile actually aids us in our success and could not imagine a better way to coordinate with our clients and make sure we are addressing their highest priority features and issues during development. Agile promotes close communication which is so vital in outsourced projects.  I can confirm that we are not part of that drop in outsourced Agile support!

Erik’s point is that many entrepreneurs, clients, product managers, etc don’t often stop to consider all that needs to happen for good UI design to happen, and that good UI design is not the goal but a kind of natural follow-on to effective thinking about a problem: thinking that is informed by considering how work actually gets done, thinking that considers the views of multiple stakeholders, most of whom are not concerned with design at all, thinking that leads to solutions that are relevant, parsimonious, elegant, adaptable, and robust.

In Erik’s words, “UX is the intangible design of a strategy that brings us to a solution.” Put another way, UX is all about how to approach a problem, whereas UI expresses, in limited terms, a part of the solution that good multi-stakeholder problem-solving generates. UI is about layout and flow and widgets and content and transitions and giving the user the tools he needs as the need arises. UX is about how to get there, how to know what parts of the original problem can’t be addressed by the UI alone, and how to keep asking the right questions so the UI evolves with the way real people actually end up using the product.

Symbian, Android and iOS, Europe

ComScore also analyzed the European market for smartphones over the last couple of years (data reported below through July 2011). Between 2010 and 2011 Google Android gained 16.2 percentage points, almost exactly matching the market share lost by Nokia’s Symbian. Apple iOS and RIM both grew by about 1.3%. Current trends indicate that Symbian will continue to lose market share and disappear entirely by 2015. Also worth noting is the far greater growth of Android’s market share compared with Apple’s iOS.

Android and iOS, USA

ComScore’s analysis of the US market runs through February 2012. As of that date, Google’s Android has just passed the 50% market share mark (50.1%), a 3.2% gain relative to November 2011. Apple’s iOS market share grew only 1,5% in the same quarter, and now stands at 30,2% overall. iOS and Android together occupy an 80.3% share of the US smartphone market. Of the competition only RIM is managing to hang on with 13.4% of the market, down 3.2% from November 2011 to February 2012. Windows Phone market share stands at 3.9% and Nokia’s Symbian at 1.5%.

Things begin to get interesting in what Tuckman called the Storming stage, when team members open up and start confronting each other’s ideas, discuss the degree of autonomy each will have, and settle on what leadership model will operate. In contrast to Forming, the Storming stage is almost always uncomfortable, but it’s just as necessary to the growth and eventual productivity of the team. One might say it’s the process by which a collection of individuals becomes a team, so it’s important to go through it and not get stuck there. In the next two stages, Norming and Performing, some ideas and personal agendas within the group are given up, a mutually agreed-upon plan and shared set of priorities emerge, and things start to hum along.

At Waverley we’re familiar with this cycle. We’ve seen it within our own organization (changing circumstances and new hires can partially reset the cycle) and in most new client relationships. A a new project kicks off and bright, talented people who have never worked together form a new far-located team. When the stakes are high (and in software design and engineering they almost always are), there’s always a moment when the new team is finding its legs, the clock is ticking, and the temperature rises. We’ve learned to harness this heat to improve outcomes, to cook tastier applications. While the team Storms and Norms synergies are created, and these synergies are a big part of what brings us to work in the morning.

On a recent project, the first in which Waverley’s new in-house UX/UI team was asked to produce a complete cross-platform mobile app design for a visionary entrepreneur, Tuckman’s phases were right there, textbook-style. The concept was so exciting that our lead designer started envisioning features and opportunities well beyond what was initially presented. And although the enthusiasm was welcome, it wasn’t long before we were busier sketching version 3 than writing a spec for version 1. The client, who was on a very tight budget for the UX design phase of the project, started to push back while our designer maintained that the only way to stress-test the flow and interrelation of certain features was to project them out into future versions. All good, but the clock was ticking and before too long the design of actual screens had to take priority.

This was classic Storming. In those early conversations, framing and reframing functionality, we weren’t just debating abstractions, we were getting to know the app, and each other: observing how we each responded to challenges while stress-testing assumptions about everything from on-screen help to the potential for social networking. Our designer was getting his head around the app’s proposed features, something the client had long-since done, but fundamental to what happened next: an elegant set of screens started to emerge, informed by the concerns of all stakeholders: market knowledge, cost constraints, user needs, and aesthetics, in an atmosphere of mutual respect. Respect doesn’t come easy, and politely pretending to agree doesn’t cut it when people are demanding the best of themselves and each other. Storms have a way of focusing our minds and sharpening our senses. Faced together, they bring out the best in a group.

But it’s not that simple. As Erik Slivka points out in his June 7th piece in MacRumors, developers are overwhelmingly opting to develop for iOS, despite Apple’s lower market share. Slivka quotes Flurry Analytics, which issued a report cited in his article, stating “Android delivers less gain and more pain than iOS … the key reason seven out of every 10 apps built in the new economy are for iOS instead of Android.” Apparently, of 18,000 SDK downloads by smartphone developers in Q1 2012, 69% were for iOS. The key reason appears to be the extremely fragmented state of the Android device space. With multiple handset manufacturers, an endless proliferation of models (and screen sizes), and with operating system updates having to go from Google to the handset manufacturers to the providers before they get to the devices, most Android handsets are two or three major revisions behind the latest Android 4.0 Ice Cream Sandwich update. Scroll down to the end of Slivka’s piece to see that as of his writing, only 7.1% of Android phones were running the latest software. Contrast this to Apple’s installed base of iOS devices, 75%-80% of which were running that platform’s latest update: iOS 5.

The fragmentation problem is not merely statistical or academic. In Michael DeGusta’s excellent analysis from October of last year, he points to the constraints faced by developers writing software for Android phones, “most app developers will end up targeting an ancient version of the OS in order to maximize market reach.” Fewer apps and less investment towards Android on the part of developers translates to a more limited selection of worse-performing apps in the hands of consumers. DeGusta adds that those consumers are likely to be less satisfied with their phones to begin with, since most of them are running outdated versions of Android. This also impacts the expectations and “culture” of consumers on either side of the divide. iOS users expect more from their phones and their apps, but they’re also willing to pay more for that refinement.

At Waverley, we’re continuing to see interest in both Android and iOS on the part of our clients, and more cost-conscious clients are increasingly asking us to develop cross-platform apps using a single code base in HTML5. We might talk about the tradeoffs of such an approach in a future article. For now it’s clear that while Android pushes more handsets, most developers feel that iOS is where more money can be made.

Research and analysis

This phase lays the foundation of a successful product design and development effort. Some of our clients have portions of this in hand when they approach us, others will call us as they initiate this phase. It involves an overview of company and product goals, competitive offers, user needs, and, time permitting, formal field (ethnographic) research. This phase ends with a concise statement of project goals, a functional specification, a Statement of Work (SOW), timeline and budget.

Sprint 00: persona, scenario, and story development

These are elements that ground the design process. Personas are fictional but specific: distinct in their goals, technical expertise and areas of concern. They often end up working together through the finished product, usually asynchronously. Scenarios are situations populated by one or more personas; the finished design is all about positively impacting a scenario, and scenarios, more than any other element, drive content. Finally, Stories are the narrative texts that describe an interaction of personas (users) with the finished product, accomplishing goals and getting on with life. It’s useful to involve a technical lead in this sprint. Stories in particular are critical drivers of production sprints, helping to meaningfully divvy-up the development effort. This sprint ends with a list of personas, scenarios and stories.

Sprint 01: information architecture, task selection, wireframe design

The core of the design. What information is presented, how it’s “chunked” and laid out, and how the chunks link together so that the resulting content and flow meet the needs of the various personas. The key personas and top stories are the drivers here, yielding an “A-list” of tasks. Card sorting and “walkthroughs” of rough designs with flesh-and-blood representatives of personas can be used to support the evolving architecture. Again the presence of a technical lead is recommended, since he or she will serve as an advocate of design details during the production sprints. The rest of the technical team can use this time to research techniques required to implement the evolving wireframe. This sprint ends with a rudimentary functional specification including wireframe designs of major screens.

Sprint 02: visual design, asset creation, start production

Portions of the wireframe are “frozen” and their individual UI elements get fleshed out at a pixel level. Simultaneously, production starts on executable code. As before, priority is given to “top” stories, the ones that meet the greatest number of needs for the most important personas. The goal of this phase is to have a working, testable “stub” of the design. This can be used in formal usability testing, in presentations to external clients or management, and as a foundation for the rest of the application. The creation of visual and logical assets continues on an as-needed basis. This sprint ends with a full functional spec including detailed visual designs of major screens and a testable “stub” of the app.

Sprint 03 to sprint N: design revisions and production

Revisions are proposed based on testing (whether formal or ad-hoc) of the first working stub or stubs. These are passed to the visual designers and engineers along with further stories, duly sorted in order of priority, that are in need of implementation. Production at both the pixel level and the subroutine level continues in alternation with testing, proposed revisions, and delivery. Step by step, the app gets built, used, tweaked, and built some more. These sprints end with an updated functional spec and a progressively more fleshed-out app that approaches full functionality.

Sprint N + 1: publication

Release of the 1.0 version and careful monitoring of client and customer feedback. No matter how attentive the design process there are often surprises once an app is in the hands of real users. Some will end up using the app in unexpected ways. Others, through their feedback, will suggest enhancements and extensions we hadn’t thought of. It’s also very likely that the 1.0 release will be partial, with certain second and third-tier stories and wireframes still in the cooker. In this phase the prioritization of what gets finished or polished next can shift. This sprint ends with a finished “version 1.0” app available for download to users and a list of user feedback, often leading to the generation of additional user stories.

Concluding remarks

At Waverley we feel it’s appropriate to apply the Agile methodology to the UX design of an app, for the same reasons we tout its advantages in the engineering and production of the design. Given the interweaving of design and engineering inherent in the production of a successful product, the above approach seems to us a matter of necessity.

As in any Agile process, a firm adherence to timeframes and tasks is essential.