We recently came across an article by Erik Flowers which makes a useful distinction between two terms that are usually conflated and confused: user experience (UX) design and user interface (UI) design. Erik has even created a handy site offering print-ready PDFs of a two-column comparison which lists all the activities that are properly, in an ideal world, part of the former, meaning part of UX design. Twenty-three activities are listed, of which two: interface design and visual design are, according to Erik, what most people think of when talking about UX design. The rest, as he sees it, are mostly essential precursors to a good user interface design effort, but they often not given the attention they deserve. Amongst these are field research, creation of personas, creation of user tests, gathering and organizing statistics, feature writing, information architecture, taxonomy creation, working tightly with programmers, design culture evangelism, and so on.

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.

Agile development has its origins in the field of software engineering but has proven its efficacy in other creative fields. One such field is user experience (UX) design, and here Waverley’s newly minted in-house UX design group is proposing how the “sprint-based” approach of Agile development might be applied to the design of a software application. Waverley thanks User Test Lab’s Stefano Dominici whose piece “Sviluppo Agile e User-Centered Design” inspired this article.

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.

Although outsourced software engineering projects require the use of complex development technologies, these projects rarely stumble due to a failure of technology. At Waverley we’ve learned that problems with outsourced projects are almost always due to issues with management and communication. These problems can arise due to lack of commitment by either company, by lack of planning before the project, or by lack of attention to “people factors”. Companies that are successful with their outsourcing projects have learned to avoid the common mistakes and we at Waverley are passing their (and our) experience on to you as a list of ten simple maxims.

Don’t Throw Your Project “Over the Wall” and Expect Results

Working with a partner demands attention, organization, commitment and skill. It requires all the skills you use to be successful inside your own organization, with the additional complexity of working with another organization. It’s surprising how often we have seen organizations think they’ll be successful with outsourcing a software engineering project by handing the project to a new partner and then , closing their eyes and hoping for the best. Throwing a project “over the wall,” as we call it, is not likely to work. Without clear goals, well defined responsibilities, organized engineering process and time and commitment from both sides of the partnership, problems are guaranteed. But when done right, working with an outsourced partner brings a large number of benefits—these include:

1. Shortening the time to market
2. Reducing costs and improving productivity
3. The ability to kill off bad ideas and work with good ones
4. Learning from the partner’s domain experience and improving internal processes and quality as a result

Lack of Trust Will Kill the Relationship

Trust is a critical and overlooked component of any working relationship. In most relationships, trust is often politely “assumed” when two people begin working together. But, as we’ll explore in a later post, real trust is earned. Early on, it’s normal for staff from either organization to wonder, “are they capable of doing the job,” “how will this effect my career,” “why do they ask so many questions,” or “do I have time to help them.” At every turn, there is potential for trust to degrade or to build. Good partners are honest, open, will tell you the good news and the bad, will communicate as clearly as possible and will make a commitment to success with every engineering decision, conference call and line of code written. When in doubt, it’s sometimes helpful to assume that the other person is doing his or her best until proved otherwise.

Say Everything

An important component of trust is full disclosure. There’s no reason to try to hide bad news or not be clear and honest about all parts of a project from the schedule and priorities to the team, deliverables, software quality, and documentation. Most people can quickly tell if the full picture of a project isn’t being accurately presented. So there’s every reason to be completely honest about all aspects of an outsourced project. Saying how it really is will help correct small issues before they become large ones and contributes to building the trust which is the basis of success in any relationship.

Commitment is Required From Senior Management on Both Sides

People in organizations take their guidance, both direct and indirect, from their management. They’re unlikely to take major risks unless they’re sure they have clear support from above. Outsourcing a development project carries inherent risks so it’s vital that management from both companies demonstrate support for the outsourcing effort. This can begin by developing a shared vision of how the outsourcing initiative will meet the strategic objectives of the client’s organization. Part of this shared vision is to state clearly how the two companies will contribute to the success of the partnership. Management can then build on the foundation of a shared vision by developing realistic requirements for the project, metrics of success, and methods for clear communication throughout the project.

Knowledge Transfer is Critical

Knowledge transfer is a critical part of any new software development outsourcing partnership. The client and service provider work together to define the product and the technical requirements of a new project. Incomplete knowledge transfer constitutes one of the major risks of outsourcing. This is also the time when team members get to know each other and where the project infrastructure is established, when risk is analyzed (and mitigated to the extent possible), when business and technical requirements are collected and disseminated, etc. High-level estimates and project plans are prepared, milestones and contingencies are examined, a software development life cycle (SDLC) is chosen, management procedures are debated and eventually accepted by the team, domain experts from the client are available to help the outsource team learn the client’s or end-user’s business and goals, and the engineering team is assembled and begins to create a detailed project plan and technology stack for the service or product to be delivered. The knowledge transfer phase of a new outsourcing partnership does not need to be long or cumbersome, but it’s critical to a successful project. It’s an important aspect of not “throwing your project over the wall.”

If You’re Not Planning on Working Collaboratively, You Won’t Be Successful

Collaborative partnership in the outsourcing model is the process of bringing different teams with different skills together to maximize results. At Waverley we believe that great partnerships are synonymous with outsourcing. And partnership (as both a requirement and a benefit) is a two-way street. Each partner brings goods to the table and the pooling of talents and energy yields synergy: a whole greater than the sum of the parts. This synergy results in a product or service that is beyond what the client could have produced on its own. We encourage our clients to think like partners. We are bringing our top talent to help our clients successful; we want our partners to think the same way.

Transparency is Good, Micromanagement is Not

We believe that transparency is critical in an outsourcing relationship. By transparency, we mean that all team members are available to the client. Nothing is hidden and there is no single central point of contact that the engineering team hides behind. However, roles and management are still critical. On larger projects, it makes sense to have a team lead, a Client Manager, UI designers, and a documentation team. At Waverley we believe it makes sense to leverage our considerable skill in engineering project management. It’s easy to fall into the trap of managing each engineer remotely over a large number of times zones, but this style of engagement is not scalable, tends to cause frustration and slows productivity.

Expect to Have Some Issues and Work to Resolve Them

Working together on any creative or technical effort is complex by nature and bound to hit snags and stir controversy. Accept that this will happen, welcome tough questions when they are asked, ask tough questions that you may have and be willing to work together to address issues as they come up. Working this way builds both trust and confidence.

Understand Your Goals up Front

Understanding your goals is critical to success. Goals drive your overall work on a project towards a vision that has been clearly stated up front. While stating goals such as “high quality,” “on time” or “low cost” are obviously important, more specific goals are needed too. For example, if the project is about delivering a backup solution, then it may be crucial to have backups restart in the event of power or network failure, and it may be essential for a restore to work perfectly. When management states goals clearly, the team will know what to do to make the project successful.

Build Momentum Slowly

One way to establish a new outsourcing software development services relationship is to start with something small. This allows everyone to learn how the organizations fit together before moving to larger, more meaningful projects. We call this “crawl, walk, run.” Like trust, momentum can’t be rushed. The up-front time investment is good for future, more substantial efforts when the partners are in the “run” phase of a relationship. This is when we can read each other’s minds, tell jokes, and create amazing high-quality products on-budget.

Waverley understands that hiring an outsourcing vendor isn’t easy. As a client you have to be methodical and focused in your selection process. You must involve several people so that your final choice will have broad support in your organization. You might include multiple people on the selection committee, negotiate carefully, and it’s still a challenge to select the right company for you and your project. Although you’ll be examining a broad range of capabilities and have industry-specific criteria for making outsourcing decisions, here are five key questions to ask (you might also ask these questions of each candidate’s references).

Does the outsourcer have the right experience for your project? After you’ve verified that a company has the right industry, domain, technical, and management experience, it’s time to dig a little deeper. First, a larger company may have people with the experience you need, but have those people worked together to complete a project like the one you have defined? It’s like the difference between a general contractor who has an impressive list of subcontractors who don’t know each other and one who has a tight-knit group of craftspeople that he has used on many projects. Second, are you looking for a full-service vendor or for one offering specific expertise? If you’re planning to turn over day-to-day decisions on the project to an outsourcer, then a full-service vendor is likely to be appropriate. If you need a vendor for specific engineering needs, then a smaller, best-of-breed company is a better choice.

What tools and processes do they use? Before you can commit to a vendor you need to know how they invest in their resources. This can include their equipment and infrastructure, the training they provide their staff, and the internal development they do to stay on the cutting edge of their engineering specialty. If the company can show that it continues to invest in itself and its people, then it will likely also be able to show how the company continuously improves both its productivity and the quality of its work.

Do they leverage their experience across several projects? Unlike your own internal team, an outsourcer is exposed to many other companies and their practices. Smart outsourcers pick the best of these practices and make them their own. As a client, you get the benefit of this exposure. The outsourcer will bring fresh ideas to your organization and can pass on industry trends and new techniques. Of course this only applies if the outsourcer leverages exposure and experiences. Talk to them about how they (formally and informally) leverage their experience across client companies and incorporate this experience into their working methods.

Who will you be working with? Often the senior person who sold you the project “disappears” once the project starts. While it may be understandable that the person who sold you the project doesn’t end up managing it, that doesn’t mean you shouldn’t be able to meet the Project Manager or Program Director before you decide to go forward. And what about turnover? While total turnover numbers don’t tell the whole story, double-digit turnover numbers are a red flag. Look for vendors where turnover is low, especially at the senior level — not only will engineers at these companies be used to working with each other, they are also more likely to keep the same engineers for the duration of your project.

How do the outsourcer manage the project and their communication with you? Outsourcing projects that don’t succeed most often have communication issues. Ask the outsourcing company how its employees communicate day-to-day, how they initiate a project and lay a good foundation for productive relationships. One way to understand how an outsourcing vendor will communicate with you on the project is to watch how they negotiate. If the negotiations are clear and focus on everyone “getting to yes,” then that is an indicator of how the project will be managed. If the negotiations are less transparent and the negotiators view the end as a zero-sum outcome, that can indicate another way that the project will be managed.

And remember that a quality outsourcing shop will be evaluating you at the same time that you evaluate them. At Waverley, the key characteristic we look for in a new client is the potential for a long-term relationship. Even if a client is planning to start us on something small, we ask ourselves whether this is a company we could picture doing business with for many years. That’s a question you might ask about your potential new outsourcing vendor.

Waverley is an outsourcing software development company, but over the years we’ve learned that not every engineering project is a suitable candidate for outsourcing. Projects that engage core competencies, require significant internal management and coordination, or for which there isn’t a significant cost advantage may be better tasked internally. But many other projects are either suitable or may be suitable with some forethought and planning. In this article we review key questions that highlight some trade-offs of the make-or-buy decision for application development.

Is this a project that would require a large investment on your part if you did it internally? This is more than a financing question. There are a limited number of core capabilities in which your organization can develop innovative and operational excellence. If the project you’re planning fits within that group of core capabilities, it may only require a modest additional investment and it may be reasonable to keep it internal. But if it is outside your primary areas of expertise and not in an domain in which you plan to make a large investment, going to an external engineering firm makes sense. As an example, say you need to make your software available on a server platform your organization isn’t familiar with. This is a good project to give to an external player that develops and ports on this platform all the time.

Is outsourcing this project an idea that your internal team can get behind? Hiring an external company to do a project is likely to have organizational implications. If your internal team is going to resist giving the project to an outsourcing company, you’ll have to consider the trade-offs. If the reasons to go outside are compelling (no resources internally, time-to-market is critical, out of bandwidth), then internal resistance is something to manage through. If the reasons to go outside are valid but not vital, then perhaps there are ways to work around the resistance by putting clear boundaries around the project requirements: making it a black box. Or you could make an effort to build a strong relationship between the two teams, combining the outsourcer with your internal people.

Is this a project you can put clear boundaries around? Some projects require more integration with teams and individuals than others. A porting project can be clearly defined and handed off to another group with less need for interaction with your teams. A systems integration project on the other hand will require extensive and ongoing interaction and negotiation with your organization, making it a more delicate project to outsource.

Does outsourcing this project give you more flexibility in managing your resources? Let’s start at the extreme of a project that you would not outsource. If you have an engineering function that has a predictable workflow, is part of the core capability of your company, and is constantly in need of changes and additions, it would not make sense to outsource this function. Moving in the other direction — projects that are less a part of the core, have intermittent needs for resources, and unpredictable workflow, these are projects for which it would make sense to cultivate an outsourcing relationship to absorb the fluctuating demand for resources.

Does outsourcing this project give you access to expert knowledge you might not otherwise be exposed to? One of the benefits of going to an external company is that they can expose your organization to new techniques and practices. The outsourcing company has done many projects of the type you need to be done, they’ve worked with many clients in the industry and seen what works best. They may even be driving industry standards and practices. Working with a company at the forefront of a particular technology can mean getting the project completed at lower cost while exposing your organization to cutting-edge practices.

Writing in CIO Magazine’s December issue, Meredith Levinson says Mobile Software Developers will be in greater demand in 2012 than they were in 2011, and more expensive. While you don’t want to be caught without a strategy to meet your near-term development needs, it’s important to not let scarcity drive you to make an questionable hire. Here are four simple things you can do to reduce your risk when hiring new developers:

1) Find the developers’ apps at the various app stores, download them and try them out. Look for attention to detail and the overall quality of the app. Does it look clunky or does it feel well done?

2) Does the developer have experience on more than one platform? Do you need more than one platform? How well can you deliver your intended experience on various mobile platforms and how can the developer help you with these decisions and associated tradeoffs?

3) What’s your strategy for deciding between native or web apps, and does the developer you’re looking at match up well with that strategy?

4) Do you want the app to be created with tools that can accelerate development? The Titanium platform from Appcelerator is a good example.

Here’s a great article from Bright Hub  on how to move from the Waterfall model of project management to Agile:

How do you write a fixed-price contract for a embryonic Agile proposal? It’s not as difficult as some make out but it does involve a change of mindset and a learning exercise for everyone. Clearly defining “done”, estimating stories and understanding velocity is key to getting it right.

Don’t Tie Agile Down

If the whole idea of Agile is that you cannot predict the future, then how can you use it in a fixed-price contracting environment where it is vital to tie down your costs, your time and your scope? Maybe the answer is to look beyond tying Agile down to ill-fitting contract templates and introducing a new structure. Read the whole article.

You wouldn’t buy a business or make a big investment without taking the time to investigate the facts and circumstances relevant to your decision, right? In business we perform due diligence in all kinds of transactions. We expect all the cards to be on the table, and we’re rightfully upset when important details are deliberately concealed. But all the diligent fact-finding in the world won’t stop us from concealing things from ourselves when a confirmation bias gets in the way. Also called a “my-side” bias and recognizable as “wishful thinking” in some, this is the tendency to give more credence to information that confirms our beliefs while ignoring input that would create discomfort if we really let it in.

A scientist knows he needs a built-in safeguard to protect against confirmation bias; it’s basic to any research design. A good scientist will actually spend quite a bit of time trying to disprove his hypothesis. He may even go so far as to enlist another scientist with another point of view.

So why don’t we do the same in business? Sometimes we do. We hire consultants who don’t share our presumptions, beliefs and expectations. This is a large part of the value a consultant brings; he or she is able to challenge the prevailing belief system. Too often, though, people who don’t share our biases make us squirm. We question their loyalty, wonder if they’re team players, and spin our wheels defending our existing beliefs instead of simply sitting with the discomfort and taking action, based on the facts. We might even avoid fact-finding altogether if the implications are more than we’re willing to look at. This is how business activities get backlogged or sidelined.

We’re somewhat predictable, we humans: people will opt for a pleasant thought or pleasing future scenario over an unpleasant one. And we’re also over-stimulated. Who doesn’t take in far more information and detailed bits of data than he or she can realistically process in a day? No wonder we push aside unpleasant details that conflict with our preferred view of things. It’s a problem that’s as old as the hills… or at least as old as the Greeks. As Thucydides wrote nearly 2500 years ago: “it is a habit of mankind… to use sovereign reason to thrust aside what is not fancied.”

What do you do when all you need is a single developer for a fairly small project? Why not pull someone in from the developer marketplace, check the boards and find a low cost engineer? Reasonable, right? Not quite. Here are several reasons to give the job to an outsourcer, even if the job is small:

1. It’s safer. You know you’ll get a trust-worthy engineer, with a well thought-out process of engagement and zero risk of some wildcard-loose-cannon-hot-shot of a developer who looks brilliant on paper but is behind the curve when it comes to depth of experience.
2. You’ll get skilled management (good communication is everything, especially on a small project), which increases the chances that one person will succeed — at little to no extra cost.
3. A good outsourcer also provides the required infrastructure (a secure, class A environment). You’ll need to evaluate the whole security question and make certain you can protect your firm’s IP and have your ducks in a row. Can any one-off developer do all this on his own? Not likely.
4. And what of that moment when the unexpected happens and you suddenly need more than one developer — immediately? Or if your “quarterback” gets taken out? Where is your back-up going to come from? Wouldn’t it be more reasonable to work with a guy who has a whole team around him should an unexpected need arise?