Thoughts on Process

There is substantial value in identifying and establishing methods for getting quality work done in a timely manner. However, it's important to not let these methods stifle creativity and innovation. I wanted to briefly share some thoughts and process and how I might define the various aspects of a typical process.

The process de-synthesized below is followed for the most part as I work on various projects, teams and products. However, every product or design problem is different. Teams that might be part of the process could be distributed across many offices in many timezones, or at the same office available at all times. Most often timelines are tightly constrained with strict requirements. This can limit the time or thoroughness that be given to each aspect of the process. Occasionally timelines are looser, with more freedom which allows for a more comprehensive approach to solving the problem. It goes without saying that feedback is valuable at every step of this process. Appropriate feedback insures that the right problems are being solved and provides confidence that the solution addresses the concerns of the stakeholders and clients. Regardless of what or how many aspects of this methodology is utilized, again, it's important that the process itself doesn't get in the way of creativity and productivity.

Ideas can take the form of whiteboard sketches, giant post-it pad planning, drawing with a stylus on an iPad or in a notebook the moment a relevant idea occurs. It is very important to not limit direction and avoid placing strict constraints on the creative process. This could be one of the most crucial phases of a design process. If only a limited about of ideation is done, the possible solutions are also limited. Limited directions could mean the creative process matures and develops to far in a single direction that doesn't actually fully address the problem. Design thinking promotes a valuable principle:

"Fail Early, Fail Fast, Fail Often",
"The key understanding in adapting a design process to an iterative one is that failure must be expected and embraced. This process also creates opportunity to remedy those failures early on -- and more efficiently."
"...Fail Early, Fail Fast, Fail Often" - Fast Company

Its important to leverage the ideation phase for discovering alternatives, possibilities and choices. The ideas harvested should help define the problems that are to be solved and develop the questions that need to be answered.

Concept Models work extremely well to discover all the individual connecting parts of a system or interconnectivity between various apps that are intended to work together. One method of conducting this exercise is to get the known the components down then link them together with verb statements.

Admin User modifies Access to Products & Services within Wholesale Accounts
or
Hiring Managers ask for Feedback from Employees
and
Hiring Managers create Job Post for Positions and
Candidates provide Resume to apply for Positions

Representing these components and the connections between them in a visual way can provide some perspective that could enable sensible grouping of similar tasks or areas of a system.

Flows

Creating use case or feature flows can surface potential risks or unsustainable decisions in a way that wires or a stack of business requirements cannot. A low level flow can be very valuable at illustrating and providing information for engineers regarding security and users permissions in a user's task. Styles can vary greatly when it comes to presenting a particular flows nuances. Using some of the Jesse James Garret like box shapes can provide details about the business rules and logic of flow. However, designers may want to use a more "natural language" flow presentation in order to communicate to stake holders or a less technical audience.

A way to make the concepts tangible is developing "wireframes". These wires are the armature, the scaffolding that will support the concepts derived in the previous phase. Wireframes can range from very informal and displaying high level information to very informative, tight representations of the concepts sketched out. In order to obtain the appropriate feedback it is important to only include relevant information. That is why most wireframes are grayscale, providing hierarchy but not soliciting early feedback regarding color palettes and final UI.

Patterns

Creating patterns is an interesting process in itself. If a team is building a unique and individualized experience for a single app or product, it makes sense to determine a direction, solution and voice for that particular product. However, if a team is building a suite of apps or a system of products that will work in concert with one another, it is smart to put as much effort that can be afforded into a pattern library. A pattern library can be defined as:

a resource of various layouts, components and elements that use the same visual language and follow a set of common principles.

This resource provides definitions as to what a particular layout, component or element is and guidelines for where and when these components should be used, as well as, how they can be implemented. In the best scenario the catalogue presents a holistic understanding of all the elements from a very high level, but also provides low level details for the specific elements, if that is what is needed.

Patterns can be discovered through a "Top-Down" or "Bottom-Up" approach. These methods could also be called, Manufactured or Organic.

The "Top-Down" or Manufactured method
A team will look at many real use cases and scenarios and determine some common guiding principles, interactions and visual treatments that as many possible use cases can share. This can mean that a team will expend some upfront effort discovering, defining and documenting the patterns that are found. Typically this method will be most appropriate for a system redesign process or new product design process where there are multiple products being designed at the same time.

The "Bottom-Up" or Organic method
An organic approach requires less of an upfront effort to discover reusable patterns. Using a much less documented set of standards to inform the design of one product or small feature enhancement to an existing product. The team attempts to bring clarity and uniformity to the various individual projects that are going on. Where over time, products are starting to look and behave in the same manner. They are starting to speak the same language. It is an ongoing and much more fluid process. I would argue that this method, although nimble can present some difficulties. It can appear that not very much is changing because the changes are occurring in smaller instances. If a team is poor in documenting the concepts or visual language being used to design their enhancements and projects it can feel like extra effort is being spent on modifying the one project so as to harmonize it with the endeavors of other teams. There is an innate lack of perspective with this method by design. This is what makes it somewhat faster when it comes to the individual projects and efforts but slower when it comes to producing multiple products that appear and interact the same way.

Obviously a team can potentially use both of these methods together. The ultimate goal of creating a pattern library is to develop a common set of principles and guidelines that will enable faster design and development while working more efficiently by not having to start from scratch with every new project or enhancement.

One by-product of using these methods could be a GUI Kit that can be used by designers or product managers to create consistent mockups for developers. Another potential and possibly more valuable by-product is a code repository of the html semantic, styles and scripts required to implement the patterns that have been designed. By having a GUI Kit that matches the code that will be implemented both conceptually and practically many barriers are removed and the less time it will take to get from concept to code, making it possible to act nimble and respond much quicker in an economy that requires relevance and progressive values.

Specs & Docs

Specs and Docs are exactly that, specifications and documentation. Usually these words are associated with more of a waterfall interaction between the business stakeholders, designers and development, where needs, concepts and solutions are thoroughly documented by each member of the team and passed to the next team and the next team and so on. This method usually means the solutions implemented address the needs of the past. I don't need to express the value of agility in product design and development. Of course it is valuable to capture decisions that are made throughout the process and provide some form of specifications to assist the collaborative process. If a pattern library is used, a team won't need to stick annotations all over the mockups to present developers with the font sizes, contai

This is it! All the previous decisions that were made will inform the look, feel and behavior of the final user interface. It is entirely possible that an amazing, modern UI could reside on top of a poorly architected system. However, this final phase is a grand opportunity to create appeal, generate excitement, build user bases, convert user's of a competitive solution, and rewarded your current users for their loyalty.

Live interactions presented through keynote animations, created in After Effects or made available through clickable prototypes on Invision and live code can often demonstrate complex interactions that would be difficult to show through static mockups.
Creating these interactions for various aspects of a project expresses intention and tends to generate more excitement and enthusiasm from stakeholders and clients.

If an efficient design and development process has been defined and established, a team will be able to take advantage of the extra time they find themselves with to create innovative interactions and micro-interactions within their work. Users are becoming more and more sophisticated every day. There is plenty of competition in almost every market of product design and development. A company can pull away from completion and retain a lead by creating intuitive interactions and delighting with thoughtful micro-interactions.