Process

Every application begins with an idea. These ideas, when executed correctly, provide value to your customers. To get there, you must first ask key questions:

• What is the problem I am trying to solve?
• What is already in the market place?
• Who are my users?
• What do the users want?
• How will this be used?
• How will we be building it?
• Are there ideas which might make this better?

What is the problem I am trying to solve?

The solution we are trying to reach is based on a problem that needs to be addressed. This problem can be anything from “we need a way to provide a service to our users” to "our users are unable to effectively perform a task with an existing solution”. Figuring out how you will accomplish this goal will require meeting with stakeholders, subject matter experts (SMEs), developers, systems architects, users and testers in order to identify and properly define the problem we are trying to solve.

Through interviews of these key players, we are able to move an idea from a discussion, to a whiteboard, off to a wireframe prototype and then development and deployment into the market place. Without such efforts, solutions breakdown and easily foreseeable problems block deployment of a quality product.

What is already in the market place?

Not every idea is new, and even new ideas are influenced by the things that came before them. It is easy to charge into design and development of an idea with the confidence that you will solve the challenges and meet expectations. Chances are that what you are working on has been, in some part, already accomplished in other products and services provided by other companies. Studying these already available solutions may help you identify ideas that you might not have already considered, and let you learn from the mistakes of others.

A competitive analysis of products by feature and usability will only help make your solution better suited to your user’s needs.

Who are my users?

Delivering a product that doesn’t consider who your user is and what they are expected or trying to accomplish with your product, will result in a substandard experience. In order to effectively create a good experience, we must consider:

• What roles will my users have related to this solution?
• What is their journey through the solution?
• How often will they use this solution?
• What will be the learning curve for new users?
• Are there ethnographic or gender variables that I need to consider?
• What challenges do they currently face with existing solutions?

What do the users want?

Often, in the rush to deliver a new product or solve an existing problem, companies move into development without input from the users. With this mistake, they miss an opportunity to gauge the user’s needs directly by simply asking them. Finding the answer to this is as easy as a survey and as complex as a deep-dive application test with users to identify issues that can cause an idea to go off rails and the resulting solution to be sub-optimal.

Research will answer these questions.

How will this be used?

More than what problem the solution solves, is how and where this solution will be used. Will it be in an office? Is my user in a hazardous environment and needs information succinctly and quickly? Will it be deployed on a smartphone? What other factors in my user’s world will influence the success of my solution?

I once worked on a project where the mandate was to deploy “the first touch screen application” to a ruggedized industry. User research and testing throughout the design and development sought to make this application usable and intuitive, but when deployment to the field came, a huge problem emerged. Nobody ever considered that users would be wearing heavy gloves the whole time.

Luckily, I was able to drive to a nearby city, find a Fry’s Electronics and buy some Haptic thread. I spent the weekend sewing touch points into a glove and testing them on an iPad and then passed the idea off to their engineering team.

Problems like these are easily avoided if one takes in not just the solution but “the how and where.”

How will this be built?

Often, in the rush to deliver a new product or solve an existing problem, companies move into development without input from the users. With this mistake, they miss an opportunity to gauge the user’s needs directly by simply asking them. Finding the answer to this is as easy as a survey and as complex as a deep-dive application test with users to identify issues that can cause an idea to go off rails and the resulting solution to be sub-optimal.

We accomplish this through Research.

Protoypes

It is really difficult to get the same level of information from a series of flat screens that you can get from a semi functional prototype example. These examples can help show developers the desired interaction states or sequence of events. They can bring to life vague ideas and help test them before actual coding takes place. It is through prototyping that we bridge the gap between concept and implementation.

A good prototype serves as a living document, a test bed of ideas and a set of instructions on how to build the application as it was designed.

I have worked in nearly every available prototyping tool. Axure, Expression Blend/SketchFlow, SketchApp, Basalmiq, Framer, Figma, XD, Invision, and Principle.

Prototype Examples

• Edison IOS Version
• Edison Android Version
• Edison Interactive Workflow Diagrams
• DIGITS Consumer - (Test Model That Helped lead to Edison)
• Halliburton Knoesis - WPF Sketchflow Application (Coming Soon)
• Halliburton Interactive Styleguide (Coming Soon)