Transcripts
1. Welcome to the class!: Hi, and welcome to the course on service design prototypes. My name is Thibault
Dubois and I'll be your instructor throughout
the remainder of the course. Now, before you commit, you might want to know
what my credentials are, which is totally understandable. I am a manager in one of the largest consulting
companies in the world. I'm active as a consultant in business analysis
and service design. I have been applying
service design in many high profile projects, especially in the
financial sector. I helped major banks in designing and implementing
complete new offerings for the customers using a service design mindset and
service design techniques, which I would love to share
with you during this course. In terms of Academical record, I hold to master decrease, one in financial economics and another one in general,
business management. On top of that, I also holds
certifications related to service design such
as design thinking. This is story mapping, agile scrimp, and
data analytics. So with this side of the way, you might want to know
what's in it for you. After you have
completed this course, you will acquire
everything there is to know about service
design prototypes. Prototypes are a
very powerful tool within service design. They help us to
explore, evaluate, and communicate service
ideas in a quick, low risk and cheap way. During this course,
we will go over the service design
prototypes benefits there building blocks. There characteristics,
the pros and cons of high and low
fidelity levels. And we'll finish it all
with a real-world use case. You also have access to
the handouts and templates and my expertise in case you have questions about the course. Please note that this course
is part of a larger series. We also cover other
courses on service design, where we tackled topics like service design
fundamentals and patterns, personas, customer journey maps, service design, blueprints, etc. should definitely check
those out as well. If you'd like to
content of this course, the link should be
in its description. Normally. Who is this course for? It's basically for
anybody looking to start a position as
a service designer, a business analyst,
business consultant, product manager, product owner, or even a UX designer. Experienced professionals
are looking to strengthen their knowledge. You should not go anywhere
because you're welcome to. But that's enough from me. Now it's your turn to, if you feel that this course
is something for you, then please hop on board. And if not, maybe next time. In any case, I wish you a wonderful and educational
and I hope to see you soon. Bye
2. Introduction to user prototypes: Hi, and welcome to this section on service
design prototypes. Let me first explain what a service design prototype is and why it's
handy to have them. Service design prototypes create a first or early form of
the cervix experience. They aim to stage and experience all process regarding
a certain part of the customer experience. Prototypes come in
many shapes and forms. You can have a
storytelling session, a quick step-by-step
walk-through, a complex simulation with
multiple stakeholders or a more in-depth theat,
theatrical rehearsal session. I personally am
more at home with prototypes of digital artifacts, such as mock-ups, wire-frames, click models, proof-of-concept,
or even pilots. You also have to
know that prototypes often have different
levels of fidelity. By fidelity, I'm referring
to how closely the prototype approximates the real
end solution boost likely at the beginning
of the project, the surface assigned
team will start with a low fidelity prototype just to test out their
ideas and concepts. And as more or less known
about the customer experience, the level of fidelity will increase and you
will end up with something that closely
resembles the final product. These are so-called high
fidelity prototypes. In this section, we will go in more detail on the
following topics. Understand why there is
a need for prototypes. Recognize the building blocks
of a digital prototype. Know what characteristics to consider when
building a prototype. Knowing the pros
and cons between low and high
fidelity prototypes. And get some insights into
a practical use case from my professional experience and also to build your own prototype and the context of a project. Now, why do we need to have prototypes
in the first place? I have listed a
few reasons here. Prototypes aim to study how customers or other
stakeholders to and experience things and how they behave in New
service situations. Specifically, they address
how things should be done differently and experienced
differently in the future. Prototypes, how the design
team to explore, evaluate, and communicate
service ideas during different activities within
the service design process. By engaging with
prototypes to design team can quickly identify
important aspects of a new concept
and then explore different alternative
solutions and evaluate which ones
might work in reality. Additionally, prototypes
can be used as a communication tool to
enhance collaboration and to present or persuade or inspire other stakeholders
within the organization. Prototypes are also a way
to capture business and user requirements and are just quite handy for
business analysts. And finally, prototypes
are also used as input for an elicitation
technique called prototyping. Prototyping is a user
base experimental process where design teams implement IDEs into tangible forms of varying degrees of fidelity
called prototypes. And that's the introduction
on prototypes. In the next lecture, we will go over the
building blocks. Live to see you there. Bye
3. The building blocks: Hi, and welcome to
this lecture on building blocks of
digital prototypes. Like I said before, I'm more at home
with prototypes of digital artifacts compared to
actual physical prototypes. This is because of my professional
experience, experience, which is mainly focused on digital transformation
in the financial sector, you will most likely
encounter prototypes of digital artifacts in
software or web development. Prototypes can have many
forms such as scribbles of an interface to fully fledged wireframes of
the final screens. It really depends on
what you want to test. You might also be happy
to learn that creating digital artifact
prototypes is no longer limited to people with
technical expertise. Prototyping software has evolved over the past few
years to allow anybody with adult training to use prototyping tools and create low and high
fidelity prototypes. Sketch Adobe, Figma, envisioned studio might
be some names that you might have heard of now
onto the building blocks. The first one is the display
area of the prototype. This represents the display
of the future device, like the screen of a
smartwatch, smartphone, a tablet, a computer
or other device. In our case, I'm using a
smartphone as a display. Next, there is the screen. This is the Canvas where contents and interactive
elements are placed. Multiple screens are
created and linked together using interaction elements
like hotspots or buttons. When clicked or
tabbed, the display simply switches to
another screen. In more elaborate prototypes, screens can also contain layers to model more complex behaviors. In our case, the screen is the full white background
within the display. Moving on now to the
interaction elements. These are placed onto a screen. Come now elements include visible navigational or
interactive elements like buttons, links, sliders, input
fields, and so on. Interactive prototypes
of touch interfaces might also involve gestures, invisible hotspots, or
other ways of interaction. I have included a next button
and the back button as a typical interaction elements which you will encounter
in many flows. And the roadblock is
the content elements. Content elements are placed
onto the display area. They allow the subject matter
content to be filled in, usually true traditional
texts elements like headings, sub-headings, textboxes,
images, audio, or video. Content elements also
include labels used for interaction elements
like defining the language on buttons or
other navigational elements. Using actual data copy
diagrams, visualizations, or food material can
make a huge difference, as opposed to just
using a sample content and should be tested
as early as possible. And additional building block is the structure and flow
of the prototype. This building block
covers how the screens or different elements of an interface are
linked together. It allows us to
figure out the flow of single features or the
overall user experience. This includes the discussion of the underlying information
architecture and Data Model. As inflexible data models are information architecture can create barriers for
the future vision of a digital product. I will show you an example in
the case in point section. It's all become
more clear there. Up next, we have the
function of a prototype. This part defines
what it can do or what's selected audience
can do with the prototype. It is closely tied to the interactive and
content elements. The available functions
in a prototype might be real,
simulated, or faked. In proof of principle prototypes only key functional
aspects are prototypes, while a working prototype already tries to capture most of the functionality of the
final artefact or software. Functional prototypes
are built to assess feasibility
and experience experiential aspects and help to evaluate guesstimate
necessary effort. In the example that you
can see on the slide, the video function is
disabled in a prototype, but the common section isn't. In some clickable prototypes
such as envision, you can just click
somewhere to see what parts of the
prototype or functional and which aren't there then highlighted with a
light blue color. Of course, we can't forget
about to look and feel. This part is important as it adds aesthetics
and experience to the visible or
perceptible elements and transitions
are of the system. Does Tetris on overall
style, the layout, a key graphics, key imagery, color schemes and patterns, as well as wider aspects like balanced proportion or emphasis of the individual elements, or timing and responsiveness. Early look and feel prototypes
might be very similar to mood boards when trying to capture a direction with
the perspective slides, playfulness, gravity,
lightness, or emotions. I haven't added any
graphical elements in this prototype as it's not necessarily needed at
early stage of Prototyping. In addition, I'm
not a UI designer, so nothing good would
come out of me trying to create something
graphically appealing. The last building
block is media. Prototypes of digital artifacts. And software can be created
in different media. Early prototypes often
use pen and paper. They're easy to work with and do not require
specialized knowledge. More evolved prototypes use specialized digital
prototyping tools like page-based or layer based
prototyping environments. Alternatively, the one
code can be used to assess design questions in different environments
or stacks. From exploring different
toolchains early in the process, to running experiments on feasibility in the
actual development and test environments, or even in the production
of the systems. Here are some of
the on the site you can see some of the
tools that also mentioned earlier that sits regarding the building blocks. In the next lecture,
we will cover four important prototype
characteristics to take into account
when creating them. Hope to see you there. Bye
4. The characteristics: Hi and welcome back. As explained in
previous lecture, I would like to share with
you for characteristics to take into account when
creating your own prototype. You can define the
characteristics of your prototype by asking yourself the
following questions. First, what's the purpose
of the prototype? Then, who will use the
prototypes and in what context, who is the origins? Then? What methods will you use
to create a prototype? And finally, what is the level
of detail that's required? What fidelity level do you need? Prototype. Let's start with
the first characteristic, the purpose of the prototype. Here we need to ask ourselves, what do we want to
learn using it? A tip that I can give you
here is to first write down all the assumptions
that you took when defining the
expected experience. And then to create a
testable hypothesis which can be validated using a prototype in a
controlled environment. Here's an example of how you can write a purpose for
your prototype. First, you need to
define the hypothesis. An example could be, can customers easily find the entry points or feature
X in a banking app? Next, you have to define how you will measure that hypothesis. A qualitative user test
with card sorting of different entry points could do the trick and measuring
customer's preference. And finally, we need to figure
out how we will build it. An example can be a high fidelity wireframe for the specific feature
that you want to test. Note that you don't always need a prototype to test
an assumption. An example of an hypothesis
that doesn't require any prototype to be tested
goes as follows. A other people interested in a solution that drives up
their matches on Tinder. We measure, we could
measure this with the number of sign-ups
for a newsletter. And we can build it
using a landing page, but with a subscription
letter and some Google ads. So no need to have any prototype to test
out that hypothesis. Moving on now to the next
characteristic which was about the audience and the
context of the prototype. It's a conscious choice when
and where prototypes are used or run and who is also experiencing
them to get feedback. For example, do you
want to simulate a prototype in your
actual environment with real customers
at a peak period, for instance, what
do you prefer to run a prototype in a
safer environment with internal colleagues, the results might
be quite different. In software development,
people talk about the production environment
versus the QA environments. Qa stands for Quality Assurance. The first one is the environment with
the actual customers, and the latter is
the environment that mimics the production
environments. It's okay to try
and break things in the QA because it won't
impact actual customers, but you don't want anything to break into production
environment. So this will also
impact the type of hypotheses that you
want to test out. Then there is a question
of the audience which is also closely connected
to the fidelity. For example, low levels of fidelity will often require
an audience that is accustomed to reading
conceptual prototypes that are not focusing
on every little detail. Also, even though early
prototypes are often created and used in
designs to do I, contextual prototypes
that are run at home with customers on the work
floor or on the go, should be considered
as early as possible. The more closely
that the prototype is run into realistic
environments, the more relevant the
feedback will be. Moving on now to the
method characteristic. Prototypes can be created with many different methods
or techniques. Well-known methods include
paper prototyping, cardboard prototyping, or
theoretical techniques. Prototyping methods replace actual implementation techniques during the design task to allow us to create faster and cheaper and to
maximize your learning. Or simply because we might not know yet how to
implement it all. The precise form and
shape of a prototype also depends on what you
actually need to test. All these methods come
down to the same, which is to ensure that we built the right thing
in the right way. And finally, we have
the fidelity level. After prototype. You
have to know that prototypes come in
many different forms. Stage subsidy refinements
and levels of detailed. Depending on the purpose
and prototyping questions, prototypes might be
more rough or polished. We call this, as I said before, the level of fidelity. Examples of lower
fidelity prototypes include desktop wild, choose to explore essential
steps in a customer journey. Cardboard prototypes to get a first idea about the
shape of a future product or sketches on
paper to visualize the early stages of a
digital user interface. Examples of
higher-fidelity prototypes could include
contextual simulations, are pilots to test technical
feasibility aspects. You can also consider
3D prints or immersive digital 3D models to evaluate a detailed
look and feel. Or you could also even
consider the actual code, which is already Closing the Gap towards the
final implementation. That's it for the
prototype characteristics. In the next section, we
will dive a little deeper into pros and cons of the low and high
fidelity prototypes. I hope to see you there. Bye
5. Pros and cons of fidelity levels: Hi and welcome back. In this lecture, I would like to go into a bit more detail around the pros and cons of low and high
fidelity prototypes. Let's start with the
high-fidelity prototypes that very closely resembled
the final solution. What are the pros? It presents a complete
functionality to the customer. There isn't much room for
image for interpretation. Then these type of prototypes are often highly interactive. This is especially the case
with clickthrough models. Prototypes are built
with the user in mind. Users should have
an easy time to use a prototype is something
is wrong or unclear. It's not the users folds. Rather, it means that to prototype still need
some more work. These types of
Prototypes also already present a fleshed-out
information architecture. So the findability of new
features can also be assessed. It's also a very rich
source of requirements. You can use high fidelity
prototypes to list all the requirements
that you see an enrich it if you see
any type of cap. It can also be used as input for commercial campaigns and
other marketing efforts. These type of Prototypes easily lend themselves to
usability testing. It also provides a
very good picture of the solution which makes it easy to use in discussions with all
kinds of stakeholders, such as business, legal
developers, etcetera. It's also easy to identify
areas of improvement. They can be used in user
tests where you can already collect feedback
early on the solution. This will also highlights less obvious areas of improvements like
unforeseen user behavior, user disability issues, etc. and last but not least, it allows for rapid trial and
error at a very low cost. Moving on now to the cons of
high fidelity prototypes, there are often costly
your and take more time to make compared to their
lower fidelity prototypes. You might receive feedback
during user tests on superficial details
rather than on the inherent aspects
of the solution. You also need to
have some skills and prototyping software
to create them. Stakeholders and
developers might confuse prototypes with the final
solution and start to form. There are some assumptions
based on that. And sometimes there's a
mismatched attachment to the prototype which could
interfere with making changes. People start to
believe in the dream. Let's now go over the pros
of low fidelity prototypes. It can be done at
almost no cost. There is no need for
any special skill for in prototyping software. You can get feedback
from users very quickly. It's best fitted to test
concepts and ideas. It allows for very rapid
trial and error and it helps to structure discussions
with users and stakeholders. And to conclude, let's now
move to the low fidelity cons. There's a limited check
on possible errors. Error flows like unhappy flows. It's not easy to
start coding to. You can't just give
it to developers as too much information
is lacking for them. These prototypes
are often open to interpretation and generate
irrelevant discussions. Another good input for generating user
requirements as well, due to the leg of detail, it's not possible
to do any type of usability testing as
the graphical side of the prototype is
not sufficiently developed and it's too far removed from
the final product. And the lack of realism
could tamper with the elicitation results
as you might not get. User feedback. Follow. I hope you now have a good
view on what the strengths and weaknesses are for
each fidelity level is. The next section, I
will walk you through a low fidelity prototype
that I made for the client. It was about creating a signature pattern for
all types of sales flows. But more on that then.
See you there. Bye
6. Bonus lecture! How to conduct prototyping? : Hi and welcome back. In this lecture
we'll be covering an experimental elicitation
technique called prototyping. What exactly is Prototyping? To begin with? Prototyping is a user-based experimental
process where design teams implement IDEs into
tangible forms of varying degrees of fidelity
called prototypes. Now, what's that based? Let's go to the different
parts of this definition. The first characteristic
that we encounter is user-based prototyping
isn't elicitation technique where the user is central. Prototypes are updated, adapted, transformed based on
what users experience and say when using
the prototype. The next characteristic that we encounter is
experimental process. This points towards
the fact that Prototyping is not a
one-shot exercise. You do prototyping on an incremental and
iterative basis until you have a prototype that perfectly matches what's your
customers or users want. Prototyping is inherently a
process of trial and error. The very course that you
are following now has been following an
experiential process. It is being updated
constantly based on the feedback that I receive
from you, the users. So please don't forget
to leave a review. Furthermore, I would
like to highlight the design teams characteristic. This can be a little misleading as you might think that only user experience designers
are doing prototyping. That is of course not true. Everybody who is creating
a new product or service can be considered
to be a designer. That's can be an architect,
a product manager, a data analyst and
operational engineer, a business analysts,
etcetera, etcetera. Then we have implement
IDEs into tangible forms. This now is the essence
of Prototyping. You want to create a
proxy of the product or service so that you can
test it with users. Many great products have
been created that way. Dropbox is a good example. In the beginning, they were testing the concept of Dropbox, true a janitor
type of prototype. This means that the
users who are testing out the functionalities
of the product when it was actually
a human behind the scenes that
execute it tasks. So users were giving feedback on Dropbox functionalities
and not a single line of code was written yet. That way Dropbox was able to capture customer feedback very, very early in the
development process. Lastly, we have degrees
of varying fidelity. You need to know that
there are multiple types of prototypes that
you have to consider. These types distinguished
themselves based on how closely they mimic
the final product. This is called prototypes
level of fidelity. Let's look closer at
the two extremes, low fidelity prototypes and
high fidelity prototypes. Low fidelity prototypes are a very simple and limited
version of the solution. Think of prototypes made on a piece of paper like
a comic, for instance. Will often find
these prototypes in the early stages of software
development lifecycle, where the concept is
tested as a whole. On the other hand, you have
high fidelity prototypes. These type of
prototypes are already closer to what the actual
solution should look like. Think of software
generated wireframes, which are actual screens
of the solutions interface with the right colors, labeling, information
architecture, and so on. The only thing that's different
from the real solution that is that there is no
code behind the screens. You will often find
these type of prototypes towards the later stages
of development lifecycle. When should you use prototyping? Quite frankly, in a world that's revolves around
customer centricity, I would always use prototyping whenever building or updating
a product or service. It's a cheap and
quick way to see if what you're building is the right thing
for your users. So the question is really, why wouldn't you use it? Moving on with the questions on how to execute Prototyping. Creating the prototyping itself falls outside the scope of this course as we are
only interested in the elicitation technique
link to prototyping, which is user testing. You might be happy
to learn that you already know this
technique as it is very similar to the
user review workshop, which you can find in the
Interface analysis part. So I invite you to
rewatch that lecture if you're unsure about
the execution steps. Moving on now to our
trusty pros and cons, I will especially zoom
on the pros and cons of low fidelity versus
high-fidelity prototypes. Starting with the
pros of low fidelity, it can be done at
almost no cost. There is no need for any skills. In prototyping software. You can get feedback from
users with very quickly. It's best to, its best fitted
to test concepts and IDs. It always, it allows for
very rapid trial and error and it helps to structure discussions with
users and stakeholders. Now, moving on to the low
fidelity disadvantages, the lack of realism linked could tamper with the
elicitation results. As you might not get
relevant users feedback, they could start filling in the gaps with their
own imagination. So to say, there is the
issue of oversimplification. So some aspects of
the prototype might actually not be
possible to develop. There is also the lack
of actual interactions with the limits of the
elicitation results. Next step, we have the high-fidelity
prototypes that very closely resembled
the final solution. What are its pros? It's a very rich source
of requirements. You can use high-fidelity
prototypes to list all the requirements
that you see. An enrich it if you find gaps. It provides a very good
picture of the solution, which makes it easy to use in discussions with all
kinds of stakeholders, such as your business
stakeholders, legal and compliance developers, user designers, etcetera. It allows for rapid trial
and error at a low cost. It can be used in user
tests where you can already collect feedback
early on on the solution. This will also highlight less obvious areas
of improvements, such as unforeseen
user behavior, user usability issues, etc. and to conclude, what
are some of the cons linked to high
fidelity prototypes? The first one is that
it's often costly or, and it takes more time to make than low fidelity prototypes. You might receive feedback
during user tests on superficial details rather than on the inherent aspects
of the solution. You need to have some skills for the prototyping
software to create a prototype and stakeholders. And also developers might confuse the prototype
with the final solution and actually go ahead
and start to form their assumptions based on
that and even develop it. And the last column I can think of is that
there is sometimes a misplaced attachment to the prototype which could
interfere with making changes. Remember, you need to fail fast, it's trial and error. Don't attach yourself
to the prototype. Regarding best practices, I again advise you
to have a look at a user review workshop in the lecture on
Interface analysis. Voila. This concludes the
lecture on Prototyping, and it also concludes this section on requirement
elicitation techniques. If you want me to cover other
elicitation techniques, don't hesitate to let me know. I will gladly cover
them as well. The next section we will cover the next step in our
elicitation journey, which is confirming
your understanding. So confirming what you, the information that you
just conducted through all these nice techniques.
I hope to see you there. Bye
7. Case in point: Hi, and welcome to
our case in point. In this lecture, I would
like to walk you through a concrete use case of a prototype that I
created for the clients. It was a low fidelity
prototype that I made to test out
a concept around new and transversal
signature patterns inside the banking
mobile application. Before proceeding, It's
important to first go over the characteristics that
are prototype should have. The questions you
need to answer our, What's the purpose
of the prototype? Who will use your prototype
and in what context? Then, what is the method for
the prototype to create it? And then lot finally, what is the expected
level of detail? What is the fidelity level? Regarding the first question around to prototypes purpose, I defined a hypothesis, a way to measure it,
and how to build it. In. My hypothesis
goes as follows. The signature pattern
both provides app users a quick overview of what
they're about to sign, while also offering
them a way to review the documents in detail. This pattern can be applied to any type of signature flow. The elements that I wanted to measure where the customers raw, unfiltered feedback on the
structure of the flow. I wanted to know what their
thoughts were on first having a overview screen with
what we're about to sign, and then the documents screen, which they will
probably not read. This is for different
signature flows to see whether to pattern could be applied
transversely over them. And regarding the building
of the prototype, I made a mockup screens
using PowerPoint. Next, there's a question about the audience and the context. The only requirement I had with my audience was that
they had to understand the concept of a
mock-up and that they are able to provide feedback on a high level concept
and not just give feedback on
superficial elements. Then the methods that
are used towards a one-on-one interview with actual users of the bank's
mobile application. I presented them the mockup, and I had a list of open
questions regarding the overall information
architecture and some functionality
questions. And finally, there's the
question of fidelity. Given that this was
just an early concept, I was more interested
in receiving feedback on the ad then on the
actual look and feel. So a low fidelity concept was more than enough
to start with. Let's now move to the actual building
blocks of the prototype. When it comes to display. As you can see, I did not bother with a
smartphone or layout. I was confident that the
testers were mature enough to understand that the rectangles respected representatives
smartphone display. Next, there is discrete. So remember that this
is the Canvas where content and interactive
elements are placed. You should not place
any of these elements outside the screen as this
could confuse to test her. Moving on now to the
interaction elements. These are the
pinkish arrows that you either split into float. They indicate which
elements the user can interact with and where they would go if they
clicked on them. The interaction elements keep the screens together and
create a flow in it. In our case, the
interaction elements are mixture between
navigation buttons, downloadable documents,
an opt-in checkbox, and a numpad for
entering a pin code. The content elements
are a bit harder to spot because they are fully integrated
within the screens. Here's a small summary
of the content elements. First, for all screens
you have the header, the titles, and the
restriction texts. Then for the overview screen, you have the labels and values of what you're
about to sign. Next for the document screen, you have documents
that you need to read, the documents that
you need to sign, and the legal declarations
at the bottom of the screen. Next, we have the
secretory screen, which basically
holds the numpad, which is an
interaction elements. And finally, we have the
confirmation screen, which holds a success icon
and the success text. Let's now take a look
at the flow structure. It should be quite clear that
a user that the flow of, of screens is defined by the navigation buttons on the bots on the
bottom of the screen. First, the user reviews what
he or she is about to sign. Next, the user lands on the
document screen where he or she sees a part with the
documents that need to be red. And then the documents that
symbols normally sign. The first set of documents
are purely informational. The user has to provide his or her consent to proceed
to the signature screen. In the signature screen, the user needs to use
this mobile banking apps for number code
to sign the documents. I could have included
biometrics signatures as well, like fingerprint or Face ID, but these were
seen as not secure enough to sign these
type of documents. So pin code it was. And finally, the user lands
on the confirmation screen after successfully signing the documents in the
previous screen. From there, the user can either close flow and go to
the start page of the mobile application or go to the documents that he
or she just signed. What about a
function components? In this use case, there was not really a specific
function I want to test. I just wanted to have feedback from the user on
what they saw on discrete IF function
that could be tested in future prototypes is
downloading the documents, inserting the right pin code, leaving and coming back
to the flow, etcetera. It's prototype is too limited to test out a real functionality. As for the graphics, there is not much
to say because it's a low fidelity prototype where graphics and
not so relevant. In high-fidelity
prototypes, however, you want the graphics
to be very similar, if not completely similar
to the final product. You want to test usability
of the prototype as well. This is because graphics of the user interface
matter a lot more. And finally, we have the media or prototyping
environments. This was done without using any specialized
prototyping software. I simply use PowerPoint, which is perfectly
fine to test out ideas and conceptual
assumptions. By the way, I wouldn't want
to spend too much time on graphics because it wasn't relevant to the hypothesis
that I wanted to test. And the first place,
there you have it. With this prototype,
I was able to quickly test out my assumptions
with actual customers. And now it's your turn. I would like you to define
a prototype on your own using the same approach
that I just showed you. Your first have to define the characteristics of
your prototype and then created using the
building blocks that we covered in the
previous lecture. Here's a short list
of categories and examples from which you
can draw some inspiration. I thought about
Prototyping the concept of a Tetris game or the prototype
of the computer mouse. I thought about the prototype for the concept of an elevator, or go further into sports with
the concept of ping-pong. You're really free in what type of prototype
you want to create. These are just some
examples to get you started. That's it from me. I wish you good luck
with the assignment. If you're stuck,
don't hesitate to let me know and we'll have
a look at it together. I hope to see you in the final section where we will cover some of the key takeaways. See you there. And good luck with
the assignment by
8. Key takeaways: Hi, and congratulations
for finishing this section on service
design prototypes. Let's quickly go over some
of the key takeaways. Shall we? Service prototypes, create a first or early form of the servers or the
surface experience. They aim to stage
and experience or process regarding a certain part of the customer experience. Prototypes of digital artifacts have multiple building blocks, which are the display, the screen, the
interaction elements, the content elements,
structure and flow, function, look and feel, the media and prototyping
and environments. You also have to take into account to prototypes,
characteristics, which are purpose,
audience, methods, and fidelity level.
And that's it. This concludes this
section on Prototypes. I would urge you to always think of ways to prototype
your designs so that you can test them as
quickly as possible in a controlled or real
life environment. The amount of information
you get out of this is well-worth the time and effort
of creating a prototype. The only thing that's left
for me to do is to wish you a wonderful and
educational day. Bye
9. Share your thoughts: Hi Thibault here. Congratulations for
finishing the course. I hope you've got
something out of it and it will be helpful in
your future career. In case you'd like to course, please leave a review and let others know what
you liked about it. That seems extremely
helpful to meet, and it's also helpful
for other students. Now, I'll, if I go have a
nice and educational day, Bye
Thibault Dubois, Manager in business consulting
