Expectations of the Proof of Concept
Patrick is a technical specialist who has been creating architectures and software implementations for over two decades. His clients have been mainly Fortune 500 companies including Financal, Insurance, Entertainment, and Consumer Electronics. Patrick is passionate about keeping current with the latest trends in mobility and the technology landscape. No stranger to hands-on mobile development, he has produced several apps ranging from Enterprise business to children’s games. Patrick can be reached at firstname.lastname@example.org or on twitter at @pxtrick.
Expectations of the Proof of Concept
New App Excitement
The most exciting part of a new project is the early stages when requirements are still being gathered and the full scope has yet to be determined. This is especially true when starting a new mobile application within an Enterprise company where mobility might be a brand new endeavor. Everyone on the project certainly knows how to use mobile devices in their personal lives, but many probably have no experience working on and completing a mobile project. Although the experienced business analyst has tremendous domain knowledge with the current products, it doesn’t necessarily mean they fully understand how their business will translate in this new mobile direction.
Warm Up Before Sprinting
Before the formal development sprints begin, it is good practice to schedule in time for a proof-of-concept (POC) version of the app to prove out basic technical functionality. This is also a good point to test out any custom UI features the designers have introduced. If the mobile app is being developed as only one part of a bigger, brand new business application, there may be many connection points and interactions that are critical show-stoppers if not working correctly. Introducing a POC should be considered a part of risk management.
That Thing is Ugly
If and when the business folks get to see the development team’s POC, the initial reaction may be of surprise at how it doesn’t look anything like it should and the behavior is only a fraction of what it should do. And like first impressions in general, the displeasure of this shock may linger long into the app development cycle. So it’s good to set expectations about what the POC might look like and how it will perform in order to keep as much of a positive outlook as possible. At this point, it should be made clear that the POC is not the same as the prototype and until the project has reached the prototype stage, any semblance to the final product is merely coincidental.
Show Me the Proof
There are some areas of the app that are more likely to need proving out than others, but in general, the following are good candidates for the POC:
- Brand New APIs or Backend Services
If the app is connecting to WebService APIs or endpoints that are new for the project, there is almost a guarantee to be friction in getting these working correctly. So the goal of the POC should be to prove that the APIs are alive and honoring their published contracts for both input and output data. An area that easily gets overlooked is how the Services handle failures and whether the client app can provide robust error handling for the information given back. It’s possible to have faith in the services and put off validation until later in the project, but this introduces tremendous risk for mid-development delays.
Security is a critical feature that nearly every Enterprise app will need to include. But the performance implications of your security solutions must be fully understood. If the app is taking advantage of SSO for login, the UX associated with your implementation needs to be demonstrated on device to observe and measure its behavior. For example, the default behavior of some SSO solutions is to launch a new application to capture and verify user credentials before then returning back to the original application. How this app-swapping looks and behaves must be observed in case it is unacceptable from a UX perspective. An additional consideration is data security, providing on-app data encryption is often a requirement for compliance with privacy regulations like HIPAA and PCI. Simply coding a generic solution for encryption may not be good enough security; the access performance and opacity of data needs to be thoroughly tested and proven out.
- Custom Controls
Today’s mobile app designers push the boundaries of UI and UX in order to give their users a new and unique experience. Sometimes this involves inventing UI elements that cannot be implemented with native controls. Although this is a respectable approach to designing apps, care must be taken to make sure the development team can actually create these controls on the platform they’ve chosen for this mobile app. A POC is useful for immediately exposing difficulties that will arise during development with things like animations and competing touch events. A great example is using parallax scrolling on a screen during a swipe or drag gesture. Depending on the complexity of the design, parallax may be difficult to get working smoothly. UX is a huge issue here as well because even though custom controls may look awesome on the design mockups, they may prove unpleasant to actually interact with on the final app.
When a business has decided to begin development on a new mobile app, delivering the solution as quickly as possible is always a top priority. A common side effect of this urgency is to not plan for a POC. Although sometimes skipping the POC is ok, failing to recognize high risk points in the app may mean magnified schedule problems later. It is in everyone’s best interest to find out early on where the pain points may lie instead of derailing development progress after discovering critical functionality or design cannot be implemented. If time to market is truly critical, it is in the best interest of your success to plan for a POC iteration.