Download - Case Study
1.What Is a Case Study?
Ans. A case study is an in-depth study of one person. Much of Freud's work and theories were developed through individual case studies.In a case study, nearly every aspect of the subject’s life and history is analyzed to seek patterns and causes for behavior. The hope is that learning gained from studying one case can be generalized to many others. Unfortunately, case studies tend to be highly subjective and it is difficult to generalize results to a larger population.2. Case Studies types?
Ans. Under the more generalized category of case study exist several subdivisions, each of which is custom selected for use depending upon the goals and/or objectives of the investigator. These types of case study include the following:
Illustrative Case StudiesThese are primarily descriptive studies. They typically utilize one or two instances of an event to show what a situation is like. Illustrative case studies serve primarily to make the unfamiliar familiar and to give readers a common language about the topic in question.
Exploratory (or pilot) Case StudiesThese are condensed case studies performed before implementing a large scale investigation. Their basic function is to help identify questions and select types of measurement prior to the main investigation. The primary pitfall of this type of study is that initial findings may seem convincing enough to be released prematurely as conclusions.
Cumulative Case StudiesThese serve to aggregate information from several sites collected at different times. The idea behind these studies is the collection of past studies will allow for greater generalization without additional cost or time being expended on new, possibly repetitive studies.
Critical Instance Case StudiesThese examine one or more sites for either the purpose of examining a situation of unique interest with little to no interest in generalizability, or to call into question or challenge a highly generalized or universal assertion. This method is useful for answering cause and effect questions.
3. . Case Studies design?
Ans. After considering the different sub categories of case study and identifying a theoretical perspective, researchers can begin to design their study. Research design is the string of logic that ultimately links the data to be collected and the conclusions to be drawn to the initial questions of the study. Typically, research designs deal with at least four problems:
What questions to study What data are relevant What data to collect How to analyze that data
In other words, a research design is basically a blueprint for getting from the beginning to the end of a study. The beginning is an initial set of questions to be answered, and the end is some set of conclusions about those questions.
Because case studies are conducted on topics as diverse as Anglo-Saxon Literature (Thrane 1986) and AIDS prevention (Van Vugt 1994), it is virtually impossible to outline any strict or universal method or design for conducting the case study. However, Robert K. Yin (1993) does offer five basic components of a research design:
1. A study's questions.2. A study's propositions (if any).3. A study's units of analysis.4. The logic linking of the data to the propositions.5. The criteria for interpreting the findings.
In addition to these five basic components, Yin also stresses the importance of clearly articulating one's theoretical perspective, determining the goals of the study, selecting one's subject(s), selecting the appropriate method(s) of collecting data, and providing some considerations to the composition of the final report.
4.When use case studies?
Ans. A case study is an intensive analysis of an individual unit (e.g., a person, group, or event) stressing
developmental factors in relation to context.[1] The case study is common in social sciences and life sciences. Case
studies may be descriptive or explanatory. The latter type is used to explore causation in order to find underlying
principles.[2][3] They may be prospective (in which criteria are established and cases fitting the criteria are included as
they become available) or retrospective (in which criteria are established for selecting cases from historical records
for inclusion in the study).
Thomas[4] offers the following definition of case study: "Case studies are analyses of persons, events, decisions,
periods, projects, policies, institutions, or other systems that are studied holistically by one or more methods. The
case that is the subject of the inquiry will be an instance of a class of phenomena that provides an analytical frame —
anobject — within which the study is conducted and which the case illuminates and explicates."
Rather than using samples and following a rigid protocol (strict set of rules) to examine limited number of variables,
case study methods involve an in-depth, longitudinal (over a long period of time) examination of a single instance or
event: a case. They provide a systematic way of looking at events, collecting data, analyzing information, and
reporting the results. As a result the researcher may gain a sharpened understanding of why the instance happened
as it did, and what might become important to look at more extensively in future research. Case studies lend
themselves to both generating and testing hypotheses.[5]
Another suggestion is that case study should be defined as a research strategy, an empirical inquiry that
investigates a phenomenon within its real-life context. Case study research can mean single and multiple case
studies, can include quantitative evidence, relies on multiple sources of evidence, and benefits from the prior
development of theoretical propositions. Case studies should not be confused with qualitative research and they can
be based on any mix of quantitative and qualitative evidence. Single-subject research provides the statistical
framework for making inferences from quantitative case-study data.[3][6] This is also supported and well-formulated in
(Lamnek, 2005): "The case study is a research approach, situated between concrete data taking techniques and
methodologic paradigms."
The case study is sometimes mistaken for the case method, but the two are not the same.
5. Key elements of a case study:
Ans.key elements of a case study:
Widest (not just Harvard Business model) multimedia as appropriate flexible for multiple purposes permitting contextual interactivity supporting materials
Peer-reviewed models of practice
Analysis Theory to practice
Shared explicit examples
Rich case material to engage viewers
Visual message permits "show me"
Examples to include good bad AND mediocre stages of innovation
Framework or metaphor for a case or a collection of minicases ...
Vignettes Walkthroughs
Series of minicases
Long (45-1 hour for context) remains important
Mediation of Case studies
Community of practice Framework
Design metaphor for engagement or facilitation
Assessment optional. Evaluation/assessment of performance for a variety of perspectives and purposes.
Inspiring reflection through
Shared view of the action with images/sound Background with teacher's view; student's views; materials; institutional 'stage'
Support materials
Indexing and databasing of examples
Units of practice that support the video examples
Different “characters” talk from their Points of View
7. "System" box?
Ans. The system box only appears on the top-level diagram (remember that a typical UML Use Case description will be composed of many diagrams and sub-diagrams), and should contain use case ovals, one for each top-level service that your system provides to its actors. Any kind of internal behavior that your system may have that is only used by other parts of the system should not appear in the system box. One useful way to think of these top-level services is as follows: if a use case represents a top-level service, then it should make sense for the actors who interact with it to request only that service of your system in a single session (in whatever sense a "session" is intelligible in your system.)
8. What is a UML Use Case Diagram (UCD), and when should I use it?
Ans. In software and systems engineering, a use case (pronounced /juːs/, a case in the use of a system) is a list of
steps, typically defining interactions between a role (known in UML as an "actor") and a system, to achieve a goal.
The actor can be a human or an external system.
In systems engineering, use cases are used at a higher level than within software engineering, often representing
missions or stakeholder goals. The detailed requirements may then be captured in SysML or as contractual
statements.
History
In 1986 Ivar Jacobson first formulated textual, structural and visual modeling techniques for specifying use cases. In
1992 his co-authored book[1] helped to popularize the technique for capturing functional requirements, especially in
software development. Originally he used the terms usage scenarios and usage case – the latter being a direct
translation of his Swedish term användningsfall – but found that neither of these terms sounded natural in English,
and eventually he settled on use case.[2] Since then, others have contributed to improving this technique, notably
including Alistair Cockburn.
[edit]Use case structure[edit]Martin Fowler
Martin Fowler states "There is no standard way to write the content of a use case, and different formats work well in
different cases."[3]:100 He describes "a common style to use" as follows:[3]:101
Title: "goal the use case is trying to satisfy"[3]:101
Main Success Scenario: numbered list of steps[3]:101
Step: "a simple statement of the interaction between the actor and a system"[3]:101
Extensions: separately numbered lists, one per Extension[3]:101
Extension: "a condition that results in different interactions from .. the main success scenario". An
extension from main step 3 is numbered 3a, etc.[3]:101
[edit]Alistair Cockburn
Alistair Cockburn describes a more detailed structure for a use case, but permits it to be simplified when less detail is
needed. His "fully-dressed" use case structure is:[4]:9-10
[edit]Fully dressed use case structure
Cockburn's Fully dressed use case template lists the following fields:[5]
Title: "an active-verb goal phrase that names the goal of the primary actor"[6]
Primary Actor
Goal in Context
Scope
Level
Stakeholders and Interests
Precondition
Minimal Guarantees
Success Guarantees
Trigger
Main Success Scenario
Extensions
Technology & Data Variations List
Related Information.
In addition, Cockburn suggests using two devices to indicate the nature of each use case: icons for design scope and
goal level.
Cockburn's approach has influenced other authors; for example, Alexander and Beus-Dukic generalize Cockburn's
"Fully dressed use case" template from software to systems of all kinds, with the following fields differing from
Cockburn:[7]
Variation scenarios "(maybe branching off from and maybe returning to the main scenario)"
Exceptions "i.e. exception events and their exception-handling scenarios"
[edit]Casual use case structure
Cockburn recognizes that projects may not always need detailed "fully-dressed" use cases. He describes a Casual
use case with the fields:[5]
Title (goal)
Primary Actor
Scope
Level
(Story): the body of the use case is simply a paragraph or two of text, informally describing what happens.
[edit]Design scope icon
Cockburn suggests annotating each use case with a symbol to show the "Design Scope", which may be black-box
(internal detail is hidden) or white-box (internal detail is shown). Five symbols are available:[8]
Organization (black-box), a filled icon of a house
Organization (white-box), an unfilled icon of a house
System (black-box), a filled icon of a box
System (white-box), an unfilled icon of a box
Component, an icon of a screw or bolt.
Other authors sometimes call use cases at Organization level "Business use cases".[9]
[edit]Goal level icon
Cockburn suggests annotating each use case with a symbol to show the "Goal Level";[10] the preferred level is "User-
goal" (or colloquially "sea level"[3]:101).
Very high summary, an icon of a cloud
Summary, an icon of a flying kite
User-goal, an icon of waves at sea
Subfunction, an icon of a fish
Too low, an icon of a seabed clam-shell.
[edit]Actors
A use case defines the interactions between external actors and the system under consideration to accomplish a
goal. Actors must be able to make decisions, but need not be human: "An actor might be a person, a company or
organization, a computer program, or a computer system — hardware, software, or both."[11] Actors are
always stakeholders, but many stakeholders are not actors, since they "never interact directly with the system, even
though they have the right to care how the system behaves."[11] For example, "the owners of the system, the
company's board of directors, and regulatory bodies such as the Internal Revenue Service and the Department of
Insurance" could all be stakeholders but are unlikely to be actors.[11]
Similarly, a person using a system may be represented as different actors because he is playing different roles. For
example, user "Joe" could be playing the role of a Customer when using an Automated Teller Machine to withdraw
cash from his own account, or playing the role of a Bank Teller when using the system to restock the cash drawer on
behalf of the bank.
Actors are often working on behalf of someone else. Cockburn writes that "These days I write 'sales rep for the
customer' or 'clerk for the marketing department' to capture that the user of the system is acting for someone else."
This tells the project that the "user interface and security clearances" should be designed for the sales rep and clerk,
but that the customer and marketing department are the roles concerned about the results.[12]
A stakeholder may play both an active and an inactive role: for example, a Consumer is both a "mass-market
purchaser" (not interacting with the system) and a User (an actor, actively interacting with the purchased product).
[13] In turn, a User is both a "normal operator" (an actor using the system for its intended purpose) and a "functional
beneficiary" (a stakeholder who benefits from the use of the system).[13] For example, when user "Joe" withdraws
cash from his account, he is operating the Automated Teller Machine and obtaining a result on his own behalf.
Cockburn advises to look for actors among the stakeholders of a system, the primary and supporting (secondary)
actors of a use case, the system under design (SuD) itself, and finally among the "internal actors", namely the
components of the system under design.[11]
[edit]Use case notation
In the Unified Modeling Language, the relationships between all (or a set of) the use cases and actors are
represented in a Use Case Diagram or diagrams, originally based upon Ivar Jacobson's Objectory notation. SysML,
a UML profile, uses the same notation at the system block level.
[edit]Limitations
Limitations of Use cases include:
Use cases are not well suited to capturing non-interaction based requirements of a system (such as
algorithm or mathematical requirements) or non-functional requirements (such as platform, performance, timing,
or safety-critical aspects). These are better specified declaratively elsewhere.
Use case templates do not automatically ensure clarity. Clarity depends on the skill of the writer(s).
Use cases are complex to write and to understand, for both end users and developers.
As there are no fully standard definitions of use cases, each project must form its own interpretation.
Some use case relationships, such as extends, are ambiguous in interpretation and can be difficult for
stakeholders to understand.
In Agile, simpler user stories are preferred to use cases.
Use case developers often find it difficult to determine the level of user interface (UI) dependency to
incorporate in a use case. While use case theory suggests that UI not be reflected in use cases, it can be
awkward to abstract out this aspect of design, as it makes the use cases difficult to visualize. In software
engineering, this difficulty is resolved by applying requirements traceability, for example with a traceability matrix.
Use cases can be over-emphasized. Bertrand Meyer discusses issues such as driving system design too
literally from use cases, and using use cases to the exclusion of other potentially valuable requirements analysis
techniques.[14]
Use cases are a starting point for test design, [15] but since each test needs its own success criteria, use
cases may need to be modified to provide separate postconditions for each path.[16]
12.What is a UML Use Case Diagram (UCD), and when should I use it?
UML Use Case Diagrams can be used to describe the functionality of a system in a horizontal way. That is, rather than merely representing the details of individual features of your system, UCDs can be used to show all of its available functionality. It is important to note, though, that UCDs are fundamentally different from sequence diagrams or flow charts because they do not make any attempt to represent the order or number of times that the systems actions and sub-actions should be executed. There are a number of graphical examples in this FAQ; you might want to look over them to familiarize yourself with the look of them.
UCDs have only 4 major elements: The actors that the system you are describing interacts with, the system itself, the use cases, or services, that the system knows how to perform, and the lines that represent relationships between these elements.
You should use UCDs to represent the functionality of your system from a top-down perspective (that is, at a glance the system's functionality is obvious, but all descriptions are at a very high level. Further detail can later be added to the diagram to elucidate interesting points in the system's behavior.) Example: A UCD is well suited to the task of describing all of the things that can be done with a database system, by all of the people who might use it (administrators, developers, data entry personnel.)
You should NOT use UCDs to represent exception behavior (when errors happen) or to try to illustrate the sequence of steps that must be performed in order to complete a task. Use Sequence diagrams to show these design features.Example: A UCD would be poorly suited to describing the TCP/IP network protocol, because there are many exception cases, branching behaviors, and conditional functionality (what happens when a packet is lost or late, what about when the connection dies?) 13. How is a UML Use Case Diagram different from a traditional flow chart?
As mentioned above, UCDs represent functionality in a top-down way, whereas flow charts represent behavior in a linear, time-based way. Also, the way you develop them is all-together different.
Example: (This text refers to the diagrams below.) When constructing a UCD, the initial step is to identify all of the top-level behavior. Once you have done this (not a very tricky process) you have already described, at least in a high-level way, all of the things your system knows how to do. You can then continue to add detail by decomposing your use cases into more use cases which are used by the top-level use cases. At every stage of development, though, your UCD is a complete description of the system's functionalty: it may lack detail, but it will not lack feature set elements. And if functionality or behavior is added or deleted over the life of your project, the scope of the change you need to make is proportional to both the scope of the change in the system itself, and the maturity of your model. This is useful because it means that when your model is very young (only high-level diagrams drawn) making sweeping changes to the system does not involve throwing very much work away. A flow chart, however, does not correctly describe the system until you have finished drawing it, and even then small changes in the system will result in significant reworking of your flow charts. In general, UCDs support the process of analysis and design much better than flow charts.
15. UML stands for Unified Modeling Language which is used in object oriented software engineering. Although typically used in software engineering it is a rich language that can be used to model an application structures, behavior and even business processes. There are 14 UML diagram types to help you model these behavior. They can be divided into two main categories structure diagrams and behavioral diagrams. All 14 UML diagram types are listed below with examples, brief introduction to them and also how they are used when modeling applications.List of UML Diagram TypesTypes of UML diagrams with structure diagrams coming first and behavioral diagrams starting from position 8. Click on any diagram type to visit that specific diagram types description.
1. Class Diagram 2. Component Diagram 3. Deployment Diagram 4. Object Diagram 5. Package Diagram 6. Profile Diagram 7. Composite Structure Diagram 8. Use Case Diagram 9. Activity Diagram 10. State Machine Diagram 11. Sequence Diagram 12. Communication Diagram 13. Interaction Overview Diagram
14. Timing Diagram
16. Structure diagrams show the things in a system being modeled. In a more technical term they show different objects in a system. Behavioral diagrams shows what should happen in a system. They describe how the objects interact with each other to create a functioning system.Class diagrams are arguably the most used UML diagram type. It is the main building block of any object oriented solution. It shows the classes in a system, attributes and operations of each class and the relationship between each class. In most modeling tools a class has three parts, name at the top, attributes in the middle and operations or methods at the bottom. In large systems with many classes related classes are grouped together to to create class diagrams. Different relationships between diagrams are show by different types of Arrows. Below is a image of a class diagram. Follow the link for more class diagram examples.
UML Class Diagram with Relationships
A component diagram displays the structural relationship of components of a software system. These are mostly used when working with complex systems that has many components. Components communicate with each other using interfaces. The interfaces are linked using connectors. Below images shows a component diagram.
Simple Component Diagram with Interfaces
A deployment diagrams shows the hardware of your system and the software in those hardware. Deployment diagrams are useful when your software solution is deployed across multiple machines with each having a unique configuration. Below is an example deployment diagram.
UML Deployment Diagram ( Click on the image to use it as a template )
Object Diagrams, sometimes referred as Instance diagrams are very similar to class diagrams. As class diagrams they also show the relationship between objects but they use real world examples. They are used to show how a system will look like at a given time. Because there is data available in the objects they are often used to explain complex relationships between objects.
UML Object Diagram Example
As the name suggests a package diagrams shows the dependencies between different packages in a system. Check out this wiki article to learn more about the dependencies and elements found in package diagrams.
Package Diagram in UML
Profile diagram is a new diagram type introduced in UML 2. This is a diagram type that is very rarely used in any specification. For more detailed technical information about this diagram type check this link.
Basic UML Profile Diagram structure
Composite structure diagrams are used to show the internal structure of a class. For a detailed explanation of composite structure diagrams click here.
A simple Composite Structure Diagram
Most known diagram type of the behavioral UML diagrams, Use case diagrams gives a graphic overview of the actors involved in a system, different functions needed by those actors and how these different functions are interacted. It’s a great starting point for any project discussion because you can easily identify the main actors involved and the main processes of the system. Click through to read more about use case diagram elements and templates.
Use Case diagram showing Actors and main processes
Activity diagrams represent workflows in an graphical way. They can be used to describe business workflow or the operational workflow of any component in a system. Sometimes activity diagrams are used as an alternative to State machine diagrams. Check out this wiki article to learn about symbols and usage of activity diagrams.
Activity Diagrams with start, end, processes and decision points
State machine diagrams are similar to activity diagrams although notations and usage changes a bit. They are sometime known as state diagrams or start chart diagrams as well. These are very useful to describe the behavior of objects that act different according to the state they are at the moment. Below State machine diagram show the basic states and actions.
State Machine diagram in UML, sometime referred to as State or State chart diagram
Sequence diagrams in UML shows how object interact with each other and the order those interactions occur. It’s important to note that they show the interactions for a particular scenario. The processes are represented vertically and interactions are show as arrows. This article explains thepurpose and the basics of Sequence diagrams.
Sequence Diagrams in UML shows the interaction between two processes
Communication diagram was called collaboration diagram in UML 1. It is similar to sequence diagrams but the focus is on messages passed between objects. The same information can be represented using a sequence diagram and different objects. Click here to understand the differences using an example.
Communication Diagram in UML
Interaction overview diagrams are very similar to activity diagrams. While activity diagrams shows a sequence of processes Interaction overview diagrams shows a sequence of interaction diagrams. In simple term they can be called a collection of interaction diagrams and the order they happen. As mentioned before there are seven types of interaction diagrams, so any one of them can be a node in an interaction overview diagram. ( img – http://www.sa-depot.com/?page_id=645 )
Interaction overview diagram in UMLTiming diagrams are very similar to sequence diagrams. They represent the behavior of objects in a given time frame. If its only one object the diagram is straight forward but if more then one objects are involved they can be used to show interactions of objects during that time frame as well. ( img –http://blog.tangcs.com/2008/01/10/uml-2-diagrams/ )
Timing Diagram in UML
Mentioned above are all the UML diagram types. The links given in each section explains the diagrams in more detail and covers the usage, symbols etc. UML offers many diagram types and sometimes two diagram can explain the same thing using different notations.Check this blog post to learn which UML diagram best suits you.If you have any questions or suggestions feel free to leave a comment.
11. Case methodThe case method is a teaching approach that consists in presenting the students with a case, putting them in
the role of a decision maker facing a problem (Hammond 1976). The case method overlaps with the case
study method, but the two are not identical.[1]
Case studies recount real life business or management situations that present business executives with a dilemma or
uncertain outcome. The case describes the scenario in the context of the events, people and factors that influence it
and enables students to identify closely with those involved
The case method is a teaching method that is largely used in business schools. For instance it was used at
the Harvard Business School since the founding of the school in 1908 (Corey 1998).
Teaching cases
Teaching cases are available through clearing repositories such as the Caseplace and European Case
Clearing House, or through professional writing and publishing centers, such as Globalens at the University of
Michigan.
Teaching case studies, and to a lesser extent writing them, is a central function performed at the top business
schools worldwide. Some organizations, such as European Case Clearing House and GlobaLens, run
competitions to identify the best new teaching cases. Some of the institutions that are the most active at writing
teaching cases (as determined by the quantity and quality validated by awards) are: Harvard Business
School, IESE, the Darden School at the University of Virginia, University of Michigan Ross School of
Business (through Globalens, INSEAD, Richard Ivey School of Business, the Asian Institute of
Management, Indian Institute of Management, Ahmedabad and Asian Case Research Centre at the University
of Hong Kong.
A business case is a document that illustrates a business or policy situation to be solved and includes
information for classroom discussion and other study. The situation does not have an obvious solution. The
case provides information to stimulate an educated conversation concerning possible outcomes. Each case
has one central decision point, dilemma, or angle. The nature of the situation is clearly apparent within the first
two paragraphs.
The writing in a case is precise and nuanced, yet always clear and concise. It is neither colloquial nor stuffily
formal. It is also engaging and interesting to the reader. It is imperative for a case writer to always be objective
—a case is not a marketing pamphlet for the featured organization, though the writer may portray biases that
the protagonist may have.
Structure
Writing styles may be unique to the individuals developing a case, yet almost every successful case employs
the following structure:
Title and Introduction (½-2 pages)
For the title, in fewer than 10 words make clear what is special about this particular case.
Within the first paragraph, identify the case’s central person and business or organization, and provide
a sense of the situation the person is in.
Within the first two paragraphs, present what the central person sees as the decision point or dilemma.
Identify other major players if relevant.
In the remainder of the introduction, provide the context for the situation: when the situation took place
(at least the year), the location and purpose of the company or organization, the relevant important
business factors, and the goal or aim of the central person.
[edit]Background on the Company, Industry and Competitors (3-7 pages)
Begin this section with the first subhead. If the section is long or relatively complex, use more than one
subhead within the section to organize separate aspects.
Often the best method for writing this section is to organize the information chronologically, with a very
brief history of the company or organization.
Provide the essential company, organization, competitor, and/or industry information that the central
person had at the time of the case. What and where are the major products or services and their
customers?
Include enough background information for the reader to analyze the decision point presented in the
introduction. Revenues, profits and losses, and other financial valuations may be crucial.
Do not simplify or weight the background section to lead students to an easy decision.
Include, as appropriate, historical information, trends, direct quotations from participants and analysts,
and simple and/or essential tables and figures. The section can also include references to exhibits placed
in the appendix, though the references should be clear and complete enough that the reader can continue
without having to turn immediately to the exhibits.
Consider depicting the culture of the company or organization if relevant.
What are the important challenges and responsibilities of the central person?
Are certain portions of the person’s career particularly important to the current situation?
Connect the background in this section to the current situation, including underlying causes and
current results.
[edit]The Decision Point in More Detail (1-5 pages)
Begin this section with a subhead. Within it, use more subheads if appropriate.
Go more deeply into the context and possible consequences of the decision point, dilemma or central
angle. Include the consequences for the career of the central person as well as for the person’s company
or organization.
Show, if true, how the decision point or dilemma differs from the one initially perceived.
Include the degree of urgency involved in the decision-making, or the timeline for the decision to be
made.
Conclude the text with alternatives available to the central person.
[edit]Exhibits and Endnotes (4-10 pages)
Use a subhead before any exhibits and before any listing of endnotes. Use a small title with each exhibit,
beginning “Exhibit 1:” Exhibits can include financial statements, time lines, diagrams, charts, tables, pictures,
and graphs. In some cases it is possible to include or link to multimedia supplements such as an interview
video with the case’s central person. An endnote is needed for anything mentioned in the text for which a
reasonable reader would want to know the source of the assertion, quotation, or apparent fact. The endnotes
are referred to by number in the text and the notes themselves appear in order, all together, after the exhibits.
An exhibit can have an endnote or its sourcing can appear as part of the exhibit.
More information is available on How to Write a Case Study.
8. A quick guide to five common color terms your clients may not fully understand.
Color terminology helps designers and decorators accurately share their vision with clients before it comes into existence. But even the most basic terms are often misunderstood by clients and even by some designers. Words that have a very specific meaning in color theory can have much broader, more nebulous meaning in the average person's mind. So being sure your client understands what you mean when you're describing a color scheme can be a tricky proposition.
Here's a handy glossary defining five of the most common – and most commonly misused – color terms: tint, shade, tone, value and saturation.
Tint.Put simply, a tint is a lighter variation of a color. Tints are created by adding white to colors. For example, pink is a tint of red. A commonly held meaning of this word is to add color to something (blue-tinted hair), so it's important to be clear with clients that the color-theory meaning is quite different.
Shade.A color made darker by adding black to it. Navy is a shade of blue. This word is routinely used to describe any variation of color, even much lighter ones — take for example the 1960s song "A Whiter Shade of Pale" — so some clients may not understand that shades are darker than the base color.
Tone.If gray is added to a color, a tone of that color is created. Tones are generally more muted versions of colors. Clients sometimes refer to grayer versions of colors as “tints” or “shades,” a distinction not widely known outside the art and design communities.
Value.This term describes the lightness or darkness of a color. Colors with more white (tints) have higher value, and darker colors (shades) have lower value. It's a very helpful term when describing the possibilities of color, but you'll want to explain it clearly to clients.
Saturation.The purity or intensity of a color is called saturation. The most-saturated colors are vivid and strong, where less-saturated colors can appear washed out or muted. Gray has zero saturation. The quality of light can affect saturation; for example, a painted wall's color can appear more saturated during the day and less so as the light fades, and different types of artificial light can enhance or diminish saturation.