scott fleck - ux portfolio

Scott Fleck - UX Portfolio

The following portfolio represents some of the work I’ve been involved in and highlights the methods used in the design process. Due to non-disclosure agreements (NDAs) and ownership rights, the focus is more on process than artwork.

T A B L E O F C O N T E N T S

S A M P L E U X D E S I G N P R O J E C T S

U X D E S I G N E N V I R O N M E N T & P R O C E S S

U X D E S I G N P R O C E S S S T E P S ( 1 - 4 )

E X A M P L E P R O J E C T

• D E S I G N A P P R O A C H

• D E S I G N A S S E S S M E N T A P P R O A C H

• D E S I G N A S S E S S M E N T F E E D B A C K

• D E S I G N P R O G R E S S I O N

• C O M M U N I C A T I O N S W I T H C L I E N T

• R E S U L T S

S O F T W A R E E X P E R I E N C E T H R O U G H O U T S D L C

Snap-On Tools – Interface design for portable diagnostic tool for diesel

trucks

BD Biosciences – PC interface for medical lab testing equipment

Plex, Inc. – UX design & development forweb-based enterprise information system

Design investigation around the driver display

Automotive Aftermarket Medical / Life Sciences

Automotive OEM Manufacturing Systems

Sample UX Design Projects

SCOTT FLECK - UX PORTFOLIO 2December 2014

Define the Problem

• Problem statement

• Project vision statement

• Product positioning

statement

• Project outline

• Agile story cards

Possible Deliverables

The goal of this stage is to align all members of the team to a common vision, strategy, and scope. Typically this step involves a lot of:• Listening• Brainstorming

1

UX DesignProcessSteps


Observe and Interview

• Actors and stakeholders

• Understanding of existing

processes and workflows

• Likes/dislikes

• Pain points


The goal of this stage is to gain an understanding of the product domain through such tools as:• Job shadowing• Interviews• Questionnaires

• Client vocabulary

2



Personas and Mapping

• Identification of primary

and secondary personas

• User goals and needs

• Barriers to adoption

• Scenarios and corresponding

workflows


The most crucial stage in the process is to identify the target end-user or “primary persona”. Clients often rethink the problem definition as they work through the main tools in this step:• Personas• Persona mapping

*

3



Design and Assess

• Storyboards

• Object / Data models

• Design style guides

• Final artwork / designs


This stage is actually a series of iterations to increasingly refine the design of the final solution. The key tools are typically:• Mockups and prototypes• Design assessments with end users

• Use Cases

• Competitor analyses

4



December 2014 SCOTT FLECK - UX PORTFOLIO 8

Overview

The client was releasing a new handheld diagnostic tool that truck mechanics (technicians) would use to troubleshoot and repair large diesel trucks. The hardware had already been determined but they wanted to ensure the user interface provided a good experience for the technician.

Design Process

1. Define the Problem• The team met with the client to create the:

• Problem Statement• Project Visioning Statement• Product Positioning Statement• Overall project plan

• Constraints included:• Pre-defined hardware• Time (planned launch date already in place)• Budget• The new product competed with an existing higher-end product from the

client. The new diagnostic tool may not be able to include all the features wanted by the customer base to avoid cannibalizing sales of the top model.

2. Observe and Interview• Initial observations were conducted at about a half dozen garages.• These visits were used to understand typical workflows, workplace vocabulary,

environmental conditions, current tools used by the mechanics, and any likes/dislikes/challenges with the current process.

3. Personas and Mapping• A series of personas were created representing the population of technicians,

managers, supervisors, and tech support personnel observed• The mapping exercise put the persona "Paul Epps" at the center of the map. Paul

is a mid-level technician who is still learning but has some experience diagnosing and repairing trucks. The output from the device would not be totally new to Paul.

• Secondary personas included a shop manager who had to weigh productivity and budget against the purchase of a new tool.

4. Design and Assess• Details follow

Example Project – Design Approach


The client was able to provide a physical prototype of the diagnostic tool.

Keys masked with cutouts to test alternative keyboard layouts

Screen mockups laid on device and swapped out

based on user interaction with keyboard or stylus.

Over the course of the project more than 55 technicians across 18 dealerships and fleet garages were observed and/or used in design assessments.

The Tech Support team for the OEM truck manufacturer (a group of 8 individuals) was also observed. This team interacts with the technicians diagnosing trucks using the handheld tool. They provided valuable insight on the process and what they needed from the technician.

Example Project – Design Assessment Approach

Example Project – Design Assessment Feedback


Interpretation of icons and language

Challenge• Icons and labels were confusing to technicians.Response• Designs had to make sense to the technician

rather than the design team• Design assessments with technicians to verify

design choices for labels and icons

Intelligent default behavior

Challenge• Technicians wanted the tool to anticipate

steps in common workflows.Response• Workflows were simplified based on

feedback from technicians.• Multiple tests were bundled together when

dependencies existed.• Auto-scan of faults when technicians

connect to a truck.

Font size and dexterity challenges

Challenge• Many technicians had large hands and

aging eyes. They had difficulty reading small text on a small screen and could not easily navigate a touch screen with their fingers.

Response• Screens were designed with larger font

sizes wherever possible and content was limited to improve readability.

• Designs that were navigated using either the stylus or the keypad tested better than those that were intended for touch navigation. In cases where a technician would have a tendency to touch the screen directly, buttons were enlarged to make those features easier to use with their fingers.

Paul Epps

Age: 29

Mid-Level

Technician

Paul used to work summers at

the garage during high school so

it felt right to take a job there

after graduating from college.

It's only been 6 years since he

started but Paul feels he is still

in school. He is constantly taking

the courses offered by Navistar.

It’s tough to stay ahead on all

the electronics.

Paul hopes to get a promotion

to Supervisor soon so he can

start putting money in his son's

college fund.


Hand-drawnmockups

Wireframemodels

Proposed keyboardfrom client

Keyboard derivedfrom testing

Final keyboardartwork

Example Project – Design Progression

Designs were increasingly refined and design alternatives narrowed throughout the project. When higher resolution artwork was required, tools like Adobe were used to generate the image.

Elimination ofAlternative Designs


Example Project – Communications with Client

A weekly “Show & Tell” was established with the client to share findings. The following would typically be covered at each meeting:

• A review of open story cards• A “screenplay” walkthrough of the current designs under consideration• Feedback from observations and design assessments• Issues, risks, input from client• Q&A with the client’s development team (as needed)• Planning for the next iteration

1. How do we handle text that extends beyond the bounds of the screen? I saw areas where this could occur in Specs

& Trip, Live Data, Faults, and Running Tests. This has been the source of much frustration in our other projects. It

would be great if we could implement a solution to this problem early in the development cycle.

We'd like to avoid a horizontal scroll bar. Any text that will extend beyond the right margin of the screen

should wrap to the next line. If there are certain fields that will always have "long data" then we could

consider keeping the label on one line and starting the text on the next to avoid wrapping as much as

possible. For example:

VIN:

1HT2345H678128323

A vertical scroll bar will probably be unavoidable in many screens. Paul (the primary persona) should be

allowed to scroll down either by using the vertical scroll bar or by swiping the screen to move it up like he

would an iPhone.

2. I noticed the “Back” button isn’t used in Specs & Trip, Faults, and Running Tests. Just as an example, if Paul is

viewing Data Details, how does he return to the Live Data screen without using the keypad?

Our observations showed that most users tended to go "home" rather than go back so we made the choice to

simplify the design and remove a "back" button from the screens. A touchscreen user would have to use the

home icon in the upper right corner or use the keypad.

3. I don’t see a way of disconnecting from the vehicle. Is pulling the cable the only way to perform a disconnect?

Hmmm. That's a good question. We know the cable will get disconnected unexpectedly and just unplugging

the device from the truck will probably be the normal thing to do when a mechanic has completed their

To: <The Client>Date: Wed, Dec 3rd at 1:31 PMSubject: Some questions…

Communications outside the meeting were frequently conducted by phone or email. A typical email exchange is shown below.


• Timeline constraintso Fixed launch dateso Time needed to code new features.

Example Project – Results

Success!!!

At the completion of the project, the client was able to bring the product to market.

The design was largely adopted but not all recommendations made it into the initial release of the product. This was due to several factors:

• Preferences of the cliento The client employed ex-Technicians who had their own

preferences on certain design decisions.o The Product Manager brought his own experience to the

project from other, similar products.o The development team had their own design patterns that they

preferred.

• Technical challenges of certain featureso Wireless printing was a highly desirable

feature based on user feedback but getting this to work reliably was not straightforward for the development team

• Practical considerationso The power button could not be moved due to the hardware

designo Certain features offered no competitive edge in the

marketplace. They were either very niche or no competitor offered them.

Ideate

Plan

Analyze

Design

Develop

Test

Deploy

Maintain

• Pre-Sales Support• Discussion of Process, Resources, & Outcomes• Product Demonstrations• Responses to RFQ/RFP

• Project Manager• Defining project plans, scope, method• Defining milestones, approval process• Establishing strategies, priorities• Project kickoff• Managing project scope

• Customer/Client/Engagement Manager• Partnering with the customer to navigate the

challenges of a new project• Post-launch support of the new systems

• Team Leader/Manager• Building teams & processes• Coordinating remote resources

• Business Analyst• Uncovering workflows• Performing needs analyses

• UX Designer• Creating solutions for a positive end-user

experience

• Software Developer• Web development and database design

Software Development Lifecycle (SDLC) Phase

Roles Played on Team

Software Experience Throughout SDLC


scott fleck - ux portfolio

Documents

scott fleck ux portfolio

scott fleck ux portfoliothe

design process1

snapon tools interface

crucial stage

main tools

key tools

existing higherend product