scott fleck - ux portfolio
TRANSCRIPT
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
SCOTT FLECK - UX PORTFOLIO 3December 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
SCOTT FLECK - UX PORTFOLIO 4December 2014
Observe and Interview
• Actors and stakeholders
• Understanding of existing
processes and workflows
• Likes/dislikes
• Pain points
Possible Deliverables
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
UX DesignProcessSteps
SCOTT FLECK - UX PORTFOLIO 5December 2014
Personas and Mapping
• Identification of primary
and secondary personas
• User goals and needs
• Barriers to adoption
• Scenarios and corresponding
workflows
Possible Deliverables
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
UX DesignProcessSteps
SCOTT FLECK - UX PORTFOLIO 6December 2014
Design and Assess
• Storyboards
• Object / Data models
• Design style guides
• Final artwork / designs
Possible Deliverables
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
UX DesignProcessSteps
SCOTT FLECK - UX PORTFOLIO 7December 2014
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
December 2014 SCOTT FLECK - UX PORTFOLIO 9
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
SCOTT FLECK - UX PORTFOLIO 10December 2014
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.
December 2014 SCOTT FLECK - UX PORTFOLIO 11
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
December 2014 SCOTT FLECK - UX PORTFOLIO 12
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.
December 2014 SCOTT FLECK - UX PORTFOLIO 13
• 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 14December 2014