Product Design: Your Co-Pilot in the Software Development Process

Or: How landing a product is a lot like landing a plane

In the 1940s, following World War II, the USAF sent Paul Fitts, a psychologist by training, to investigate why thousands of airplane crashes had occurred during the war. The incident reports often concluded with “pilot error” as the cause, but the crash data didn’t reveal any randomness in the data sets. When he went to talk with the pilots who had survived, it opened up an entirely new perspective that the reports did not have.

The stories varied from pilots who misread dials, couldn’t tell which way was up, to those who never deployed their landing gear. One pilot recounted getting an alert and running to a plane that had arrived only days earlier. When he jumped in the cockpit, it appeared the entire cockpit and instrument gauges had been rearranged.

Alphonse Chapanis was a colleague of Fitts and took to investigating the airplanes, putting himself in the context of the pilot. When reviewing the B-17 Flying Fortress—a plane that had been involved in many of these crash reports—he noted that the toggle to engage the landing gear was exactly the same as that of the wing flaps and they sat right next to each other.

The investigation of these crashes led to the standardization of instrument layouts and the differentiation of the toggles used in planes which, when implemented, dramatically reduced pilot error. This work, by Fitts and Chapanis, contributed to the inception of the study of human factors. (1)

What are human factors?

Human factors are the application of psychological and physiological principles to the design of products, processes, and systems. This application is found in various disciplines such as industrial design, visual design, and user experience design.

Human factors address what people are being asked to do, how they do it and, in some cases, where they are doing the work. The ultimate goal of this is to determine a way to develop or improve a process or set of processes the person wants to undertake. In our case, that typically means software development.

Design at Slalom Build

At Slalom Build, whether the person you’re working with has the title of Experience Designer (XD), User Experience Designer (UX), or Product Designer, they all use principles and methods that tie back to the application of human factors.

The title “Product Designer” has its origins in industrial design And that has led, on occasion, to some confusion. Many designers utilize a core process of Analysis, Concept, and Synthesis to develop solutions that reduce human error, increase productivity, and enhance the interaction between the user and the experience. (3)

A product designer is responsible for defining how the experience will be useful to the end user. Although typically associated with the visual/tactile aspects of a product, designers often come to Slalom Build with a unique blend of human factors skills and experiences that they can leverage based on the unique design needs of our clients.

What does a Product Designer do?

Discover
Starting with a Discovery phase, our team’s goal is to develop an understanding of the problem scenario and the user needs at the center of that. We conduct divergent research activities that collect information and insights from the intended (and actual) users at the center of our work in addition to our client stakeholders. Our desire is to uncover what they want to accomplish, how they currently do their work and, what prevents them from doing so.

Some examples of these research activities include stakeholder interviews, user interviews, heuristic evaluations, product and business analysis, contextual inquiry, etc.

Define
These research activities lead to a process of convergence, where we synthesize all of this knowledge into summaries that help our clients understand who their users are, what needs they have, where there are new or existing areas of opportunity, and if the original problem is confirmed—or perhaps needs to go in another direction.

The results often lead to creating personas, affinity maps, user research summaries, wireframes, user flows, journey maps, or other deliverables.

During Discovery-only projects, the project outcomes enable clients to leverage our deliverables for discussions on the path forward for their project. Not every Discovery leads to a project, but our hope is to always work toward that possibility.

In the case that the project will have a Delivery phase after discovery, the Slalom team will build out a backlog that includes framework stories that will be groomed and prioritized as additional project team members are staffed for the subsequent Delivery phase. A Product Designer often will play a large role in collaborating with our Solution Owners to define requirements and acceptance criteria for a successful product experience.

Develop
Once we have an agreement with our clients on the way forward and the problems to solve, we start to prioritize and map out the features we will build. Using our initial work, we proceed to review existing branding assets, document user scenarios, and gather the data and functional needs, in order to define the requirements of user stories that will inform the desired features of the experience (4).

These user stories become a blueprint that leads us into exploring the visual form the experience will have. At this point, the Product Designer’s objectives are to:

1. Exercise iterative design cycles to continuously socialize design concepts, enabling stakeholders to make informed decisions.

2. Provide a compelling vision of the experience, how it works and how it might look.

3. Ensure that the design envisioned will accomplish the client’s business goals and accommodate for future product growth.

The output of this work can be anything from sketches to high-fidelity interactive prototypes.

Ideally, once a design satisfies the requirements of a user story, we test these design hypotheses (often called wireframes) with users to understand if their needs and the business goals are in alignment. User testing is essential because not every user completes tasks or interprets an experience in the same manner. We want to test with multiple users to see where their interactions converge and diverge while using the experience. Early testing is beneficial to our clients as it can:

1. Mitigate risks

2. Reduce development costs

3. Reduce customer service costs

4. Improve customer retention

5. Identify new opportunities

After the initial tests are completed, if necessary, the wireframes see further iterations using user feedback to improve the prospective experience. This process can loop a few times if called for, but if the experience is received well by the users, detailing the visual and interaction design can begin.

Deliver
During the Delivery phase, the goal of visual and interaction design is to translate the product and user needs into a functional experience. We take cues from the client’s brand, the competitive landscape, technical requirements and constraints, known patterns, and our own experiences to create a usable product vision that will move forward into development.

As we conceive interfaces, interactions, and design system elements, we’re leveraging human factors to make sure that our work is not only appealing but also meets acceptable standards of usability and accessibility for the end users.

Throughout this phase, a Product Designer will also be managing a process of continuous Discovery. The initial Discovery phase will establish the value proposition and help set the direction of the work, but as we build and test, new insights may be acquired that help the product fit into the market better.

As the experience (and user stories) are finalized, we create a source of truth for our development and Quality Engineering teams to reference. The designer will upload screens and views to either Zeplin, Figma, or InVision (or their design tool of choice) to provide the development team with the design documentation needed to effectively build the user interface. This is often accompanied by a high-fidelity prototype where the entire experience can be referenced and utilized for verifying motion and interaction design specifications.

While the entire team builds, Product Designers also play a key role in reviewing the details of the experience as the engineers near completion of stories. Sometimes referred to as design QA, it doesn’t always exist as a formal step but is important to consider including during Delivery work to avoid design debt early on.

Prepare for landing

Beyond the standardization of aircraft instrument layouts and the need to clearly differentiate toggles with unique functions.

Or in the case of software development:

Beyond the display of rectangles and buttons on a screen, Product Designers shape clients’ digital products. From a product’s inception as a hazy idea, the designer will bring further definition through user research, ideation for new solutions, user testing, and finally co-create the end product in collabration with our delivery team of Engineers, Solution Owners, and the client.

Oftentimes the outcome brings to life a mobile app, B2B software, product strategy, enterprise solutions…

…or even instrument dials and switches, as the case may be.

But, rest assured, the Product Designer made sure there will be no confusing the landing gear with the wing flaps. Bon voyage! 🛫

Bibliography

1. Kuang, Cliff, and Robert Fabricant. “Error.” User Friendly: How the Hidden Rules of Design Are Changing the Way We Live, Work, and Play, Penguin, London, England, 2020, pp. 80–84.
2. What is a Product Designer — Product Plan
3. Human factors and ergonomics — Wikipedia
4. Goodwin, Kim. Designing For The Digital Age, Wiley, Indianapolis, Indiana
5. 4 Reasons Why You Should User Test Your Product Early And Often
6. Krasner, Herb, The Cost of Poor Quality Software in the US: A 2018 Report, Consortium for IT Software Quality (CISQ)

Additional contributions and editing by Billy Zinser.