Steve Berry, Grant Hutchins, and I presented to the NYC UX/Agile MeetUp group on how to leverage a Live Style Guide when designing products in an Agile process.
2. Unifying Agile and UX with
Live Style Guides
Grant Hutchins
Pivotal Labs @nertzy
Andrew Cramer
Case Commons @andy_cramer
Steve Berry
Efficiency 2.0 @thoughtmerchant
34. Style guide driven development
• Specify new widget (visual + behavior +
naming)
35. Style guide driven development
• Specify new widget (visual + behavior +
naming)
• Implement the widget in the style guide
36. Style guide driven development
• Specify new widget (visual + behavior +
naming)
• Implement the widget in the style guide
• Re-use the widget throughout the site
40. Retrofitting
• Full site sweep of existing components
• If it shows up 3 or more times, add it
41. Retrofitting
• Full site sweep of existing components
• If it shows up 3 or more times, add it
• Name everything
42. Retrofitting
• Full site sweep of existing components
• If it shows up 3 or more times, add it
• Name everything
• Ask design to offer improvements to names
45. Discover repetition
• Putting things next to each other reveals differences
• Don't fix it yet, start a discussion
• Add all conflicting versions of the same
widgets
58. Internal Design Team at Case Commons
Design Team Context
We make digital products that help Social
Workers leverage technology when managing
their case files.
Team Breakdown
There are 3 designers that pair with 3 product
managers when researching, defining, and
building new product in an agile process.
When We Came Aboard
The internal design team grew over time since
last summer, first collaborating with IDEO
designers and then owning the user experience
design for Case Commons.
59. Inheriting the Style Guide
Printed Style Guide Live Style Guide
• Shared reusable patterns at our fingertips • Allowed us to create low-fidelity sketches
via InDesign Library Palette that reference existing patterns in the guide
• Helps to work to scale when laying out • Shared annotation for use and naming
Information Architecture, “see what fits” conventions across Dev/Product team
• Kinetic designs allowed for us to test the
functionality and see how things worked
• Both: Were useful in on-boarding and becoming acquainted
with the existing interactive patterns and styles
61. Naming Conventions in the Live Style Guide
A shared language to cut down on written
specs and high-fidelity wireframes...
62. Naming Conventions in the Live Style Guide
A shared language to cut down on written
specs and high-fidelity wireframes...
“Use the Person Auto-Completer
pattern in the Live Style Guide.”
66. Naming Conventions in the Live Style Guide
The Hammer Metaphor
“I need a 10 inch wooden stick
that can be griped with a human
hand. Attached to the end of this
wooden stick there needs to be an
8 ounce block of steel. The block of
steel needs to be balanced and not
exceeding 5 inches in length. The
steel component must have a flat
striking surface.”
Designer
67. Naming Conventions in the Live Style Guide
The Hammer Metaphor
“I need a 10 inch wooden stick
that can be griped with a human
hand. Attached to the end of this
wooden stick there needs to be an
Here you go! 8 ounce block of steel. The block of
steel needs to be balanced and not
exceeding 5 inches in length. The
steel component must have a flat
striking surface.”
Developer Designer
68. Naming Conventions in the Live Style Guide
The Hammer Metaphor
“OKAY NOW I need a 10 inch wooden
stick that can be griped with a human
hand. Attached to the end of this
wooden stick there needs to be an 8
ounce block of steel. The block of steel
needs to be balanced and not
exceeding 5 inches in length. The steel
component must have a flat striking
surface................................
Developer Designer
69. Naming Conventions in the Live Style Guide
The Hammer Metaphor
“OKAY NOW I need a 10 inch wooden
stick that can be griped with a human
hand. Attached to the end of this
wooden stick there needs to be an 8
ounce block of steel. The block of steel
needs to be balanced and not
AND I need a curved in length. The steel
exceeding 5 inches
component must have a flat striking
metal end opposite the
surface................................
striking surface which is
split in two on one end,
converging in a wedge
on the other.”
Developer Designer
70. Naming Conventions in the Live Style Guide
The Hammer Metaphor
“OKAY NOW I need a 10 inch wooden
stick that can be griped with a human
hand. Attached to the end of this
wooden stick there needs to be an 8
ounce block of steel. The block of steel
Hmm...this sounds needs to be balanced and not
very familiar... AND I need a curved in length. The steel
exceeding 5 inches
component must have a flat striking
metal end opposite the
surface................................
striking surface which is
split in two on one end,
converging in a wedge
on the other.”
Developer Designer
72. Naming Conventions in the Live Style Guide
The Hammer Metaphor
“I need a 10 inch wooden stick
that can be griped with a human
hand. Attached to the end of this
wooden stick there needs to be an
Here you go! 8 ounce block of steel. The block of
steel needs to be balanced and not
exceeding 5 inches in length. The
steel component must have a flat
striking surface.”
Developer Designer
74. Naming Conventions in the Live Style Guide
The Hammer Metaphor
Hammer
Lets put this in
our live style guide We’ll call it a
for future use! “Hammer”!
Developer Designer
76. Naming Conventions in the Live Style Guide
The Hammer Metaphor
“I need a HAMMER...
and I need a curved metal end
opposite the striking surface
which is split in two on one
end, converging in a wedge on
the other end.”
Developer Designer
77. Naming Conventions in the Live Style Guide
The Hammer Metaphor
Great, we already
have a hammer...
“I need a HAMMER...
Hammer
and I need a curved metal end
opposite the striking surface
which is split in two on one
Here you go! end, converging in a wedge on
the other end.”
Developer Designer
79. Naming Conventions in the Live Style Guide
The Hammer Metaphor
Hammer
Claw
Lets put this new
affordance in
We’ll call it a
our live style guide
“Claw”!
for future use!
Developer Designer
81. Naming Conventions in the Live Style Guide
Finding a balance when naming...
Seclect relationship
This person may already be on file
RELATIONSHIP PERIOD
Refine your search:
Start date to Age Ongoing
Functionally descriptive. Address (approximate)
Ongoing
Top 6 Results (56 total) Arange By
Visually descriptive.
Mark Abett
DESCRIPTION OF RELATIONSHIP M, 32
We’ll call it the Write about relationship Jersey St., Indianapolis, IN 46204
51 S. New
“Non-modal filterable Mark Brooster M, 20
person auto-completer 51 S. New Jersey St., Indianapolis, IN 46204 We’ll call it the
overlay”! Mark Piper M, 42 “Red drop down”!
Cancel
51 S. New Jersey St., Indianapolis, IN 46204
Dave Markster M, 12
51 S. New Jersey St., Indianapolis, IN 46204
Patricia Marksman M, 32
51 S. New Jersey St., Indianapolis, IN 46204
Patricia Marksman M, 32
51 S. New Jersey St., Indianapolis, IN 46204
Not listed? Create as a new person
Developer Designer
83. Naming Conventions in the Live Style Guide
A human-centered approach to naming...
Seclect relationship
This person may already be on file
I use this when I’m searching
RELATIONSHIP PERIOD
Refine your search:
Start date
Address to Age Ongoing
(approximate)
for the names of people I Top 6 Results (56 total)
Ongoing
Arange By
want to collect from our Mark Abett
DESCRIPTION OF RELATIONSHIP M, 32
system to add to a case file. Write about relationship Jersey St., Indianapolis, IN 46204
51 S. New
It automatically completes Mark Brooster M, 20
suggested names as I begin 51 S. New Jersey St., Indianapolis, IN 46204
to type. Mark Piper
Cancel
51 S. New Jersey St., Indianapolis, IN 46204
M, 42
Dave Markster M, 12
51 S. New Jersey St., Indianapolis, IN 46204
Patricia Marksman M, 32
51 S. New Jersey St., Indianapolis, IN 46204
Patricia Marksman
person auto-completer
M, 32
51 S. New Jersey St., Indianapolis, IN 46204
Not listed? Create as a new person
End User
84. From sketch to guide, Live Style Guide in the UX Design Process
85. From sketch to guide, Live Style Guide in the UX Design Process
1 Whiteboard + Strategy Session
Supervisors who oversee Foster
Home License revisions need to...
• Navigate many data points to
discern which changes to a licensed
foster care home were made.
• Remember what original data points
these changes were made from.
• Quickly revert changes that they
disagree with or require further
revisions.
Contextualizing the design challenge...
86. From sketch to guide, Live Style Guide in the UX Design Process
1 Whiteboard + Strategy Session
Supervisors who oversee Foster
Home License revisions need to...
• Navigate many data points to
discern which changes to a licensed
foster care home were made.
• Remember what original data points
these changes were made from.
• Quickly revert changes that they
disagree with or require further
revisions.
Existing Patterns
Contextualizing the design challenge...
87. From sketch to guide, Live Style Guide in the UX Design Process
1 Whiteboard + Strategy Session
Supervisors who oversee Foster
Home License revisions need to...
• Navigate many data points to
discern which changes to a licensed
foster care home were made.
• Remember what original data points
these changes were made from.
• Quickly revert changes that they
disagree with or require further
revisions.
New Pattern Existing Patterns
Contextualizing the design challenge...
88. From sketch to guide, Live Style Guide in the UX Design Process
89. From sketch to guide, Live Style Guide in the UX Design Process
2 Design (UX) + User Story (PM)
Naming Syntax:
Function + Visual Descriptor
A Design Vocabulary + Grammar
90. From sketch to guide, Live Style Guide in the UX Design Process
2 Design (UX) + User Story (PM)
A Design Vocabulary + Grammar
91. From sketch to guide, Live Style Guide in the UX Design Process
92. From sketch to guide, Live Style Guide in the UX Design Process
3 Refine Design and Bid with Developers
Collaborating with developers...
93. From sketch to guide, Live Style Guide in the UX Design Process
94. From sketch to guide, Live Style Guide in the UX Design Process
4 Leverage the New Pattern
Revisions for Assessments and
Ongoing Cases
Foster Family Licensing is just one piece of the
Casebook software, this pattern may be utilized
when specific edits are requested to supervisors
on Assessment and Ongoing Cases.
Versioning Bi-Annual Case
Submissions
Every six months Ongoing Cases must be
resubmitted, the Revision Bar can help call out
which data points have changed on the case.
Now we have a hammer...
95. From sketch to guide, Live Style Guide in the UX Design Process
96. From sketch to guide, Live Style Guide in the UX Design Process
Whiteboard + Strategy Session
1 Product Manager and User Experience Designer translate
high-level policy and business requirements into user flows
Product
Designer
and new affordances.
Manager
Design (UX) + User Story (PM)
2 Product Manager writes user stories and User Experience
Designer creates designs based on whiteboard session.
Product
Designer
Manager
Refine Design and Bid with Developers
3 Product Manager and User Experience Designer present user
stories and designs to developers. Developers collaborate to
Developers + Designer + PM
help refine designs and to bid on user stories.
Leverage the new Pattern
4 Product Manager and User Experience Designer think about
what ways they can strategically leverage new design pattern
Product
Designer
elsewhere in the product.
Manager
122. A Live Style Guide is:
A consolidated vocabulary of the
application’s visual and interactive
language.
123.
124.
125. Resources Slides
• Jim Lindstrom’s UX Mag article
http://uxmag.com/articles/anchoring-your-design-language-in-a-live-style-guide
• Hammer metaphor by Karl Llewellyn
http://www.inrhythm.com/
• CUB Energy Saver Live Style Guide
http://www.CUBenergysaver.com/style_guides
• Front-End Style Guides
http://24ways.org/2011/front-end-style-guides
Notes de l'éditeur
\n
Make sure people are familiar with the companies\n
- Enables problem solving across the team\n- Creates a consistent language to communicate to the user\n\n\n
- Enables problem solving across the team\n- Creates a consistent language to communicate to the user\n\n\n
\n\n
\n\n
A style guide or style manual is a set of standards for the writing and design of documents, either for general use or for a specific publication, organization or field. The implementation of a style guide provides uniformity in style and formatting of a document.\n\nThe vocabulary of your visual and interactive language\nEnables problem solving across the team\nA process for creating and maintaining a visual and interactive language.\n\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
(value of in-house team)\n\n
(value of in-house team)\n\n
(value of in-house team)\n\n
(value of in-house team)\n\n
Don’t focus on the static guide, talk about how the live guide was really more helpful ‘cause its “kinetic”, then go into how we leveraged it better by starting to work more on naming conventions. \n(hand-off from grant)\nfirst give context to how the design team inherited a live style guide plus a static one (from Daniel), and how were both useful In their own way \n\n
A shared language to cut down on written specs\nWhen I came aboard we we were at a point where both developers and designers agreed that we needed a naming convention for the reusable patterns that we were saving in the live style guide. This would allow us to create low-fi sketches and quickly label the sketch with commons names that referenced the live style guide. (image of hand sketch with a label assigned to a pattern)\n
A shared language to cut down on written specs\nWhen I came aboard we we were at a point where both developers and designers agreed that we needed a naming convention for the reusable patterns that we were saving in the live style guide. This would allow us to create low-fi sketches and quickly label the sketch with commons names that referenced the live style guide. (image of hand sketch with a label assigned to a pattern)\n
A shared language to cut down on written specs\nWhen I came aboard we we were at a point where both developers and designers agreed that we needed a naming convention for the reusable patterns that we were saving in the live style guide. This would allow us to create low-fi sketches and quickly label the sketch with commons names that referenced the live style guide. (image of hand sketch with a label assigned to a pattern)\n
A shared language to cut down on written specs\nWhen I came aboard we we were at a point where both developers and designers agreed that we needed a naming convention for the reusable patterns that we were saving in the live style guide. This would allow us to create low-fi sketches and quickly label the sketch with commons names that referenced the live style guide. (image of hand sketch with a label assigned to a pattern)\n
A shared language to cut down on written specs\nWhen I came aboard we we were at a point where both developers and designers agreed that we needed a naming convention for the reusable patterns that we were saving in the live style guide. This would allow us to create low-fi sketches and quickly label the sketch with commons names that referenced the live style guide. (image of hand sketch with a label assigned to a pattern)\n
A shared language to cut down on written specs\nWhen I came aboard we we were at a point where both developers and designers agreed that we needed a naming convention for the reusable patterns that we were saving in the live style guide. This would allow us to create low-fi sketches and quickly label the sketch with commons names that referenced the live style guide. (image of hand sketch with a label assigned to a pattern)\n
\n
The Hammer Metaphor\nThe rationale for naming conventions in a live style guide is to alleviate the need to articulate functionality in words when you can leverage a shared reference point. The hammer metaphor is a great example of how this works (site Karl from BN.com). Show the hammer and then the claw add one example. \n
The Hammer Metaphor\nThe rationale for naming conventions in a live style guide is to alleviate the need to articulate functionality in words when you can leverage a shared reference point. The hammer metaphor is a great example of how this works (site Karl from BN.com). Show the hammer and then the claw add one example. \n
The Hammer Metaphor\nThe rationale for naming conventions in a live style guide is to alleviate the need to articulate functionality in words when you can leverage a shared reference point. The hammer metaphor is a great example of how this works (site Karl from BN.com). Show the hammer and then the claw add one example. \n
The Hammer Metaphor\nThe rationale for naming conventions in a live style guide is to alleviate the need to articulate functionality in words when you can leverage a shared reference point. The hammer metaphor is a great example of how this works (site Karl from BN.com). Show the hammer and then the claw add one example. \n
The Hammer Metaphor\nThe rationale for naming conventions in a live style guide is to alleviate the need to articulate functionality in words when you can leverage a shared reference point. The hammer metaphor is a great example of how this works (site Karl from BN.com). Show the hammer and then the claw add one example. \n
The Hammer Metaphor\nThe rationale for naming conventions in a live style guide is to alleviate the need to articulate functionality in words when you can leverage a shared reference point. The hammer metaphor is a great example of how this works (site Karl from BN.com). Show the hammer and then the claw add one example. \n
The Hammer Metaphor\nThe rationale for naming conventions in a live style guide is to alleviate the need to articulate functionality in words when you can leverage a shared reference point. The hammer metaphor is a great example of how this works (site Karl from BN.com). Show the hammer and then the claw add one example. \n
The Hammer Metaphor\nThe rationale for naming conventions in a live style guide is to alleviate the need to articulate functionality in words when you can leverage a shared reference point. The hammer metaphor is a great example of how this works (site Karl from BN.com). Show the hammer and then the claw add one example. \n
The Hammer Metaphor\nThe rationale for naming conventions in a live style guide is to alleviate the need to articulate functionality in words when you can leverage a shared reference point. The hammer metaphor is a great example of how this works (site Karl from BN.com). Show the hammer and then the claw add one example. \n
The Hammer Metaphor\nThe rationale for naming conventions in a live style guide is to alleviate the need to articulate functionality in words when you can leverage a shared reference point. The hammer metaphor is a great example of how this works (site Karl from BN.com). Show the hammer and then the claw add one example. \n
\n
\n
\n
\n
The Hammer Metaphor\nThe rationale for naming conventions in a live style guide is to alleviate the need to articulate functionality in words when you can leverage a shared reference point. The hammer metaphor is a great example of how this works (site Karl from BN.com). Show the hammer and then the claw add one example. \n\n\n\n
\n
The Hammer Metaphor\nThe rationale for naming conventions in a live style guide is to alleviate the need to articulate functionality in words when you can leverage a shared reference point. The hammer metaphor is a great example of how this works (site Karl from BN.com). Show the hammer and then the claw add one example. \n\n\n\n
The Hammer Metaphor\nThe rationale for naming conventions in a live style guide is to alleviate the need to articulate functionality in words when you can leverage a shared reference point. The hammer metaphor is a great example of how this works (site Karl from BN.com). Show the hammer and then the claw add one example. \n\n\n\n
The Hammer Metaphor\nThe rationale for naming conventions in a live style guide is to alleviate the need to articulate functionality in words when you can leverage a shared reference point. The hammer metaphor is a great example of how this works (site Karl from BN.com). Show the hammer and then the claw add one example. \n\n\n\n
The Hammer Metaphor\nThe rationale for naming conventions in a live style guide is to alleviate the need to articulate functionality in words when you can leverage a shared reference point. The hammer metaphor is a great example of how this works (site Karl from BN.com). Show the hammer and then the claw add one example. \n\n\n\n
The Hammer Metaphor\nThe rationale for naming conventions in a live style guide is to alleviate the need to articulate functionality in words when you can leverage a shared reference point. The hammer metaphor is a great example of how this works (site Karl from BN.com). Show the hammer and then the claw add one example. \n\n\n\n
\n
Overly descriptive functionally vs visually\nYou need to decide what the size of your pattern is, what affordances should be clustered together at what level of detail.\n\nShow the natural tension of the developers wanting to name a card with overly minute and purely functional labeling vs. a higher level descriptive name that spoke to human interaction with the widget. \n
A human-centered approach to naming...\n Think about the user flow and what the user is thinking about when they are using this widget. \n
Let’s talk about a real world example...\n User needs a clear visual cue of a change in state, and an immediate actionable way to change it back. (new pattern)\n - Problem defining vs problem solving\n - Learning larger context, we had a better understanding of the problem\n
Let’s talk about a real world example...\n User needs a clear visual cue of a change in state, and an immediate actionable way to change it back. (new pattern)\n - Problem defining vs problem solving\n - Learning larger context, we had a better understanding of the problem\n
Let’s talk about a real world example...\n User needs a clear visual cue of a change in state, and an immediate actionable way to change it back. (new pattern)\n - Problem defining vs problem solving\n - Learning larger context, we had a better understanding of the problem\n
Let’s talk about a real world example...\n User needs a clear visual cue of a change in state, and an immediate actionable way to change it back. (new pattern)\n - Problem defining vs problem solving\n - Learning larger context, we had a better understanding of the problem\n
Let’s talk about a real world example...\n User needs a clear visual cue of a change in state, and an immediate actionable way to change it back. (new pattern)\n - Problem defining vs problem solving\n - Learning larger context, we had a better understanding of the problem\n
Let’s talk about a real world example...\n User needs a clear visual cue of a change in state, and an immediate actionable way to change it back. (new pattern)\n - Problem defining vs problem solving\n - Learning larger context, we had a better understanding of the problem\n
Let’s talk about a real world example...\n User needs a clear visual cue of a change in state, and an immediate actionable way to change it back. (new pattern)\n - Problem defining vs problem solving\n - Learning larger context, we had a better understanding of the problem\n
Let’s talk about a real world example...\n User needs a clear visual cue of a change in state, and an immediate actionable way to change it back. (new pattern)\n - Problem defining vs problem solving\n - Learning larger context, we had a better understanding of the problem\n
Let’s talk about a real world example...\n User needs a clear visual cue of a change in state, and an immediate actionable way to change it back. (new pattern)\n - Problem defining vs problem solving\n - Learning larger context, we had a better understanding of the problem\n
Let’s talk about a real world example...\n User needs a clear visual cue of a change in state, and an immediate actionable way to change it back. (new pattern)\n - Problem defining vs problem solving\n - Learning larger context, we had a better understanding of the problem\n
Let’s talk about a real world example...\n User needs a clear visual cue of a change in state, and an immediate actionable way to change it back. (new pattern)\n - Problem defining vs problem solving\n - Learning larger context, we had a better understanding of the problem\n
Let’s talk about a real world example...\n User needs a clear visual cue of a change in state, and an immediate actionable way to change it back. (new pattern)\n - Problem defining vs problem solving\n - Learning larger context, we had a better understanding of the problem\n
Let’s talk about a real world example...\n User needs a clear visual cue of a change in state, and an immediate actionable way to change it back. (new pattern)\n - Problem defining vs problem solving\n - Learning larger context, we had a better understanding of the problem\n
Working in a interactive language and grammar, naming convention and style.\n - Leveraging what already exists\n
Working in a interactive language and grammar, naming convention and style.\n - Leveraging what already exists\n
Working in a interactive language and grammar, naming convention and style.\n - Leveraging what already exists\n
Working in a interactive language and grammar, naming convention and style.\n - Leveraging what already exists\n
Showing all the states of the interactive dialog.\n
Working in a interactive language and grammar, naming convention and style.\n - Opportunity to collaborate on the placement and context of the alert\n - Each team member (dev and design) speaks the language of the application\n
Working in a interactive language and grammar, naming convention and style.\n - Opportunity to collaborate on the placement and context of the alert\n - Each team member (dev and design) speaks the language of the application\n
Working in a interactive language and grammar, naming convention and style.\n - Opportunity to collaborate on the placement and context of the alert\n - Each team member (dev and design) speaks the language of the application\n
Working in a interactive language and grammar, naming convention and style.\n - Opportunity to collaborate on the placement and context of the alert\n - Each team member (dev and design) speaks the language of the application\n
How we might re-use the Revision Bar...\n - An asset that we can build off of and find new applications for\n Discuss the ways we may leverage the work flow and design pattern in future pieces of the software.\nHighlighting Deltas\n
How we might re-use the Revision Bar...\n - An asset that we can build off of and find new applications for\n Discuss the ways we may leverage the work flow and design pattern in future pieces of the software.\nHighlighting Deltas\n
How we might re-use the Revision Bar...\n - An asset that we can build off of and find new applications for\n Discuss the ways we may leverage the work flow and design pattern in future pieces of the software.\nHighlighting Deltas\n
*move through this fast*\n Creating the “Revision Bar” pattern...\n Show the step by step process with visuals on how we moved from a sketch-board to an implemented widget that is now captured in the live style guide.\n \n
*move through this fast*\n Creating the “Revision Bar” pattern...\n Show the step by step process with visuals on how we moved from a sketch-board to an implemented widget that is now captured in the live style guide.\n \n
*move through this fast*\n Creating the “Revision Bar” pattern...\n Show the step by step process with visuals on how we moved from a sketch-board to an implemented widget that is now captured in the live style guide.\n \n
*move through this fast*\n Creating the “Revision Bar” pattern...\n Show the step by step process with visuals on how we moved from a sketch-board to an implemented widget that is now captured in the live style guide.\n \n
\n
We build applications to help people save energy.\n
\n
\n
- The kinds of tasks that a live style guide enables\n- very powerful\n
- The kinds of tasks that a live style guide enables\n- very powerful\n
- The kinds of tasks that a live style guide enables\n- very powerful\n
- The kinds of tasks that a live style guide enables\n- very powerful\n
- The kinds of tasks that a live style guide enables\n- very powerful\n
\n
\n
\n
\n
\n
\n
\n
\n
Jump to demo.\n
Jump to demo.\n
Jump to demo.\n
\n
\n
Tools to improve consistent communication with the user\nkeeping them oriented and meet their expectations\n...and make our lives a hell of a lot easier\n\n
Tools to improve consistent communication with the user\nkeeping them oriented and meet their expectations\n...and make our lives a hell of a lot easier\n\n