Mike Haught - My Design Process

DESIGN PROCESS

The following documents my design process. While no two projects are ever exactly the same, there are some common waypoints and artifacts generated along the way to help communicate the design concepts. I should note that this is my process that has come from many years in design. Like with many processes, some projects and deadlines demand alterations or exceptions, but generally I try and stick to this format. This allows me to navigate the design process and (critically) bring others along with me.

Contact Info:

E-mail: ScaryBiscuitsStudios@gmail.com

Step One:

DISCOVERY

The first step of any project is the discovery of the idea. For personal projects, this is usually a novel idea for something I want to create. For client projects, it's about getting to know the design requirements and thinking about some ideas on how to turn them into a product.

I will spend a lot of time listening to the client and earmarking some early solutions to investigate. I'll look into existing products that attempt to fill the same space and get across best and current practices. As usual, I'll take a lot of notes and collect source material. With educational e-learning and VR training projects, I will attempt to attend as many training sessions as possible to understand the space I'll be working in.

Design Artifacts

The main artifact that emerges at this stage is a Product Objectives & Requirements Document. This will outline what problem this product aims to solve or outlines the gap it will fill, client specifications, and preliminary costings. For educational products this will involve mapping out an Instructional Design Model (IDM) to identify learning outcomes and objectives.

Tools

Google Drive & Docs, Dynalist

Step Two:

CONCEPTING

After initial explorations and the objectives have been staked out, I will start to organize the ideas into groups, such as user personas, broad mechanics ideas, data, research documents, etc. I'll then start to align the groups to the product objectives to identify critical resources and secondary ones.

From there I'll start putting down concepts for each group. These can include everything from map sketches, mechanical concepts, high-level flow documentation, and more. I tend to keep my mind open to new ideas but I also keep a mental library of older ideas that might suit this new project. I'll start to arrange these ideas into a storyboard that I can communicate to the client or peers to get some high-level feedback on my direction. I'll process that feedback and measure it against the product objectives and triage them accordingly.

Design Artifacts

The output of this stage is a Storyboard full of general concepts. This should give the client or a reviewer a brief and clear look at the project end-to-end from a high-level.

Tools

Miro, Draw.io, Photoshop

Step Three:

WIREFRAMING

With the storyboard signed off, the next phase is to build out the concepts into more robust designs and start creating styles and parameters that can be applied throughout the product. Through this process, I will identify and remove any distractions to the objectives and bottlenecks to the flow.

For printed material or screen-based designs (such as mobile apps or e-Learning pages), I'm exploring layouts and settling on some templates. I'm looking to see how the elements appear on a screen or page, finding common elements, streamlining mechanics, and eliminating excess.

For 3D space designs (such as digital games and virtual or augmented reality applications), I use this phase to start laying out underlying logic for mechanics, drawing up level designs, identifying features, and ultimately tying it all together by creating application flows.

Design Artifacts

What comes out of this stage is a detailed Wireframe and a Feature List. There should be enough information in these artifacts to interactively move through the experience and have a handle how it will flow and what features will need to be developed to make it possible.

Screen Shot 2020-09-25 at 9.25.25 PM.png

Tools

Figma, Miro, Google Docs & Sheets, inDesign

Step Four:

PROTOTYPING

Thanks to the storyboard and wireframing, I am prepared to go into prototyping. I'll start making and testing prototypes of features and then bring these together to assemble a working model of the game so that I can test my design concepts as a whole. The highest risk features are built out first so that they can be tested sooner.

For printed prototypes, I'll design the elements using inDesign and print out a paper prototype for some testing. Whenever possible, I'll do this for 3D digital products as well. For web-based or mobile apps, I'll put these together as working prototypes in Figma. For more complicated prototypes I'll use Unity to mock things up.

No feature, concept, or mechanic is sacred in this process as I take an objective and critical look at each to ensure its the best option to deliver the objectives and scope of the product. Once the prototype is generally stable and represents the intent of the design, I will update my design documentation to account for any changes.

Design Artifacts

At the end of this stage, there is a Prototype that functions approximately same as the final product. All of the major features are tested in this environment and I should have a more complete view of the size of the project.

Tools

Miro, Google Sheets, Figma, inDesign, Acrobat Reader, Unity

Step Five:

FEEDBACK & ITERATION

I will distribute the prototype as far as pracitcable and gather as much feedback from clients, peers, and stakeholders as possible. Where features are complicated, I will also get feedback from developers to discuss the best approach to tackle the underlying design requirement. I then triage all this feedback through the lens of the original product objectives to make sure that I'm staying focused on the original intent.

After taking on relevant feedback, I'll make adjustments and improvements to the prototype. Then I'll re-circulate the prototype with the relevant people to see if the new solution fits their feedback. This step operates as a series of loops and can take as many or as few cycles as time and resources permit. However, generally the more time spent in this phase, the more efficient and prepared the production will be.

Design Artifacts

At the conclusion of this step, the prototype should evolve into an improved Alpha Version of the final project. All of the core concepts are represented and have been given as much design consideration as possible.

screen_shot_2016-12-15_at_10.18.50_am_10

Tools

Figma, Miro, Google Sheets & Forms, inDesign

Step Six:

PRE-PRODUCTION

Completing the Alpha Version signals that the project is nearly ready for production. However, before the design can be handed off to developers, it needs to be chunked up into milestones and then mapped out so that the project is built in a logical and relatively stable way.

When the project goes into production, the designer needs to be able to verify the features are made according to the original design. The key skill here is to be able to identify which features need to be developed first. Typically I first consider what features are essential to deliver a minimum viable product. Then I triage priority based the highest risk features first. That way if they fail or cannot be built, then there is time to develop an alternative. As is often the case, elements of features will have dependencies with other elements, so I will map these dependencies out and have the developers tackle the foundational building blocks first.

With a plan in mind, I then make sure that all of the artifacts from the earlier steps are captured and documented for the wider team to easily access. This is typically accomplished via a project wiki or something similar.

Design Artifacts

There should also be enough information at this point to make some effort estimates and pull together a Scoping Document and map out milestones. This is typically done in close consultation with producers and development team leaders.

Tools

Confluence, Figma, Miro, Google Sheets, Project Management Software (Hansoft, TargetProcess, Jira, etc)

Step Seven:

PRODUCTION

With the milestones set, the project is ready to be moved into production. I will usually hold a design kick off with the developers (or just the leads in the case of larger teams) and walk them through several of the design artifacts, starting with the Product Objectives & Requirements Document to provide a baseline direction for the project. I'll then go through the wireframe to show the breadth of the project. Finally, I'll run them through the Alpha so they can see and experience the design as much as possible. I'll let the team go away and then process all of the artifacts and then come back together with the production team and start planning our sprints using the milestones as our short term objectives.

During production, I'll remain deeply embedded with the team to answer questions, make judgement calls, and help where I can. However, I aim to empower the team to make their own judgement calls based on the documentation I've provided and their own experience. I'll keep tabs on the project, regularly testing it to make sure the project objectives are being met.

Design Artifacts

The ultimate output of this step is a playable Minimum Viable Product (or MVP) Beta Version. I can put this in front of stakeholders, clients, the QA team, and others for feedback, review, or demonstration.

Tools

Confluence, Figma, Miro, Google Sheets, Project Management Software (Hansoft, TargetProcess, Jira, etc), Unity

Step Eight:

QUALITY ASSURANCE & POLISH

This step isn't strictly sequential to the previous one. I typically like to get the quality assurance team involved once the project has a working backbone and a complete experience flow. I'll then work with the QA team to get them across the project, establish test cases, and set up any required processes for managing feedback and bugs.

If this process is happening during Production, I will take a more active role in this process and own the triage process. This helps ensure that bugs that are logged are not just a result of incomplete WIP features. I will also set bug priority according to the project's milestones and stability.

Polishing tasks can be added to the project, provided the main MVP features are in and stable, the additions are low-risk, there is still some time and resource remaining, and there is time for QA to test the product.

Design Artifacts

This step will generate Test Cases for the QA team to use when going through the project.

Tools

Confluence, Figma, Miro, Google Docs

Step Nine:

SHIP IT

I've never shipped a project that I've felt was 100% complete. Along the way, compromises needed to be made to ensure deadlines are met, features added at the last minute, and other similar emergencies crop up. In my experience, this is just the nature of these sorts of projects. Deadlines will always be short, the demand for new features sometimes irresistible. The best a designer can do is help make sure these changes and compromises adhere strictly to the product objectives, inform stakeholders of the impact of the changes, and help ensure the final project stays on course.

Design Artifacts

There's no specific artifact for this stage, but the output should be a ready and stable Final Product.

Step Ten:

UAT, ANALYTICS, & POST MORTEM

Once a project has been shipped, I try an reflect on it. This reflection can come across in several ways.

If I'm building this for a client, User Acceptance Testing (or UAT) is a common practice of putting the finished product in front of them so that they can test out on their end, figure out how to integrate it into their systems and processes, and generally get a final sign off. While this is happening, I'll be collecting their feedback and making any tweaks as necessary, and working with the production team to triage and estimate the changes before implementing them. Once both sides are happy with the resources and time required, the changes will be implemented and sent through QA.

Other forms of reflection come from analytics that come from use of the product. As the data coming through increases, so too does my understanding about how it's being used and what's not being used. If they are critical problems, I'll design solutions. If they are not critical, I'll note them in the event that we re-open the project for further development.

Finally, I always try and have a good post-mortem review with each of the teams. I'll not only look at the design and the result, but also the processes that got us there to see if there's improvements that can be made to make the pipeline more efficient.

Design Artifacts

The key documents generated at this final stage include UAT Feedback Documents and a Post-Mortem Report.

Tools

Workshops, Confluence, Google Forms & Sheets