User flow comparison, before and after.
Project Tracker Landing Page
The landing page is the tool’s “home” page (within the platform environment). It is the first page that users access when using Project Tracker, and the typical starting point for creating a new issue.
Project Metrics landing page: OLD
Project Metrics landing page: REDESIGNED
- Empty page
- Empty landing page offers little value and is a lost opportunity to provide value.
- Confusing page defaults
- The page defaults to what the person last did in the tool (i.e. entering a new artifact, querying, or making a report). This confused users — it did not map to their expectations or typical workflow.
- Tabs are misleading
- The three functions represented as tabs are not actually connected to each other. They are independent actions, and there is no communication between those actions (passing fields, etc.). This frustrated people. Also, the visual meaning of tabs is inconsistent with the rest of the platform, adding to the confusion.
- Tabs are redundant
- The tab actions are already available in the main navigation.
- Value for the user
- An at-a-glance overview of artifacts in the project is displayed, with personalized content. This makes the requisite landing page immediately useful and valuable.
- Info people want
- “My active defects” is the most common query by users. Making that information the default content on the page reduced users’ time and effort. Satisfaction increased.
- Project summary
- The aggregate “Project Summary” is not available anywhere else in the application — its inclusion addresses many long-standing user requests.
- Predictable page behavior
- The user can confidently know the page will behave consistently and to be up-to-date.
- Tabs eliminated
- The new design removes the tabs, eliminating confusion and conflict with the application-wide navigation.
Enter New Defect, Step 1
- Navigation tabs are (still) displayed
- Visual disorder: form fields
- Inconsistent field widths create visual distraction by incoherent positive and negative spaces. The user has difficulty “reading” the page because of the visual noise.
- Layout is not matched to the audience/user
- The existing layout uses a fixed single-axis format, labels on the left and the form fields on the right. Although this is an easy layout, it is overly simplistic and does not use the screen space well. The audience of this application wants maximum efficiency.
- Entry fields are not responsive
- The form fields do not adapt to the user’s screen width or the amount of the text entered.
- Two-column layout
- A two-column layout is created using a simple, fail-safe, algorithm. Since it is done programmatically, the ability to customize the fields is maintained (e.g. admin users can add and remove fields for different issue types).
- The tabs are removed so the user can focus more directly on the task. This is the first step on the path of narrowing task focus to benefit the user.
- Reduced user effort
- Only those fields that are necessary and relevant are displayed on the entry screen. Example: the tracking and lifecycle values are irrelevant when a defect is entered — they do not need to be on screen until the defect has moved to later states in the workflow (e.g. verified, accepted, started). This lowers the effort required for entry and improves focus.
- User assignments and attachments can be added right away
- Users can be assigned to the defect, and attachments can be included immediately without additional navigation. This aligns with user expectations and needs. For example, an interface defect will need a screenshot attachment.
- Adaptive widths
- Fields are given a minimum width that is greater than or equal to 75% of the values. This establishes a stable visual appearance while supporting internationalization.
- Improved visual/usability
- Form labels are redesigned for an improved look and quicker parsing by the user. The primary action button (submit) is visually separated from the other buttons.
Enter New Defect, Step 2
- Multiple steps before item is created
- A person is required to work through multiple pages before the defect is actually created. People found this confusing and often lost work because they expected it to be created after the first page.
- Navigation tabs are (still!) displayed
- No team roles
- Team associations (e.g. owner, QA contact, etc.) are not available as part of the entry process. Since user assignments and roles are a core part of workflow, this was a critical issue for customer teams.
- Redundant “required fields” legends
- In each group of fields, the “required fields” caption is displayed because the rendering logic was not built to consider the whole page. This wastes attention and vertical space.
- Overly complex and technical "Add Attachment" process
- The function to add an attachment is much more complicated than users expect or need. The “Type” field requires the user to select a mime-type. Users should not have to know the mime-type — the application should do this work.
- “After submit” confuses people
The presence of the field here requires a user to answer questions about what to do next before knowing if the defect was actually successfully entered.
Also, form fields are used as navigation.
- Unbounded length
- All possible fields in the defect are always displayed. As the defect definition grows to include additional fields, the page length also grows.
- Simplification — No step #2
Submitting the defect is changed into a single-page task, simplifying the cognitive load on the user and keeping the attention focused on the main activity.
“Reason” and “After submit” are eliminated.
When the page is submitted, the defect entry is created. The view refreshes, and the confirmation message is displayed.
- Lost message
- The confirmation message is small and easily missed at the top of the page. Communication that the action was successful is unclear, and the user is uncertain about what is happening.
- Clear message
- Once the defect has been submitted, validated, and is actually in the system, an unambiguous confirmation message is displayed using established visual styles.
- Focused assistance: What would you like to do next?
- At this point, the user has completed their task, and can think about the next steps. The application presents appropriate choices in a clear, friendly manner that supports rapid recognition and decision making. The actions listed have been chosen based on usage frequency.
- View is not comprehensive
- Instead of presenting a comprehensive view of the defect, the information is split into tabbed segments, requiring multiple clicks to view required details.
- Organization is arbitrary
- User research established that people do not hold a workflow distinction between fields such as “Priority” and “Assignee.” However, the application separates these values onto different screens, forcing a workflow on the user. This separation is an arbitrary historical decision, made without user feedback.
- Unbounded length
- All possible custom fields in the defect are displayed. As the defect definition is customized and grows to include new fields, the page length also grows.
- Single page
- All of the primary fields are available on a single page for review and editing, including assignments, attachments, and comments. Reduces the time and effort required from the user.
- User control over what is displayed
- Text areas keep text readable
- Using capabilities that degrade gracefully, the text areas will grow if the text extends beyond the default height of the field. This allows the user to review all of the text efficiently.