Windows Blue Screen of Death
Academic Work
A redesign of the Windows Blue Screen of Death screen to demystify the system status and the cause of errors.
Team
Solo
Duration
7 Weeks
Work Spec
Academic Project
Summary
PROBLEM DEFINING
Resolving the error is a frustrating process
To understand my design process, it's necessary to know the work focused on evaluating the product based on one or two usability heuristics then — finding problems related it.
To keep the project scope low, I searched through forums to uncover the three most widespread problems based on the problems I uncovered.
All problems are related to the usability heuristic of "visibility of system status" and/or "help users recognize, diagnose, and recover from errors"
A vague status of the system
Vague terminology such as "a problem" or "some error info" fail to communicate system status and problem transparently. This leads to a poor understanding of what is currently happening and/or what happened to Windows.
In turn, users lose trust in the system from the lack of transparency.
Stop codes make diagnosing errors frustrating
BSoD stop codes communicate what triggered the BSoD event. But, they give little context to a problem (ex. CRITICAL_PROCESS_DIED) or contain technical jargon (ex. WHEA_UNCORRECTABLE_ERROR).
Users often have to guess why, when, and how a BSoD occurred.
The users who choose to research the error code often feel overwhelmed because, the solution to the error could require heavy technical knowledge or a complicated repair process.
Some codes can be intuitive to interpret. But don't provide context WHY this occurred.
Others use comlplicated technical jargon, making it difficult to infer the cause of error.
Automatic restarts are too fast
At times, Windows automatically restarts too fast. A lack of controlling the restart results in failure to read and document the problem.
This prevents users from recognizing and diagnosing system errors.
At worst, it becomes impossible for users to pass down key information to technical support teams for diagnosis and repair.
Quick restarts gives users no time to record details.
But, how do I solve the problem?
SOLUTION DESIGN
Understanding technical limitations
To start, I wanted my ideations realistic. I accessed a BSoD's dump file to find what specific information is recorded displayed.
However, some ideations cannot be applied such as the example below (WHEA_UNCORRECTABLE_ERROR) for varying reasons. I mention how I overcame this in my "BSoD variant" two sections below.
Inevitably, my goal is to help average users — without hindering power users.
Use transparent and concise language, as much as possible
Previously, the main text was vague and confusing. I revised the wording to be transparent and concise. This way, it's easier to understand the current system status and what caused the BSoD to occur.
However, it's important to note, some errors will always require an inherent knowledge of technical workings to understand.
BEFORE - Lack of transparency in system status and BSoD cause
AFTER - Clearly defines system status and BSoD cause
BSoD Variants
Changing the header text brings implementation problems. Stop codes are programmed be a variable. However, the header text was never meant to change and requires a unique instance per stop codes.
To resolve this, I chose to implement a boolean system that changes the variant of the screen based on the processed error codes. Variations of the BSoD without the QR code exist, validating the feasibility of using BSoD variants.
This also allows for screens that omit certain information to exist.
Adding context to stop codes
Additional contextual information answers the "why", "when", and "how" questions a user may have regarding a stop code.
What failed. Specifies the origin or trigger of the stop code.
Error code. Formerly used in older Windows versions to differentiate variations of a stop code. Useful for users who rely on tech support.
BEFORE - Quick restarts made key info unreadable
AFTER - Clearly defines system status and BSoD cause
Manual restarts
Forcing the user to restart the PC manually gives users time to read and document information. This also gives the user a sense of control of their PC's actions, enhancing a user's trust in Windows.
BEFORE - Quick restarts made key info unreadable
AFTER - Clearly defines system status and BSoD cause
GRANULAR DESIGN DETAILS
Use clear and concise language…as much as possible.
The original BSoD barely met WCAG requirements, making text information hard to read sometimes. To resolve this, I changed the background color to be a darker shade.
(This is a bonus for my academic project to help boost readability, leading to an easier time to digest the information.)