Product Validation.

The process of building a minimum viable product is an exciting journey that culminates a variety of business initiatives into one cohesive path. A minimum viable product serves as a proof-of-concept build to demonstrate the primary functionality of your mobile application. The focus of the build allows users an opportunity to experience the key features of your application and provide a feedback loop into effecting the product’s evolution in a direct way. The idea of building, measuring, and learning over time helps define a path for great products to develop. The goal of shipping software early is to increase knowledge over time. This approach to user-centered design is beneficial to individuals building their first application, as well as corporate entities looking for ways to quickly ideate new product ideas. The first step when beginning to think about your proof of concept build is to validate your idea as something uniquely valued by your users. I often hear ideas for applications that already exist in the marketplace, or are so similar to other applications it wouldn’t make sense to replicate. 

It is important when considering the functionalities for your application that you take a unique approach to serving your users.

I find with new product ideas they can overlook aspects that makes the difference between marketplace viability. Before a proof-of-concept build is considered it is important that as much work has been done to validate its place in the market for the users you are serving. An early and strong relationship between users and how they affect your product helps ensure a progressive path for the product’s evolution. 

The start of any great idea has been molded and shaped by the environment around it to be as unique as possible in it’s approach. For mobile applications this is having distinct differences for how you approach your product versus the competition. Once there is a clear path for your innovative idea to take shape achieving it becomes much easier.

On most projects I usually start with brainstorming and competitive or comparative analysis. Creating a moodboard of interface patterns, branding elements, and colors help define a palette to drive design thinking. This helps clients and I to think similarly about how to approach the design, while providing visual examples to solutions that may work. I base most design decisions from quantitative or qualitative data, and develop personas to guide user experience. The goal of utilizing competitive or comparative data is to base your design decisions from, and to begin to define the reasons behind why certain patterns fit. It also gives insight into the competitive landscape and how best to position your product for success. 

Validated? Great, Let’s Work!

Once the key concept behind your idea is refined you can start to work on the functionality of your application. I find it helpful to work from a development backlog to map designs with user stories once key functionality has been defined. A development backlog should include the full scope of functionality for your application, which is often trimmed down or reprioritized based on the scope of the MVP. The backlog begins by defining the goal for your app. You then define roles and personas for your user group, in addition to non-functional requirements. When it comes to defining functional requirements it helps to create epics for your users stories, then writing them individually. 

This approach helps define development and design tasks simultaneously with product decisions. User stories capture and refine product decisions, and once those are completed the task of designing page flows and interactions becomes drastically easier. I rely upon a backlog as a foundational element for organized product design. 

The design process can begin at various stages, but from experience I have found it best to start design after a backlog has been completed with approval from the product owner. Once a general pass for layout and interactions is completed, more detail can be applied to individual screens. I consider my process for wireframing functional, meaning the elements are built using vector shapes, but for ideating colors and layer effects are omitted. This helps work out the specifications of design elements in perfect pixel form, so that once they are approved applying final visual design is a straightforward process. 

Refine and Condense.

Now that a development backlog is populated and the designs are close to complete an estimation can occur to define duration and cost. The estimation process is a highly important one. Without the right direction I have heard of many clients being led down various paths that are costly and don’t result in providing you with a functioning app. It is also important to consider the integrity of the code that is provided, since in many cases I have found rebuilding rather than refactoring code is the best option. When user stories are completed a group of developers and non-developers would then go through each individual use case and estimate the complexity on a point scale. A low point relates to a relatively easy task, where a higher point accounts for more complexity. At the end of the estimation the total story points are combined and a timeline is defined using an assumed velocity. When defining velocity keep in mind more developers can't necessarily build something faster, it is important to have the right amount of resources dedicated to fulfill the need. 

My goal is to define information architecture and perfomance correctly from the start, with room to scale or refine within the code base as needed. 

I find the estimation piece as the most complex throughout the process. As a designer I am confident with the work I can produce, however in building digital products there are so many aspects that can potentially go beyond scope in an agile setting. The product owner should be a single person defining the decisions that impact the build for each week, helping to keep the build on track. Agile software development traditionally takes a two-week cycle to build feature sets and move onto another sprint. I’ve found in proof-of-concept builds that having shorter week-long sprints helps manage all aspects more directly, and results in less potential issues arising towards release. It helps pace the design and development sprints in more manageable chunks so that you quickly see where issues arise and solve them before they get your timeline too far off scope. 

Execute.

Using an agile project management tool such as Pivotal helps organize your sprints on a weekly basis based on prioritization from the product owner. Given the velocity (amount of work that can be completed given resources over time) a weekly basis for points is established and the product owner is free to add or re-prioritize stories accordingly. Agile sprint cycles culminates with testing features that have been implemented to ensure working functionality. Once the designs are implemented it is necessary to take a pass at the layout to ensure development and design aspects match. There are tools that automate this process directly from your designs, which I find extremely useful in my own work. It helps to remove any doubt and in situations when you are dealing with off-shore teams, while helping to bridge cultural and linguistic gaps. This is why I am a huge fan of crafting pixel-perfect products. 

Designs that are not implemented correctly are considered bugs in the system, and sent back for a second pass to ensure the quality is the same as the design. Any bugs that are found from functionality to design errors are tracked and corrected during the QA process. In the end you should have a seamless journey from ideation towards execution.