In Two Days I Improved Conversions By 28%. So What Went Wrong?

At National CineMedia, when it was noticed that our regional clients were only able to successfully upload their media files to us 40% of the time, I was asked to take a look.

Upon initial examination, I couldn’t understand why the completion rate would be so low, but I did have some ideas. The first thing I noticed was that the layout of the form was difficult to read, and also didn’t seem to have logical grouping, leading to user confusion. For example, is the confirmation email supposed to be for the agency or for the account director? Maybe I should just use the help bubble to find out?

Um, maybe not.

The other immediate issue was the difference between Order Number and Job Number. Does a client know the difference? It turns out, not always. In fact, on their paperwork, Job Number is actually listed as Creative Number. Also, these are both required elements. If a customer skips one because they can’t find it, the process fails. And why it fails is because we have an automated system that reads this data coming in and filters media into the right bucket. Incorrect fields break this system.

Should we use the help bubble?

Ah, and there’s another issue with the Order and Job Numbers. They have a specific format, which is not followed consistently in all of the paperwork. Put it in wrong and, yeah, you get the picture. So here’s the first step I took – redesign the form.

The first piece to this was make it vertical. If the space is available, which is is here, I always suggest this. It created a natural “step” process for the user. Look back at the old form. Do you go left to right and back to line 2, or column 1 and then 2? That kind of mental challenge is alleviated here.

Next, I put in the understanding of grouping. The top is all NCM information, the bottom is all client information. Do you wonder who’s email to use now?

Thirdly, the most common questions clients had about each field were answered in short sub-label form with each of the field labels where it made sense. Order Number and Job Number are required, and not just because we ask, but because you may miss your start if not done properly. And to ensure they are done properly, watermark text was also inserted into the field as a simple design affordance for the user.

Next, the hint bubbles were kept, but rather than some ambiguous text, they were populated with screenshots taken right from a client contract. No more wondering where to find things. Oh, and I changed the title from Job Number to Creative Number. That makes a little sense, eh?

And lastly, in the case someone still needs help, I “unhid” the ability to do so. On the old version, if you had trouble, here’s what you could see:

Not only is this really bad grammar, and slightly hidden, but it doesn’t let you know what you’re going to find. Do I really want to click this? Will it take me away from this page and delete the work I’ve already done? Overall, just a bad experience. So I brought it up into the page where it needed to be, and gave it some context.

I also added a link to a new .PDF that was a nice, visual, step-by-step guide to completing this form, just in case there was still confusion. And this was placed before the phone number, in hopes that a call was the absolute last resort. Turns out, the calls went WAY down. In fact, when related to filling out the form, they all but disappeared.

And now, the results!

Before the updates, the success rate for media uploads was around 40%. After the above changes, which were researched, designed, and developed over a two-day period, the success rate jumped up to 68%. If you were to ask me, “Hey, Brad, is a 68% success rate something to write home about?”, I would have drop my shoulders and mumble “well, no”. So what went wrong?

It’s fairly simple, actually, and I’m not going to take the blame. This site utilizes the Aspera High Speed File Transfer Software, which is a browser plugin, and a very difficult one at that. I know this is the reason for the majority of issues on the new design because we have a help desk, and those are now the calls we receive. The good news is that we identified a new tool created by Upload Care and tested this last year with our Cannes Lions contest page, where hundreds of large media files needed to be uploaded and automatically placed into folders. The success rate for this tool was 100%. It is now planned to be the replacement company-wide for Aspera.

Using Feng Shui Principles to Help Web Usability

Feng Shui, a Chinese philosophy that dates back over 3500 years, is the study of all forms of energy, including the energies of spaces, and how those energies affect people . In the last decade, Feng Shui has become a regular practice in America for architects and interior designers on every scale imaginable; it has been adopted by such well known companies as Coca Cola, Hewlett Packard and Citibank. Historically, implementation of Feng Shui models has been used primarily in three-dimensional realms, however, with parallels to design theory and environmental and behavioral psychology, it follows that principles applied in architecture and interior design could be similarly applied in two-dimensional design and provide comparable benefits. The principles of Feng Shui–flow, balance, position, color, shape, and command–provide a solution that can be incorporated into website models, thereby increasing overall website usability.

Just like architecture in buildings, websites use similar elements of form in their architecture. A website’s improper design is a distraction, much like scaffolding is to a building. Using Feng Shui principles to provide a more user friendly experience on the web will help to reduce these distractions, adding to time on page, page views and increasing overall usability.

This research will combine principles of Feng Shui and its powerful tools of expression such as color and shape, to create a new language for website design. Using this new technique, a website will be fully optimized to bring a user to their end goal. A user enters a web page with a specific goal in mind, not expecting to be subconsciously influenced. By analyzing current web design practices and environmental and behavioral psychology, web users can be persuaded to spend more time on a website while reducing the possible negative experience associated with many current Internet practices. Further, this information will provide a solution to improve and streamline the user experience. By creating this solution, incorporating these principles into today’s web design practices will not only increase website performance and usability, but also provide a new guideline that can be followed to achieve that goal.

Included is an analysis of three disciplines–web design, graphic design and psychology–as they pertain to companies’ on line presence, particularly in the success of website performance and usability. This can be achieved by combining all three disciplines under the premise that they can follow Feng Shui’s principles and be used together harmoniously. As there is no study done to date that analyzes Feng Shui and it’s integration into website creation, each field of study–Feng Shui, psychology, graphic design, and web design–will be separately analyzed and conclusions will be made where parallels are found between the three. Each section explores a basic principle of Feng Shui and how it applies to human emotion and interaction through it’s relevance to current design knowledge. This review will analyze these different practices and how previous research can be used to show where these three fields of study can work together to provide a more successful framework for web design, as it pertains to website performance and usability.

Feng Shui

Feng Shui is a body of Chinese wisdom in knowledge and experience relating to the built environment, that has accumulated over more than 3000 years. In that time, many different theories within Feng Shui have been developed for numerous applications. Most contemporary Feng Shui scholars have set up their own criteria for Feng Shui design including criteria for: architectural design, landscape models, location selection, interior design and furniture placement. There are two schools of thought in Feng Shui, the compass school and form school. Compass is more focused on the metaphysical speculations, whereas the form school is more concerned with the physical form and its surrounding environment. Because of the nature of a website–having an actual architecture and visible elements, but also existing in a virtual environment–both of these schools of thought have principles that apply to the complexity of a website and how humans act within its space. Since the Ming Dynasty (1368-1644), these two schools of thought were not exclusively attached to their own methods for the practice of Feng Shui, but rather combined and integrated ideas from both. Therefore, neither school will be discussed in particular.

Almost every problem that arises in a space will relate to the flow of energy and the balance of energies. Though previous understanding of Feng Shui refers to the three-dimensional idea of the built environment, it, as well as the principles associated with Feng Shui, can also be applied to the Internet’s constructed environment. When mapping out a website, one of the starting points is creating a site map, or flow chart. This controls the way the back end or internal workings of the website will function and be organized. For the front end or the portion of a website that an on line user views, designers create a graphical user interface (GUI) to control the appearance and user navigation of the site, working in design principles which place heavy consideration on balance. From a website’s inception, flow and balance are key factors associated with its potential success and are practices to reduce problems before they arise.

Flow And Balance

Flow, also known as chi, as it relates to Feng Shui, is energy that moves through a space and affects our level of stress and our behavior. Spatial organization of a website should be used to increase a web site’s chi, providing a more comfortable and integrated user experience. Energy naturally moves in a curved motion, so with a very geometric platform on which a website is built, how can a website increase the flow of something curved? The practice of Feng Shui is an intuitive matter involving site selection and spatial organization, and it has strong parallels with the Western concept of geometry in architectural design. A website does not necessarily need to be built with more curves, but built so that the elements making up the site allow for a curved flow of energy to easily move through the space. This flow relates to composition and layout, as in design, typography and photography, but also has a more spiritual aspect, which may provide another level which can be incorporated to improve a site’s success.

A user enters a website with a specific goal in mind. Properly moving them to their goal in the shortest amount of time will directly affect a web site’s success. Components that are placed at the top of a page tend to be perceived as more important and creating a visual hierarchy on a web page can make it easier to understand, consequently making it more usable. This increased understanding of a website is achieved through analyzing flow and balance of components on the web page, and using that flow to direct the user to their goal.

Research indicates that whether a user finds a website visually appealing often has a powerful impact on forming perception of website usability. This formed perception is better understood as the first impression; the first thing we see puts our subconscious to work. Studies in eye tracking technology have shown that when a user enters a website, their first few fixations rested on the center and top of the pages, suggesting that these areas may play an important role in forming the first impression of a page. Therefore, true to Faraday’s theory of visual hierarchy, importance of a website does have a natural starting point, being the top or center of a web page. In the Feng Shui schematic design checklist, one must be aware of the impact of the first view upon entering a building. Developing good website chi requires developing a design plan that begins with understanding this focal point.

Once a focal point is found, what is it that keeps a user engaged on a website? While users may move away from a website for technical reasons (slow download) or content reasons (the information on the page), studies suggest that form can also be a reason for moving away from a website. Once the focal point has been identified, the continuation of that flow, or energy, must be created. There is an overall user preference of aesthetic content over loading speed, and the most important variable is information layout. There are two driving aesthetic factors behind a successful layout: symmetry and complexity.


Symmetry is a structural variable that reduces complexity. In architectural Feng Shui, a main entrance to a building should be in the center to create a feeling of balance. Studies in web design have found that users viewed asymmetric web pages more negatively than symmetric ones. Vertical symmetry has an impact on intuitive straightforward beauty appraisals and on classical and expressive aesthetics judgments made by the participants. With balance being an important factor in Feng Shui, and symmetry being the shortest answer to creating balance, its understandable that symmetry can benefit website usability.


As mentioned above, symmetry also reduces complexity. The reduction of complexity facilitates viewers’ processing the given information which will result in a more positive aesthetic response toward the stimulus. This positive response from reduced complexity leads the user to another important subconscious conclusion that drastically affects the success of a website. Visual design of the website results in trust, satisfaction, and loyalty. Furthermore, websites that match the users’ social and emotional perceptions are expected to increase trust and be more engaging. By simply analyzing the flow and balance of a website, one can design with a new focus on the emotional comfort of their customers.

Commanding Position

Commanding position is a theory in Feng Shui long used with the placement of furniture. For this study, the furniture in a room as seen in Feng Shui, is translated as the elements on a single web page. A website needs to make clear to everyone entering the site who is in control of the space, or what message is being conveyed. Without this initial statement, a user may not generate a first impression that their goal can be met. Similar studies to the Feng Shui principle of commanding position have been done for website usability. Pages that included a main large image were rated as the most appealing, and those that did not were rated as least appealing. The size of an object is an important factor in its perceived visual importance–the larger the item, the greater its importance and, consequently, the higher its level in the visual hierarchy. When designing a website, with the users’ goal in mind, the commanding position, or commanding image in this case, should be relevant to the main message of the website, driving a user to continue, comforted that they have reached the correct location.

Color And Shape

More than just inserting a large image or text block, shape must be a consideration. According to Feng Shui’s principles, a regular shape (rectangle, square, or round) has the most comfortable impact on an individual. This may be another reason to believe that the flow of chi does not necessarily need to be a curved flow, but reflect the flow of a user through the websites’ content.

In his work, Leonardo da Vinci used the mathematical ratio of the Fibonacci Sequence and is considered the creator of the concept of the golden rectangle, a Feng Shui principle which is a simplified version of Leonardo’s work. The golden rectangle–with a ratio of 1 to 1.618–reflects the proportions that are most often found in nature, from a flower to the proportions of a human figure, and can generate a positive aesthetic response. There are two main approaches to investigating aesthetic responses: one that investigates reactions to the whole object and one that examines reactions to isolated parts of an object. In website design, the viewable area on the majority of computer monitors is very similar to the proportions of the golden rectangle. Therefore, a proper Feng Shui approach to web design would not place any important content, or continue images or fields of information, below the fold–the section of your website that is viewed before a user has to use the scrollbar. This section reflects the whole object. The content included in the fold–text fields, images, advertisements, navigation–can also be designed with the golden rectangle in mind, particularly the image or text field used in the commanding position.

Perhaps just as important as shape in web design is color. As with flow and balance, results reveal that website color appeal is a significant determinant for website trust and satisfaction. Trust is built when, especially with Internet users, privacy is not a concern. Given that deception is particularly easy on line, consumer awareness of manipulation is higher. Applying the principles of Feng Shui such as flow, balance, shape and color can directly affect the success and overall usability of a website by addressing a consumers’ trust issues aesthetically, and on the first impression.

Consumer oriented websites that match the social and emotional perceptions of users are expected to increase trust and be more engaging. Color can be a direct link to matching these perceptions. Colors affect us both physiologically and psychologically and impacts our psyche on the conscious and subconscious levels. A web designer who aligns their content with a Feng Shui color model may be able to address the goal of their user on a whole new level.

The Bagua color theory in Feng Shui uses hues in general color areas to convey an image of the desired intentio. Colors in this theory can easily be used to enforce an emotion expected of a web user. If health is to be conveyed on a website, perhaps the color yellow should be used to build upon that user’s expectation of what they will find on the website. The primary purpose of a space is probably the most important determinant in the choice of the basic design color for that particular environment.

Feng Shui color theory specifically mentions the Bagua color theory and  the Five Elements of Colors. However, psychological studies and the effects of color on people are also taken into account to create a palette that completely represents a websites’ message. Some colors serve to arouse and excite an individual, while other colors elicit relaxation. Though in website design, little is knows about how color affects trust or satisfaction on the part of the viewer. Properly recognizing the web site’s goal and combining the proper colors to support that goal will build a strong backbone for usability and customer trust.


An underlying factor in the use of Feng Shui is the power on the subconscious mind. This subconscious effect is present from the first impression to the time someone leaves a website. One of the most powerful uses of capturing a subconscious mind is the ability to control behavior. In banner blindness–a phenomenon where users recklessly skip over any text that they deem to be fluff – the subconscious mind controls the behavior to ignore the content associated with a web banner. In web design, this control of behavior can be the difference between success and failure.

Properly combining the principles of Feng Shui – flow, balance, commanding position, shape and color–produces a new level of consumer trust in websites. According to the social presence in communication theory, by creating a feeling of warmth and human contact, websites can create a psychological connection with their users. The balance of complementary aspects of our environment, whether colors, shapes, materials, or other design components, greatly affects the way we feel and behave. Flow and balance provide a comfortable path to the user’s end goal, while shape and color provide the warmth and contact to keep them on that path, knowing they belong there because the commanding message told them, honestly, that they were.

In Conclusion

For centuries Feng Shui has been applied to many fields, and now initial observations and experiments will be made into its successful application in web design and usability. The parallels between architecture and web design allow for Feng Shui to be applied in both models. Flow, balance, position, color, shape and command all have roots in Feng Shui, architecture, and web design, and previous studies show that these principles, as delineated in Feng Shui, should translate well into increased usability on the Internet. Eye tracking data will enable a thorough and precise examination of the areas of the page that attract participants’ attention, while the heuristic will compile data from a more natural Internet experience–pointing and clicking a mouse. Though differences will likely exist between females and males, past research suggests that the majority of participants should react to the stimuli as expected, preferring the models created with Feng Shui principles incorporated.

Past studies of design psychology and Human Computer Interaction (HCI) provided a good basis to begin studying the effects of incorporating Feng Shui into this two-dimensional realm. Just as commanding position has been used in furniture placement to increase a CEO’s control over his business, Feng Shui can use commanding position to increase a website’s control of a message. Effects of color schemes on human emotion have been noted in psychology for years, and have been a large part of the Feng Shui Bagua color theory. By combining many of these studies through their documented parallels, Feng Shui will produce better web usability.

The research to be conducted only examines a small effect on web usability, therefore it is recommended that further research be conducted to identify stronger connections between Feng Shui and web usability. However, after this initial round of research, it is also expected that Feng Shui principles included in common web design practices can be a viable alternative, or powerful addition, to today’s current design models. Through this research, many successful applications of Feng Shui principles are expected to surface which, when implemented, show promise to increase a web site’s time on page, page view, and usability statistics. Using Feng Shui can improve the visual appeal of [a website], potentially leading to a higher rate of return and the attraction of more users.

With the ever-changing world of technology, web designers are constantly looking for more ways to market themselves and prove successful solutions to businesses. Concurrently, businesses are looking for better ways to achieve success over their competitors and find resources to help them in that search. This work becomes important in that it recognizes another means to differentiate a website from others in a factor not normally considered in today’s web design practices. Because of the parallels between Feng Shui and better known design practices, it is also likely that this study will open new avenues for Feng Shui to be incorporated into other two-dimensional fields, such as painting and illustration.

Mastering Project Management Within Any Development Environment

To be a successful project manager in a software development environment, one must know more than the “best practices” for managing a project. In software, it is often not known what the final product is going to be at the inception, nor is it known the path that will be taken to create the final product. It is a project managers responsibility to recognize how much can be predicted, how much will be created along the way, the process that will be used to create the product, and how to successfully communicate all of this to the stakeholder – an end user, a purchaser, a contractor, a developer, or a project manager – while keeping time and budget constraints in check.

Perhaps one of the biggest challenges in project management, as it applies to software development, is choosing the development method  (assuming the upper management or client will let the project manager make that decision) from a wide array of choices. Lets take a look at mastering the art of project management in any development environment, focusing on the differences and challenges of the high-level categories of iterative or waterfall development processes, rather than breaking it down into each method. Various people make distinctions among development processes, but the distinctions are neither widely agreed on nor that important compared to the iterative/waterfall dichotomy. One important factor that is taken into consideration is that a master project manager has more control over the development environment than the other way around. A common occurrence in today’s business environment is stress incurred from naming the development method used but not actually following the method’s rules, many times out of a lack of understanding of what the rules actually are for any given methodology. A strong project manager will understand that rules are meant to be broken and tailor the style to meet the project needs. Call the method what you will, but in the end the right development process is the one that delivers a successful product through a hybrid approach. No matter the approach, there are a few specific phases that must be present in any SDLC (software development life cycle) if anything is to happen: planning & requirements analysis, design & development, integration & testing, and implementation.

I’m going to assume here that there would be no need for a project manager if there were no project, therefore, a software need has already been identified and it is now time to plan everything. The planning & requirements phase of a SDLC is perhaps the most varied cycle depending on the chosen development method. This is also the point where the general development method should be chosen. There are seven factors that should be questioned to find the proper fit of process to project:

  1. The kind of system you are building.
  2. The technology you are using.
  3. The size and distribution of the team.
  4. The nature of the risks.
  5. The consequences of failure.
  6. The working styles of the team.
  7. The culture of the organization.

Many of these 7 factors can be analyzed and tentatively decided upon before a team is even assembled, however, it should be a continual analysis during the course of the entire project. Before development begins, and after the team has been assembled, the official decision making can begin. The most suitable process for a software project should be discovered during the initial requirements phase, not before, when a team can tailor the framework to best fit the project needs.

The Team

With larger companies that have a pool of talent, a team should not be assembled until the initial scope of the project is analyzed and the first ideas as to what type of development method have been assumed. It is then that a project manager should be assigned and asked to assemble the team. A project manager is an integral part of the team; most computer programmers suffer from profound deficits in the following areas: thinking critically about what a computer application should do, writing down a design, writing down an implementation plan, documenting important features or design decisions, exercising good judgment and communicating project status. A PM can fill these slightly important needs. As humans, it is easy to get comfortable in our ways, and it is important that a project manager be adaptive to accommodate any project environment. The PM approach should be tailored to the project type, however, the PM should also assign the type based on the project requirements. It is not fair to any project that a PM use their bias to assign a project type only because they are more comfortable in that environment, when doing so could jeopardize the projects success. This is where the importance of understanding multiple project methods and experience can prove to be a huge asset. That being said, we are still human and one PM will be more suited to a certain method than another.

The most important factor in a projects’ success is the quality of the people on the project and how well they work together. The process and tools they use are strictly second-order effects. Choosing the right team can facilitate progress and release the temptation to micro-manage. It is important for the PM to create a self-driven team, rather than relying on command and control. A common practice suggested for iterative development, but that also should be recognized in waterfall methods, is choosing teams that are selected based on the skills required for the project. The second concern which should be addressed when selecting a team is availability. For smaller companies that may only have enough employees for one or two teams, the luxury of choosing members by skill set and availability might not exist. In that case it is especially important for the PM to develop a strong plan to deal with adversity.


A projects first stage shouldn’t deal with product design, but rather with designing the development process itself. Two main positions exist in software development: classic plan driven development and more contemporary iterative software development. One of the most well known methods in plan-driven software development is the waterfall model, where each phase of the project is planned in advance and there are clearly delineated interfaces between phases often called “gates”. The more agile iterative development methods kick in when not all of the solution is clearly known. What’s needed is not a single software methodology, however, but a rich toolkit of process patterns and “methodology components” (deliverables, techniques, process flows, and so forth) along with guidelines for how to plug them together to customize a methodology for any given project. An idea of the general properties of the two development methods is displayed in the table below.

Waterfall Iterative
Low Customer Involvement High
More Documentation Less
Smaller Project Size Larger
Larger Team Size Smaller
Many Known Requirements Few
Less Frequent Communication More Frequent


It is important that the PM learn the patterns and attributes associated with many of the most popular development methods to be able to function within them, change them, and successfully support and explain to stakeholders why they are being used on a project.

Requirements Analysis

Properly identifying the requirements of a project is the first challenge in mastering project management and planning a project. These requirements are the key to deciding on the right development method, and a good understanding of all models is integral in continually making intelligent management decisions.

Requirements analysis can initially be overviewed by just the PM, but continues with the entire team working together. Many times this entails brainstorming and modeling sessions using tools such as the UML (Unified Modeling Language) to map out the plan for the software project. This plan can also serve as a great identifier of the development process that should be used. Consistent with the model above, if the system has most of the requirements known at the start, it is much easier to take a waterfall based approach, which endures because of the desire for predictability in software development. Predictability promises less deviation from a solid plan and helps with recognizing costs and duration, and is good for keeping happy stakeholders. Predictability does not, however, dictate that a waterfall method must be used. It may be safer to try and steer the stakeholders towards a planned yet flexible process to allow for any change. Predictability is an illusion and cannot exist within today’s changing technology and market conditions, and companies and clients need to face the reality of constant change. It is the PM’s job to communicate this change well.

Client Needs

The client is just as important as the software requirements when it comes to selecting the right software development method. A client who wants to take a back seat in the process will probably feel more comfortable with a plan-based approach to development. Iterative development methods require heavy client involvement on a regular basis and end up failing if this involvement is not achieved or sustained. Many customers now are specifically asking for iterative methods in their software projects because of their adversity to surprises (often arising with the low communication and lack of iterations in the waterfall method). Unfortunately, it is also common that if a PM cannot keep the client involved, the project tends to revert back to “management by plan” which, in turn, severely limits agility resulting in more of a waterfall mode. Customer involvement greatly dictates the development method that will be most successful for any project, and a good project manager stays alert to this. The customer and the PM are both decision makers in a project with the customer knowing the business, and the PM knowing the technical aspects, however, the end decision should be made by the PM. As long as expectations are properly documented and consistently met, the client will trust the PM and the decisions they make. Customer involvement must always be monitored as a more customer-centric iterative process has a greater frequency of failure if the customer wants to be on the sidelines.

The PM must also figure out what the users and customers of a software effort want the system to do to properly identify the requirements. If less is known of the requirements, an Iterative method – a much more customer-driven approach – has a better chance at success because of the ability to innovate as the life cycle develops. Innovation starts with requirements, and elaboration should include diverse perspectives and skills including the end customer, developers and testers.

Planning The Plan

Mastering project management also depends on being able to master your project management plan. A tall order when a flexible plan is required to properly manage a dynamic development environment. Not only should there be an SLC (System Life Cycle) chosen for the development, but there should also be a supporting PLC (Project Life Cycle) in place for the management of the project. A project manager should have a general plan laid out that they generally follow, as well as common tools that they use, but there is no one “best practice” that fits all projects & situations. Managers must select a combination of practices and integrate them into a coherent process that’s aligned to their business context. Changing from a static project management plan to one that can be more dynamic can have many differences:

  1. Focusing on planning & scheduling using iterations as opposed to planning & scheduling an entire project.
  2. Using teams that are smaller than traditional teams where team members are selected based on the skills required for the project.
  3. Including customers throughout the project and meeting on a daily basis for a short period of time in contrast to traditional weekly meetings.
  4. Creating less documentation.

Though a master project manager will have a variety of strategies for different development methods, just like a website, it is better to be dynamic than static to allow for changes as they arise. Any one of the above items can, and should, be adjusted if the project success is being threatened.



Design & development happens in every project. It may be in a big gathering of the minds at the start of a project in true waterfall fashion, or it may come in iterations. However this happens, it is important the the PM constantly keeps up communication with all stakeholders. The PM must also understand that communication consists not only of speaking, but is also written and body language. Good communication is at the core of all successful projects, and there are some simple ways to keep communication flowing:

  1. Proximity – Greater communications come from a team that is closer to one another.
  2. Temporal Proximity – Teams that work the same hours have better communication.
  3. Team Morale – High morale = high communication.
  4. Tools – Complicated tools = communication barriers.
  5. Anxiety – Reduce anxiety by identifying the communication styles your team prefers and utilizing this knowledge.

Keeping a project under control relies heavily on good communication, especially when in an iterative environment there are rapidly changing variables.

The Team Revisited

Whether or not you use a waterfall approach, you still do the activities of analysis, design, coding and testing, and you need a team that supports all of these activities. The PM needs to begin the project by facilitating a rhythm that they will carry through the entire life cycle of the project. This rhythm is essentially the flow of good communication as mentioned above, keeping anxiety down and morale high. A PM with a good PLC in place, a strong understanding of requirements and development cycles, and good organization can manage without missing a beat, infecting the entire project team with an unbelievable energy.

This rhythm and energy that a PM has worked so hard to build can also be crushed if the right team is not in place and managed properly. An important factor that should constantly be reviewed in any project is how many people are involved. The size of a project team can depend on the number of requirements and how large the project scope is. For larger teams there is a greater need for more efficient communication and co-ordination. Before you lose morale and energy with a larger team, increased control of the project can be gained by the PM by continually assessing time estimates through communication with the developers. A truly adaptive PM also understands that just like requirements, team members can also be changed at any time.

Only around 20 percent of all IT projects are completed on time and within budget; an average project takes twice as long as estimated and is approximately 200 percent over budget; and projects regularly only deliver 2/3 of their planned scope. Definitely a scary statistic which can be mostly mitigated by the management of a PM and a properly selected team. Team selection continues through the entire project as new tasks come up. These tasks should be allocated as people become free, rather than on the basis of expertise, which reinforces the development of silos and indispensable “heroes”. Morale, as we all learned in gym class, stays higher when there is no “I” in team.


Development has begun and it’s time for the PM to go to his office and wait right? Of course not, that is a very poor habit for a project manager. Many times the PM is a previous developer who has moved up in the company, but it is important to know that the primary task of the manager is to have the right people do the correct work and, ultimately, to get the tasks done in the most efficient and least problematic way. Mastering project management depends on mastering your project management plan, which does not include solving code problems. In fact, there should be very little problem solving and much decision making. In the book The One Minute Manager Meets The Monkey, it is suggested that the manager train the employees (in this case the developers) to bring at least two suggested solutions to any mention of a problem, practicing “hands-off management”. The best way to develop responsibility in people is to give them responsibility, and the best use of your time is doing your own work, not the work of everyone else. Project managers can make more effective decisions when supported by the right tools and techniques for leading a project, and using those tools and techniques in the right way will have direct impact on the delivery of a successful project.

Both iterative and waterfall methods have their place and can be effective in different project contexts, depending on how much uncertainty exists and how much flexibility a team requires. Allowing a project to move around between an iterative and waterfall structure is essentially balancing flexibility with reliability. There is a danger in dynamic environments where allowances for change in a project can send the project out of control. This may be the point where a PM may call for a requirements freeze, kill the project entirely, or just revert back to a more waterfall approach for a period of time. Rapid changes in the environment, including tools and methods, and attempts to innovate, act to push the project into an iterative model, increasing unknowns. The challenge is to conduct exploration at a greater rate than the emergence of environmental change, keeping requirements relevant. Change in requirements can be counterproductive to the success of the overall project and should be carefully scrutinized.


A good way to remove yourself from the mindset that you know whats best is to keep a detailed log of what works best in each project. Learning from the past is invaluable and often overlooked. There are many differences in the iterative/waterfall dichotomy when it comes to documentation at the development level, however, a strong plan for documentation should be in place for the PM. There are many types of documentation in a project including documentation for: the team, the management, the client, the PM, or simply to generate ideas.

Tracking results from elements of different development methods and how they were used in problem solving can be invaluable to the future success of software projects. The use of qualitative methods would not only provide insight into qualitative results, but is a practical and necessary avenue to defining meaningful and consistent metrics; qualitative investigation could provide the context & background needed to compare results from different projects even when different methods are used. A well organized resource for learning from past decisions is the key to making future intelligent decisions.

For the development team in an iterative environment it is better to build something and then document it rather than document something and then build it. Even with a waterfall style project, this should prove true as well. Though waterfall suggests planning and documenting the entire product at the beginning, there is still a chance that it may live in a gravity-free environment or may move over to an agile process. A client may request a requirements or functionality change, negating the relevance of previously created documentation which could throw some wrenches into your team morale and overall cost. Development documentation has a knack for becoming irrelevant and out of date. This is not the case with management documentation and it would be good to find an understanding of what documentation should be kept for statistical analysis by the PM.

Reuse is a common term to developers, but this can also be a term associated with project management when paired with the idea of learning from other projects, teams etc. Documentation is king when learning from the past and is an important part of a PM’s repertoire. Without good documentation it can be very difficult, if not impossible, to learn from your mistakes. A continual analysis of things that are working, things that are not working, and changes that you have made can provide the basis for a solid decision making library.


With the right tools, a creative, hopelessly optimistic, and brutally honest PM can shine. Creativity can help identify next moves, optimism can recognize paths that have potential, and the brutal honestly can quickly halt a failing project. These tools are the ability to plan, select a team, make tough decisions, and keep documentation to learn from. In todays software development environment, perhaps the most important tool, is how to cater the development method to the overall environment.

In general, minimal empirical evidence exists to support the advantages of any one model over any other regarding cost, duration or quality. Requirements and clients should be the dictators of the development environment, and the environment in which a project is conducted directly affects the amount of dynamism required. The project manager should then tailor their management approach to the project type, and it should be the PM that assigned the type based on the experience they have and the documentation from previous adaptive projects. In software development events tend to arise at faster rates than is practical to re-plan for. Traditional management is simply counterproductive; it crates self-inflicted problems that seriously undermine performance.

Whether a project begins as waterfall and ends as iterative, stays the same, or wanders through many development models, there is no “best practice” for project management that can be applied. It is the responsibility of the PM to stay adaptive so that each project has the best chance for success, in the shortest time, with the least cost and the most satisfied stakeholders.

UX Design: Displaying Multi-Tiered Pricing and Discounts

The decision by management to start offering multi-tiered pricing to customers, as well as in-stock pricing sparked months of debates. When I received a project that required me to present management with over 35 different ways to present this pricing information to our customers, I realized it was time to stop debating and take it to our customers for the real answer. I sent out two surveys to over 300 users that had signed up for the MyArrow Impact Group and quickly solved the problem before it was time for the UI team to implement the new features.

The first immediate problem identified was the format for offering in-stock pricing:

Question: If Arrow owned inventory that it could offer for a lower price, how would you interpret the following image?

  • What price would you expect to pay per part if you were ordering:
  • 60 pieces? Correct 39/45 ($1.35)
  • 120 pieces? Correct 16/45 ($1.85)

As you can see from the answers, most users understood how this pricing would work for a purchase of 60 pieces, however, as soon as the order jumped outside the quantity range, only 16 of the 45 respondents selected the correct answer. The solution had over 93% correct answers; still not perfect, but much closer.

Now the fun part is how this solution was found. The process was a combination of surveys and competitor research. The majority of Arrow’s main competitors already used multi-tiered pricing on their websites (but not in-stock pricing). I took a look at each of their presentations and used them to customize Arrow’s pricing scheme, which I then took to the customer.

Question 1: In your opinion, which of the following methods best displays products with quantity breaks?

In question 1, I took the most common multi-tiered pricing displays and found that option C had over 78% of the vote. No debates there. I then catered question 2 to whichever option they chose in question 1 (using the most popular answer for this explanation).

Question 2: In your opinion, which of the following methods best displays products with quantity breaks?

As you can see, in question 2, I showed the quantities in that users’ favorite style and introduced alternate methods of displaying all the pricing information. In this scenario, 80% of respondents chose option B.

For the 3rd and final question regarding display of multi-tiered pricing, I wanted to find out if availability or pricing was more important to the users.

Question 3: In your opinion, which layout provides the best information for making your purchasing decision?

67% of users selected A as the preferred display helping them to their purchasing decision. The multi-tiered pricing project was a resounding success, providing very solid data from users surveyed as to how this information should be presented.

So why all this work for one simple display of pricing? Simple! This is where sales are made. Pricing is displayed in the search results, in a bill of materials, on 3rd party websites, and most importantly, in the cart where the purchase is made. In the example above, if only 35% of users even understand what they will be charged for a purchase, how many of them will still want to go through with it? The power of the data collected in this project is enough to assure management that there will be a solid return on investment.

To solidify the reasoning for multi-tiered pricing, additional questions were asked:

Would seeing a price difference on the next highest quantity break lead you to increase your quantity for that part?

How important is it to know quantity breaks when buying components?

It seems that even though this type of pricing may not lead to more sales, in a competitive market where other companies are offering this service, users have grown to expect it.

This is an example of validating the need and usefulness of a value added service. View the risk management UX project post for an example of when to kill a project.

Going Mobile: Developing a Business Mobile Strategy

We live in a world where an online presence is quite simply a necessity for any business to succeed. As technology advances, and mobile usage increases, this online presence is not satisfactory if accessible only on the typical PC through a Web browser. Mobile access is becoming just as important as PC access was not long ago, before smartphones and tablets even existed. Moving your company forward into this new world can be an incredibly difficult decision, based on a wide array of technological choices that you may or may not have any experience with. To justify a decision to go mobile, how to go mobile, and how to ensure the ROI is sound, education in mobile technology is necessary.

This discussion attempts to break down the process of developing a mobile strategy into easy to digest topics, written so that the layman can feel they have a solid enough understanding to build a mobile strategy and present a well informed argument for their choices. Whether this mobile strategy is being created for the local dry cleaner or a Fortune 500 enterprise, the following information will provide a useful tool to for moving forward with your strategy.

The mobile Internet has the capability to release a significant amount of added value. As companies strive to capture this value, reach new customers, and retain their current customer base, it is important that a good mobile strategy is developed. Whether this strategy is as simple as creating a responsive web design provide a better experience for mobile browser users, or it requires a complex application be developed for each device type, many factors must be taken into consideration to assure the strategy is a successful one.

The explosion in smart mobile devices in increasing demand for mobile-enabled content and services. Building a mobile strategy can, and should be a complex process with analysis of many factors. Some of these factors have strong ties to the typical business decisions of the past, including time and cost concerns, as well as marketing and monetization of the product. In the realm of mobile applications, the infancy of the technology can provide a new set of considerations that many businesses have yet to experience. This can prove to be a dangerous prospect if not properly understood and analyzed prior to a decision on mobile strategy. Much more, a new breed of salesman, talking tech that is commonly misunderstood, and often overpriced, can easily sway an inexperienced decision maker into moving on a poor solution. I have experienced this first hand in a top Fortune 200 company, where a simple mobile solution, which would have taken an in-house team of three less than 2 months to produce, was outsourced to a mobile agency for over a quarter-million-dollar price-tag. Not surprisingly, this company was missing deadlines within the first month of development, and the in-house team was called on to assist in research and development of the product. Moreover, a more in-depth analysis of the company needs most likely would have found that this simple solution was not the proper path for a successful implementation of a new mobile presence.

Being that the topic of mobile application development is fairly new, and is also changing daily, in an attempt to put together a framework for building a mobile strategy, it is important that the majority of research done is recent. As sources are filtered through, any findings that deal with technology, statistics or processes that are quickly changing, sources older than 2010 will not be considered. For terminology or more consistent relevant factors, older sources may be considered, as well as sources used to provide a historical context.

Information from the Pew Research Center will provide a majority of the statistical data when analyzing mobile usage, as well as app usage within that segment. Their general nonpartisan stance and public opinion polling methods should provide a solid foundation of facts to build upon. Because of the wide variety of businesses that may need a mobile strategy, to include the largest segment, a strong understanding of usage must be provided in such a way that target markets can be compared against the statistical data. With this thorough analysis, business decision makers will have a better understanding of how to use this data to their own benefit.

Research conducted will cover a variety of topics to provide the best overview of the mobile app landscape. At the highest level, the research is used to build an understanding so that the decision of whether to create a mobile strategy for a web application, a native application, or a hybrid approach can be made. Based on this context, factors included in the research will include differences in user interface, user experience, development practices, time concerns, cost concerns, application delivery, application versioning, monetization, security and privacy, application capabilities, and future proofing.

Who Should Read This?

Everyone in a decision-making role in a business, whether small or large, can benefit from reading this paper. The shape of business is always changing, and the introduction of the mobile device, specifically smartphones and tablets, has introduced a very complex web of technological decisions for business owners as they move their online presence forward. No matter what their target market, a business owner can count on the fact that a large segment of that market is using mobile devices, and that usage includes browsing the Internet and using applications.

A recent study done by the Pew Research Center found that, on the eve of Apple’s unveiling of the iPhone 5, 45% of American adults, and 66% of Americans ages 18-29 now own smartphones (Anderson, 2012). Tablet usage is behind smartphones, but is also increasing at surprising rates; a clear sign of how far tablets have come is in another statistic: by 2013, the total number of tablets shipped – 100 million in just the U.S. – almost will be on par with the number of smartphones shipped this year, 108 million. These numbers also jump drastically as income levels rise, but whatever the numbers, it is a guarantee that the way in which people are getting their information is quickly changing. One can only guess how popular these devices will be in the future, but if companies like Microsoft are willing to jump into the hardware market to get a piece of the action, it is easy to conclude that we are still in the infancy of the mobile device era. A surprising show of the increase in not only who has these devices, but also how they are using them comes from eBay. Last year, eBay reported an increase in global mobile sales from $600 million in 2009 to $2 billion in 2010. Trends are up, expectations are up, demand is up, and so is pressure on companies to make sure they are positioned well for the future.

Is there currently a point of friction between your business model and your customers? When it comes to applications, this may be very difficult to recognize until you start building a mobile strategy, but because there are so many new technologies associated with this strategy, simply creating an easier path for your customer to their goal can uncover pain points that were previously unknown. A simple example of this can be found with how we used to find our way when driving. Many years ago, you would have to discover directions to your location, maybe even by calling the destination on a land-line phone and physically writing down these directions. Later, this pain point – which was unknown as a point of friction before – is eased by the Internet, and Google Maps, which could then quickly map out your directions both visually and textually, allowed you to print these directions and take them with you. No more calls, no more writing, no more hassles… or are there? Today, with smartphones, people have access to mapping utilities right in their pocket. A rendering problem aside, the new Apple Maps not only emulates a similar mapping feature as Google Maps, but also vocalizes turn-by-turn directions. Once again, a new pain point arises that maybe was not previously known (although GPS modules already have this feature). Mobile strategy development can recognize these, and provide a new path to success where none existed prior.

So what’s included here is a very wide overview of every consideration when delving into the process of creating your mobile business strategy. What’s not here is an in-depth jargon-filled tech paper that only the developers can understand. Upon finishing this paper, you should have a strong enough knowledge of the process to start building the team and relaying the project details. Leave the detailed jargon to the experts and keep your eye on vision and insight.

What Are the Considerations?

At the very least, a business creating a mobile strategy should address the following considerations, which I will analyze further below:

  • What mobile devices should we develop for?
  • What type of application should we build?
  • How do we approach the User Interface?
  • How do we approach the User Experience?
  • What do we need for development?
  • What capabilities does our application require?
  • What limitations are acceptable with out application?
  • What options does our application framework decision afford for monetization?
  • How do we get our application to our customers?
  • Can we support multiple versions and is this necessary?
  • What is our acceptable time-to-market?
  • What security concerns are there with our framework decision? With our business model?
  • Is this application future proof?

These 13 questions, if answered well with the business needs in mind, should provide a very transparent model for a mobile strategy.

Types of Mobile Devices

With the mention of mobile devices, I am generally referring to smartphones and tablets. Of course, within these two segments, there lies a wide variety of hardware, operating systems, screen resolutions, security features, processing power, etc. Perhaps the greatest differentiation between devices is what operating system they are running; some of these including Android, IOS, Windows Mobile and Symbian. The decision to create a mobile strategy for your business will require a lot of consideration simply around this divide, and how your solution will, or will not, address it. Mobile devices also come in a variety of screen resolutions. There would be no way to properly show the variances within this paper, but a truly overwhelming, and yet incomplete, list of these resolutions can be found on Wikipedia at the following link: This link also displays how wide the variety of devices can be, though it does include devices other than the ones in consideration with this paper.

Types of Mobile Applications

For the purpose of this study, three application types will be addressed, and considerations for device type in regards to these applications will also be included.

Mobile Web Application

The term “mobile web app” refers to an application that is viewed through a web browser. Generally a mobile web app is more limited than a native application, but when it comes to lower development cost and easier maintainability, it generally surpasses a native application. Of the three development decisions, mobile web applications are by far the easiest to implement. Depending on your business model, developing a mobile web app can be as simple as adding some media queries to your CSS stylesheet to display your current website differently based on screen resolution. Though this is quick, and very inexpensive, maintaining a strong user experience can be a challenge, one of the mobile web app’s biggest drawbacks.

Another complaint with the mobile web application is its reliability. Not only is this application type required to have an Internet connection, but also it is dependent on the service provider, the host, and the processing power of the servers, rather than on-board processing with a native app. Granted, mobile data access is quickly increasing with wireless hotspots and faster cellular data, however, any time data is moved from server to client and vice-versa, bandwidth limitations might require handling data-intensive calculations and processes within native applications. If the trend continues with increased bandwidth, this gap may soon be closed, bringing even more power to the mobile application solution. A quick way to estimate whether a mobile web app will server the needs of the business is to ask whether the browser on a desktop computer is enough, since they are essentially using the same technology. Access to a device’s native features, such as Bluetooth, cameras, accelerometers, GPS, and telephony may not be accessible.

Native Application

The term “native application” refers to software that is downloaded and run on the mobile device. This software has a benefit over a mobile web app in its full access to the native device features, as well utilizing the on-board processing. Native applications are often found in app stores, where they can be searched for and purchased or downloaded for free, which can also provide an added level of security, as well as user trust. Essentially, native applications are the Rolls Royce of mobile applications, but as with the car, they come at a high price.

Just considering development for the top three operating systems introduces three different programming languages; Objective-C for iOS (Apple), Java for Android, and C# for WP7 (Windows Phone 7), requiring native applications to be built one at a time. Development in this manner is one way to ensure idea correlation between hardware features, OS requirements and your application’s user interface, but increased development cost, longer time-to-market, and additional resources can be tough to swallow. The decision to go native can also segregate customers who are not using platforms that your mobile strategy has decided not to build for.

Hybrid Application

A hybrid application is a combination of web technology, such as HTML5 and JavaScript, and native functionality, essentially a combination of both mobile web application and native. Selecting a platform, or combination of platforms, clearly must be done with the full collaboration of your technical staff, which will be considering a number of factors. The “Write Once, Run Everywhere” mantra that comes with a hybrid application sounds very appealing, and is definitely the power behind hybrid app success, but there are some big differences with this and a native application that may prove incredibly important in your mobile strategy decision.

A hybrid application can get your brand name in front of the customer in a shorter amount of time, but if its performance doesn’t measure up to the user’s expectations it might do more harm to your brand than good. A big part of this missing expectation is with the user interface. When a customer is used to their Android device, which has a very recognizable UI, they will instantly be put off if your application appears and functions like an Apple device. This added cognitive load could be enough to send them packing.

User Interface Comparison

Each new platform poses unique restraints for User Interface designers and developers. Though this is generally not a big concern in mobile development overall, it does play a role. One of the initial concerns for UI should be the processing speed of the device. Depending on your application’s needs, the development of the UI may need to be adjusted to accommodate differences. There is also the possibility that users may move between different platforms while carrying out a single task, or many tasks. Imagine a banking user working from home to pay bills, and then needing to find an account balance later from their smartphone. What kind of expectations does this user have, knowing they are accessing the same account, and the same data, from the same company?

User Experience Comparison

The first decision that affects the mobile user experience is what technologies will be used to create the application, but what technologies are going to be used should be decided with creating a rich and satisfying user experience in mind. Because the same technology displayed on different devices will frequently render very differently, it is important to ask, what are the expectations of your users?

A recent study by PhoCusWright, Inc. showed that 37% of users experiencing a malfunction in a mobile application are very likely to leave the application and never return, with 25% of those reporting that they would have a more negative overall perception of the entire brand. This kind of data really drives the nail home when considering how much research should go into a mobile strategy. A study done by the Aberdeen Group found that businesses who have made the decision to put more resources into improving their application performance based on external factors, cited user demand as the number one factor, and customer complaints and expectations followed close behind.

Generally, user expectations are not met with a web application due to presentation as an app, but retaining the performance of the web. According to Daniel Na in “The what, why, and how of mobile applications. Connectivity and the User Experience.”, the use of standards-compliant web browsers provides a foundational functionality for both the users and developers of websites and web applications, which in turn provide a consistent user experience regardless of OS or device. This is true when simply looking at browser rendering, however, this does not take into account a web application which is built to emulate a native application, and only rings true for a responsive website type solution. If a responsive website is what you are going for, mobile devices are much more reliable and standards compliant that a PC.

One factor that directly affects overall user experience is application analytics. In a longer paper, this would definitely be broken out into its own section because of the insight it can provide to a business as they move forward with their mobile presence. Knowing how your application is performing is key to improving user experience, and organizations need to measure and monitor application performance to detect application problems before they become business problems.

Development Considerations

Before starting any mobile application development, it is essential to outline a mobile strategy to help define the application’s scope, usability, and schedule. One of the most important decisions in application development is whether to build a native application or a mobile web application. That is perhaps step 1 for the IT team, with a second question that follows if native app is selected as the choice; will this be truly native or a hybrid application? [For all applications,] programming complexity is inversely related to the platform’s access to device capabilities. In general, the same things that make a platform powerful will make it more complex to code. This complexity is multiplied for each platform if a decision to develop as a native application is made. Few businesses can afford to develop applications customized per device and OS; however, consumer demands expect that the application perform, look and feel as expected for their specific device. The right answer, every time, if you are building only for customer needs, is building native. Unfortunately, this can’t always be the only deciding factor.

The company that makes the native decision must be well aware that development for multiple devices inevitably means significant duplicated effort, as application code cannot be shared between them because of the differing languages. Apple’s iPhone and iPad devices use Objective-C, while Windows phones use .Net, and Android and BlackBerry each use very different flavors of Java. This can prove to be a very tough sell in an agile environment where reuse is the common theme, and can easily push the talks to discussing hybrid applications.

In implementing a hybrid solution, developers need to carefully select the user-preferred platforms and ensure that the choices reflect user desires and details that contribute to the total user experience, so that the correct development environment can be chosen. The possibilities of development environment seem endless for hybrid development, unlike native development, which usually is done in the specific device’s SDK (Software Development Kit). Application platforms for hybrid development have varying advantages and disadvantages. Titanium Developer can develop for iOS and Android, but Blackberry support is in beta, and other frameworks have not yet been added, though it eliminates the need to set up multiple IDEs (Integrated Development Environment). Rhommobile is an application platform that supports all the major device platforms, however it requires knowledge of Ruby, which your development team may not possess, as well as a monthly membership to use.

As new devices come online, with updated software and evolving mobile client requirements, maintaining your application is now your number one priority. This is a potential major cost, as well as a major requirement for man-hours. If your mobile strategy called for a native solution for each platform (supported), then your maintenance strategy will need to include the same. Hybrid HTML5 development can cut out wasted effort and build cross-platform apps, which work on all current mobile devices, and also require only maintaining one code base; definitely a big benefit to this decision, however; while they (hybrid applications) handle fairly simple types of apps easily, they can struggle when it comes to features that access a device’s native on-board functionality.

Application Capabilities and Limitations

Previously, the biggest drawback functionally with a hybrid application was its limitations when accessing device features. Because of growing support for HTML5, as well as extensions to the language, this is now a thing of the past. This leaves one of the only functional drawbacks to a hybrid application being performance speed, which still lags far behind that of a native application.

Application Monetization

The launch of the Apple App Store changed the way developers could profit from their applications, putting these programs directly in front of the users and collecting an immediate profit with a percentage well above the previous model. The importance of a seamless end-to-end user experience to increase usage and monetization became a core principle in the mobile apps space (Sharma, 2010). This was a native solution, and an early solution to application monetization. Since then, advertising has made the leap to mobile devices in similar ways it did previously with the Internet. The main forms of monetization for apps today are:

  1. Paid
  2. Advertising
  3. Virtual Goods
  4. Up-selling/cross-selling other goods
  5. Hybrid

The app store is the typical paid model, and as mentioned earlier, does not apply to the mobile web application. The next four forms of monetization have mainly come in response to the changing application market and different platforms. Platform differences can significantly impact monetization – built-in-billing & in-app commerce are key. Depending on the chosen mobile strategy for a company, the paths to monetization can be drastically different, as well as how one can collect from these methods. Once again, the Rolls Royce of applications, the native app, offers the most options, and the most startup cost.

Revenue from applications is going to depend on the future of the technology. There are three critical factors that will determine how revenues from mobile apps will play out in the future:

  1. Penetration of HTML5+ browsers on mobile
  2. Difference between the native OS support and browser access to the same API’s
  3. Implementation differences between various browsers

Surprisingly, even though the W3C (World Wide Web Consortium) does not suggest HTML5 will be an approved standard until 2023, the first factor mentioned above is already ringing true. Every smartphone shipped today comes with an on-board browser that is fully HTML5 capable, though there are differences in rendering. Perhaps the biggest deciding factor above is the access to API’s, which currently is only fully open to native applications.

Methods for App Delivery

This section follows app monetization because it can have direct ties, however, there are also some major considerations with delivery that affect user experience. A significant factor in the mobile technology “stack” – alongside devices, operating systems, OEMs and network operators – are the app stores. These app stores may most often be recognized as the main delivery method for an application; however, this is only true with native and hybrid applications. The understanding that accessing a website on a mobile device may actually be accessing an app, can escape the layman. There are also apps available all over the Internet that have not been introduced in an app store, or have been declined, and are now only available through other means, which most often include downloading directly from the manufacturer. As a consumer, these apps can pose a security risk in that there are no guarantees to their motives. Only organizations that have undergone a registration or vetting process get to distribute apps in an app store [which] ensures accountability and additional safety to the customer. For a business to decide on this method for their app delivery, they should also know that a question of risk could persuade a user to abandon thoughts of using a certain application.

Native applications and hybrid applications both can be found and downloaded through an app store. This searchability, as well as the channels for monetization, can be a big benefit to a company who has decided to go this route. This seeming ease of delivery, however, is not necessarily what the customer is looking for. This clutter on a device may be more than the customer is looking for. How important is it that a companies’ offering be available offline, and is this tool important enough that a customer wants access to it 24/7? A mobile web application can be accesses directly online and does not need to be downloaded, having a very lightweight footprint on the user. If this use case fits closer with the business model, then a web application, or perhaps a hybrid application is the right path.

Software Version Considerations

As with delivery for native applications, software version updates are delivered the same way and a good app store will notify users when new updates are available using a centralized mechanism. This is a very useful tool for versioning your software, and can help to quickly transfer users to the newest version. This is not, however, a guarantee that all users will be on the same version, and it is important for the user experience, that if you have a native or hybrid application, all versions are supported and work as expected.

Web applications are the winners in this realm. Just like a website, a user visits via a browser and they are served the latest version. No additional considerations need to be made, and no additional versions need to be supported.

Native Application Mobile Web Application
Downloaded onto a mobile device Accessed through a mobile device’s web browser
Installed and runs as a standalone application (no web browser needed) No need to install new software
Users must manually download and install app updates Updates are made to the web server without user intervention
There are stores and marketplaces to help users find your app Harder for users to find with no apps store
Hybrid applications can be deployed to the app store Hybrid applications can be deployed to the app store

 Time-to-market and Costs

Many mobile strategies call for the development to be outsourced, often because the company does not have developers as part of their business model. Although this can be a cost-saving and time efficient move, care must be taken to ensure that you’re not outsourcing your mobile strategy along with the development process. As much information as you provide to an outsourced developer, the understanding of the business model, company needs, and future planning, can only be truly known internally. Companies also need to be well aware, especially with native applications, that costs do not cease when the product is handed over. Maintenance and support costs can be highly unpredictable as new operating systems and devices are released. Many companies find themselves charged with unexpected and significant fees, even after a diligent effort to discover in advance all applicable usage fees, transaction fees, and additional development costs.

With native application development, building a single app is painstakingly slow, development cycles are long and the cost and the delay in time-to-market multiplies as each additional device and operating system is added to the launch. A mobile strategy that opts for this path may decide to build for one platform at a time. Often we hear of a new application hitting the market with the caveat, only for iOS, or only for Android, followed by the typical “coming soon” message for other platforms. This is exactly what happened last week with the company Jawbone and their release of the new Up, a fitness wrist band. All of the iOS devices are supported with their application, and down in the FAQ of the website, the line reads, “An Android app is coming soon”. Is this an acceptable answer for all of the users looking to get this new product, but lack the necessary iDevice? It must be a difficult decision to decide between an earlier product launch that segregates your customer base, and a later launch that may not beat the competition to market.

Due to the complexity in planning a mobile application, there is no possible way to suggest what something would cost without knowing exactly what it is, but only provide an estimate. Application costs involve many factors including visual design, functional design, development, testing, deployment, marketing, maintenance etcetera.  Dr. Tim King, CTO of 5app breaks down application estimates into 4 categories, based on app size and function: Simple, Data List, Complex, and Enterprise. The following table illustrates just how wide this cost variance can be:

Even with this table, Dr. King goes on to say “It’s safe to assume that using traditional development techniques to create a simple single-platform app will cost around £10K and a cross-platform enterprise app won’t come in under £100K.”

Security & Privacy Considerations

Many organizations bring security to the forefront of web application design only when an incident occurs. The result is generally an expensive, knee-jerk, reaction to security problems that might have been avoided with intelligently planned controls. With the growing concerns over mobile security, this is a very flawed policy. Mobile phones are unique from desktop and laptop PC’s in that they feature always-on connectivity and cloud synchronization, which can increase the threat to mobile data. Mobile threats vary in scope and severity, including malicious applications, botnets, spyware, and phishing. Most of these terms have become household names, but few realize that their mobile devices are also susceptible to attack. Depending on the application function, whether it is simply presenting information, making mobile payments, or transmitting confidential data, the choice of which application framework to use can make a huge difference in measures needed for protection.

Organizations often do not protect their applications because they do not fully understand how popular security controls, such as firewalls and vulnerability scanning, relate to the application layer. This often is a direct result of the “need for speed” aspect of trying to get time-to-market down, rushing to a decision and passing it down to the development team. Making sure that development team has a trained security expert can save the aforementioned knee-jerk solution. This is the security plan in place for my personal blog, which has nothing important… at all… that I need to protect, but when I was running an e-commerce website with millions of customer records, security was always a top concern. Most companies recognize this from the standpoint of the website, but fail to understand that simply extending this to a web application or native application adds additional security concerns. Remember, building security into the development may generate some additional initial costs, but hiring a “cleaner” who has no intimate knowledge with your code-base will always end up costing more, both financially, and with your users trust.

Every day we hear news of websites being hacked and user data being stolen. These are not small websites like my insignificant blog, but large companies and government organizations like Yahoo, Facebook, and the FTC, and in fact, a survey done by Computer World shows that 90% of companies say they’ve been hacked. This type of statistic seems to present the certainty that your website will be hacked, but it doesn’t seem that we hear the same news about mobile devices and applications. Researchers suggest, however, that with the increased processing power and memory, increased data transmission capabilities of the mobile phone networks, and with open and third party extensible operating systems, phones [and tablets] become an interesting target for hackers. It would seem then, that the threat of hacks that has been expected and not materialized, is still expected and most likely imminent.

Prepare for the Future

Companies, due to the rigidity of their internal structures and culture, often have great difficulty in keeping up with technology. Users, on the other hand do not, and quickly pick up the latest devices, still expecting a perfect experience. But is this the future that needs to be planned for, or is there something else that needs to be addressed? Futurist John Smart, founder of the Acceleration Studies Foundation, looks beyond 2020 and sees apps as merely a passing phase in Internet evolution. “Apps are a great intermediate play, a way to scale up functionality of a primitive Web,” he said, “but over time they get out-competed for all but the most complex platforms by simpler and more standardized alternatives. What will get complex will be the ‘artificial immune systems’ on local machines. What will get increasingly transparent and standardized will be the limited number of open Web platforms and protocols that all the leading desktop and mobile hardware and their immune systems will agree to use. The rest of the apps and their code will reside in the long tail of vertical and niche uses”.

But who is planning on next going to market in 2020? Business is today, and a plan needs to be made for today and the next few years at least. There is a huge unknown that can only be speculation at this point when it comes to the future of mobile applications, but for today, software makers must balance the Web-vs.-native debate based on an application’s primary objectives, development and business realities, and the opportunities the Web will provide in the not-so-distant future. Oh, by the way, did anyone mention app-enabled televisions?


There are way too many things to consider to jump blindly into creating a mobile strategy. Each of the topics that I reviewed for this paper could fill an entire book, and probably already do. I’m simply trying to combine all of these questions together to see if an overall pattern emerges that can help solve some of the toughest questions, or at least provide an educated starting point to conduct further research.

There seem to be some simple decisions where business needs are so completely obvious that only one solution is relevant. Take the case of highly interactive game companies. As of now, there is no possible way a mobile web app, or even a hybrid app, could match the power of a native application for graphics rendering. EA Games has many titles where I’m sure nobody in the boardroom suggested a web app could be the best route to take for development. It is also easy to imagine a one page website with instructions on how to bake sweet potatoes would probably not need to spend thousands of dollars on a native application solution.

I have recently noticed a trend within larger companies who offer multiple mobile solutions, which include web applications and native or hybrid applications, often with a different solution for different divisions of the company. This makes me think of the “siloing” aspect with enterprise architecture studies and I wonder how these companies are organizing their data for so many points of contact, but that would be another paper. An example I found of this recently was Showtime. They have a very useful mobile web application if looking for high-level information, but they also have options to download full-blown applications to really utilize the media they provide. I was impressed with the distinction they made between these different options and felt I understood the reasoning. Another company, who is moving in this same direction, with less success in my opinion, is Comcast. I recently tried to download an application to view my onDemand content from Comcast and found multiple applications in the app store, with very little information on what each one did. I ended up downloading three of these, all with incredibly similar names: XfinityConnect, Xfinity Player, and Xfinity TV. After opening each one, I’m still not entirely sure why I have three, or which one I use for watching live TV, managing my account, watching onDemand content, or watching premium channels, if I even can. These two cases seem to have many similarities with very different user experiences attached, reflecting the importance of a well thought out mobile solution.

I have watched companies struggle to make a mobile strategy decision, as well as companies struggle to recover from poor mobile decisions. It is an incredibly complex decision, as most business decisions are, but because of the infancy of the industry, few possess the knowledge to intelligently make this kind of decision alone. A close, high-level, look at each of the aforementioned categories can provide either: A. Knowledge enough to make an informed decision, or B. Knowledge enough to find the right person to make the decision. I have met very few people who had a good understanding of each aspect of the SDLC (Software Development Life Cycle), let alone thorough knowledge of advertising, marketing, IT security, graphic design, or a slew of other relevant fields in mobile strategy development. Perhaps this paper can provide a good starting point for recognizing weak areas so that further research can be done? In fact, my conclusion after writing this is that I have realized just how much valuable information is out there, and I need to do further research on my weak areas, which consists of just about the whole shebang.

Technology for hybrid application development has come a long way in a short amount of time, and continues to quickly progress. The ability now to access nearly every native feature of a mobile device does wonders for the scalability of this kind of solution. That combined with the lower cost of development and maintenance makes for a nearly perfect mobile solution. Though this technology cannot perfectly replace a native application, the features, user experience, low cost, readily available tools, developer network etc. make for a foundation that should satisfy 90% of business needs. The new decisions moving forward will be what flavor of hybrid application do we develop?


Users have their expectations, and those are going to be based on what you, as a business, have presented to them. One important thing to keep in mind as you build your mobile strategy is to keep your own expectations realistic. The power of mobile technology, and the extremely persuasive “cool factor” of getting involved in this, can quickly turn a simple strategy into a complete refactoring of the business model. Before any decisions are made, it is necessary that a business begin with the use case. What requirements are necessary to assure a quality user experience? When a thorough use case has been developed, a business will have the tools it needs in hand to move forward with the framework decision. The table below shows the considerations for a mobile strategy, and the effort required to address each one.

Mobile Web Native Hybrid
Cost of development
Time to market
Dynamic content
Cross platform
Use existing development tools
Use existing hosting
Controlled user experience
Use native UI
Monetization infrastructure
Easily upgradable
Requires internet connection
Speed and latency
Easy Questionable Difficult


There are standards already in place for application security, so reinventing the wheel is not necessary. It only takes a decision to be proactive, rather than reactive when putting together a mobile strategy. Security can easily become a make-or-break piece of your brand if not properly handled. At the very least, performing a vulnerability assessment prior to development should be mandatory. An organization that has never done [this], is likely to immediately and significantly reduce its risk exposure by taking that first step. For businesses that feel lost on where to begin, a good place to start is to contact the OWASP (Open Web Application Security Project), whose mission is to make software security visible, so that individuals and organizations worldwide can make informed decisions about true software security risks.

Making sure security measures are in place is a great decision, but how does this work? Security cannot be planned until it is understood what needs to be secured. Does the application have access to financial information? Does the application store information, and if so, where does it store this information? What services is the application making connections to, and what is its vulnerability while it is connected? The well thought out mobile strategy should easily answer these and more questions.

When making the decision of what application type to target, it really depends on the use case. If it’s something that doesn’t really need super high performance or native feature support at a very high level mobile web is the way to go. If not, then native applications are worth looking at. That being said, many people might not want to litter their smartphones with a bunch of native applications so taking a hybrid approach where your application is available via the browser or the app store is worth looking at.

Because the majority of cost comes with the development, I have put together a few tables to get an idea of development requirements throughout the SDLC, and how different mobile decisions affect these requirements. Hopefully this provides another useful tool in making the mobile strategy. To understand the following tables, a score of 1 out of 5 requires the smallest time cost, while 5 out of 5 requires the most.

Quality Assurance

QA Effort Web Application Hybrid Application Native Application Notes
Test Devices Y Y Y Devices with OS variations
Test Setup 2 out of 5 2 out of 5 5 out of 5 Native requires special deployment
Functional Test Effort 2 out of 5 4 out of 5 5 out of 5 HTML5 requires the same level of UI testing as native
Security test effort 3 out of 5 4 out of 5 2 out of 5 JavaScript code are more exposed in HTML5
Performance test effort 2 out of 5 4 out of 5 5 out of 5 Requires a device lab infrastructure


Software Configuration Management

SCM Effort Web Application Hybrid Application Native Application Notes
Dev Devices Y Y Y Devices with OS variations
Dev Tools N Y Y HTML5 requires device specific dev environment
Code Configuration 2 out of 5 2 out of 5 5 out of 5 Native requires special configuration
Build 1 out of 5 2 out of 5 5 out of 5 HTML5 requires new web services and end points
Code Deployment 1 out of 5 2 out of 5 5 out of 5 JavaScript code are more exposed in HTML5



Infrastructure effort Web Application Hybrid Application Native Application Notes
Test Devices Y Y Y Devices with OS variations
New Runtime N Maybe Y HTML5 may require new web services and endpoints
New Firewall Policies Y Y Y
New DNS Maybe Y Y



Operation Effort Web Application Hybrid Application Native Application Notes
Devices Y Y Y Devices with OS variations
Support Effort 2 out of 5 5 out of 5 5 out of 5 HTML5 and native has similar UX
Deployment Effort 2 out of 5 3 out of 5 5 out of 5


The Application Decision

By shifting the mobile paradigm to focus on the creation of robust, cross-platform web applications in place of native applications specific to each OS, businesses will save on development costs while reaching a wider customer base than ever before. These mobile web apps are incredibly powerful, and scalable, and easy to implement. Not only that, but because of their quick implementation and low cost, they are also much easier to get approval on. This may push some business decision makers in this direction, but very often this ends up being a mistake. If your whole online business model is built around a website that simply provides information, this could be a great solution. Any time additional requirements come into play, the added complexity can quickly become more than the web application can handle while still appeasing the users.

Lean UX and The Enterprise Architecture – Part I

Spectrum of User Experience

Unlike the Graphical User Interface (GUI), which only connected marketing, technology, and the user through a façade, User Experience (UX) in the enterprise incorporates the way people perceive a design, use the product, and how they make decisions. In fact, UX is a very broad term that encompasses many smaller categories, all with the goal of creating a better product, whereas GUI is laser focused on the graphical presentation of a product.

From my early time at NCM, I had seen my own UX title represented many different ways, from architect, to designer, to developer. I had yet to see researcher, but this would also fit just fine. These title changes are due to a combination of factors. First, the general infancy of the term User Experience brings with it a lack of understanding around what it means. For some, it is simply the User Interface (UI) design, or what most closely relates to the deprecated GUI role. For others, the UX role is a developer that builds the UI graphically, as well as in code functioning as a prototype, or leaving it ready to accept the logic piece. This leads to the second reason, and that is that UX really does have multiple titles within the main UX category. Many companies will separate research from design, development, testing etc. The below image is an example of all the areas within a business, shown with UX at the center. This, however, does not break out UX into its different areas of focus, which are then seen on the outside as sub-containers.

Spectrum of User Experience
Based on design by Information Architects, Inc.

With the UX role built into the process at NCM as a floating specialist, my concern is that the role is being utilized on an “as seen fit” basis. This could result in the aforementioned siloed view of the role, circumventing the deep knowledge of a project required to properly implement UX in its most cohesive form. Instead of “as seen fit”, UX should be looked at through the idea “how does it fit” throughout the software development life cycle (SDLC). Any fragmentation of knowledge leads to miscommunication and ineffective design.

I should also note that not only is the “as seen fit” implementation apt to be siloed, to this point the floating specialist (me) has been utilized more as a UI role called upon when needed, with that need being identified through the stakeholder request of a new UI integration or change. Much of the time, these new feature or change requests are only being initiated because of underlying bad UX and should be looked at from the root of the problem in a proactive manner, rather than the more common reactive response.

UX professionals listen intently to stakeholders and users. Being involved in the early design sessions through to the launch of a product and beyond allows for the frequent collection of team-wide feedback and will minimize waste. Placing a UX iteration step into each business cell will lend itself to building a true lean UX process into the SDLC.

The deliverables from the UX practice must be constantly integrated into the lean process to assure the least amount of waste — work ultimately forgotten or not used in development of the product. That being said, lean is light and fast, so emphasis on deliverables should be lessened in lieu of actual experience design. In short development cycles this isn’t even an option. Achieving this shift from deliverable -> experience design is heavily weighted on the UX factor being truly collaborative during every cycle of the SDLC. Deliverables are not worked on and completed, but rather iterated on throughout.

Lean UX Process as created by @jboogie
Lean UX Process as created by @jboogie

The question becomes, where, and more importantly, how does this all fit in to the rest of the process? The first step is to make sure that UX is heavily involved in the design phase of development. This focus on earlier insights ensures that UX is aligned with the business vision, provides direction to developers prior to their work beginning, and flushes out creative thinking through increased collaboration.

My job is as much to create the experience as it is to organize and analyze the feedback that manifests through this collaboration, which in turn feeds the experience. Integration throughout the entire design process will result in an experience design that is infinitely greater than work I would create if involvement were minimal or “as seen fit”. As the sole UX expert in the Enterprise Information Systems department, my job is to use an entire toolkit of sketching, presenting, critiquing, researching, testing, prototyping and wireframing as they are appropriate for each development cycle, and for each problem that needs solving.

In order to cover all these bases, I cannot be in a cell myself; however, my particular “jobs” can be incorporated into cells. If the above iteration diagram were my products, how would each of these fit into the product families for each of the cells being created? That is what I’m hoping to solve and embed into our new lean environment.  I’m hoping this blog can serve as a launching point for my research into how this can be done. Based on our current process, I intend to move forward by looking at each deliverable above: concept, prototype, validate, test, analyze & research, and iterate, and make a game plan for assuring UX and the lean work cell are one highly functional factory of awesomeness!