Product UI/UX : How a product takes shape

PRODUCT UI/UX
HOW A PRODUCT TAKES SHAPE
Amanjot Malhotra
@amanmalhotra911
1

2
DESIGNING UI/UX BRANDING DEVELOPMENT MARKETING STARTUPS
ACTIWATE
Visit www.actiwate.in for any requirements or mail at info@actiwate.in

METHODS USED
3
1. REQUIREMENTS 2. BRAINSTORMING 3. DELIVERY
— Service Blueprint
— Consumer Journey Map
— Personas
— Ecosystem Map
— Stakeholders Interviews
— Storyboards
— Value Proposition
— Sitemap
— Features Roadmap
— Use Cases and Scenarios
— User Flow
— Usability Testing
— A/B Testing
— Wire-framing
— Prototyping

SERVICE BLUEPRINT
5
1. A map that displays all the touchpoints of the consumer
with your brand, as well as the key internal processes
involved in it.
2. Useful to visualize the path followed by consumers
across multiple channels and how you could improve
the flow.
3. The traditional blueprints –as they are used in
disciplines like architecture, product design and
engineering- are instruments for building,
standardizing, communicating, planning and sharing
the project.
4. While, if we think at how the blueprints are used in
service design, we can notice that they give just partial
representation of how a service works: they provide a
detailed visualization of the actions and processes,
without looking at the motivational and emotional sides.
5. The solution proposed improves this aspect By adding
more layers of information inside the diagram, like the
emotions line and the color-coded emotional states.

CONSUMER JOURNEY MAP
6
1. The customer journey map is an oriented graph that
describes the journey of a user by representing the
different touchpoints that characterize his interaction
with the service.
2. In this kind of visualization, the interaction is described
step by step as in the classical blueprint, but there is a
stronger emphasis on some aspects as the flux of
information and the physical devices involved.
3. At the same time there is a higher level of synthesis
than in the blueprint: the representation is simplified
trough the loss of the redundant information and of the
deepest details.
4. A blank journey worksheet and a set of cards
representing the touchpoints are needed to set the
ground for the activity
5. The cards provide a visual support that facilitate
understanding and assembling the sequence of
activities and touchpoints that characterize the service
experience.

PERSONAS
7
1. From all over the techniques and tools related to
design process and User experience, only personas
appears as a consistent common denominator, even in
methods against the use of extensive “deliverables” as
Lean UX.
2. Most of the point of view agree in that the secret of a
great user experiences strategy lies on this tool, even
so the building process varies significantly.
3. Probably the most important reason to create personas
is to set a common understand of the final user. So that
a coherent strategy is defined that will result in a
product/service that is user oriented and meet the user
goals.

ECOSYSTEM MAP
8
1. A visualization of the company’s digital properties, the
connections between them, and their purpose in the
overall marketing strategy. Gives you insights around
how to leverage new and existing assets to achieve the
brand’s business goals.
the flow.
the project.

STAKEHOLDERS INTERVIEW
9
1. Scripts for interviewing key stakeholders in a project,
both internal and external, to gather insights about their
goals. It helps prioritize features and define key
performance indicators (KPIs).
the flow.
the project.

CHECK-LIST
10
— PROJECT VISION
1. What is your vision for this offering?
2. What defines success for this project?
3. What are the potential pitfalls (i.e. what keeps you up
at night about this project)?
— USERS
1. Different types of users (salesperson vs supervisor vs
analyst)
2. Who is primary?
3. Role(s)?
4. Typical Background?
5. Defining Attribute?
— VALUE PROPOSITION
1. What problems do users have that this offering
solves?
2. What is the core value prop of the offering?
3. What are the main marketing messages?
— COMPETITION
1. What similar tools are in use today?
2. Target Market? Value Proposition?
3. What are their relative strengths/weaknesses?
4. How is this offering different?
— YOUR CUSTOMERS
1. Target market(s)?
2. What role is your team selling to?
3. What problem do they have that their offering solves?
4. Who is their competition?
5. How are they differentiated?

CHECK-LIST
11
— PROCESS & WORKFLOW (example questions here
for a Salesperson role)
1. What is the nature between the salesperson and their
customer?
2. How does the salesperson know when it is time to
engage with a customer? Are there multiple types of
engagements? Are there other key patterns (e.g.
cyclical patterns, size of company, level of customer
savvy-ness, industry, etc.)
3. How do they prepare? How do they work with? What
tools do they use?
4. How do they engage? What is the first step? And the
next (and so on)? How does the engagement end?
5. What frustrations/ pain points do they experience with
their current process?
— CONTEXT OF USE
1. What tools do they use today? Where do those tools
fit? (collect screenshots, printouts, any relevant
articles if possible)
2. What data points do they collect today? What insight
are they able to share with customers today? How do
they share it? What does it look like?
3. What’s missing in the current process that this tool will
provide?
4. Where do you imagine your new (or redesigned)
offering will fit?
— USER GOALS
1. What defines success? (if an experience goes well,
what happens, commission? bonus?)
2. What are bad results? (If an experience doesn’t go
well, what happens?)
3. If users had a “magic wand” and could wish for
anything to make the process better, what would they
wish for?

STORY BOARDS
13
1. A comic strip that illustrates the series of actions that
consumers need to take while using the product.
Translates functionalities into real-life situations,
helping designers create empathy with the consumer
while having a first look at the product scope.
the flow.
the project.

VALUE PROPOSITION
14
1. A reductive process in the early stages of product
definition that maps out the key aspects of it: what it is,
who it is for and when/where it will be used. Helps the
team narrow down and create consensus around what
the product will be.
2. When you’re starting a new project or a new company
you need quick and dirty tools to help you focus on
executing things faster and better. Good strategy tools
exist only to help you focus on getting the right things
done. The value proposition canvas is a simple tool
that quickly gets you to the ‘minimum viable clarity’
required to start building and testing.
3. The value proposition sits at the pivot point of the entire
business model. Mapping the business model of a new
product or service is one of the most important parts of
building a business strategy. Strategy frameworks have
traditionally been the domain of MBAs but they are so
important that these days the tools have been
democratized for use by entrepreneurs, designers and
technical teams.

SITEMAP
15
1. One of the most iconic IA deliverables, consists of a
diagram of the website’s pages organized
hierarchically. It makes it easy to visualize the basic
structure and navigation of a website.
2. They show how the navigation should be structured
3. They help identify where content will sit and what
needs to be produced
4. They help show the relationship between different
pages
5. They provide a structure upon which to begin estimates
for development
6. They are the first tangible deliverable showing what
you will be creating
Reference : http://www.thedesigngym.com/service-design-blueprint

FEATURES ROADMAP
16
1. A product’s evolution plan with prioritized features. It
could be a spreadsheet, a diagram or even a bunch of
sticky notes. Shares the product strategy with the team
and the road that needs to be taken to achieve its
vision.
2. Think of your roadmap as a strategic communication
document. Its purpose is to show your team and other
stakeholders what your product vision is and what the
high-level initiatives will be to get there. It’s not a
device for showing off every last nook and cranny of
your development plan, and doesn’t need to include
your list of specific bugs or minor features you want to
get out the door.
3. Now, realistically, as a product manager, you probably
do have a list of bugs and little items that need to be
addressed and moved through development. This is
fine, but remember that at that point (when you’re
helping the development team move items in and
through their Kanban/Sprint/Backlog/whatever), you’re
playing the role of a project manager or product owner
rather than the product manager. The roadmap is a
product management document and should live
separately.
4. Leave out the dates. You don’t know what the expected
delivery dates are for anything that goes beyond a
couple weeks – i.e. the length of a sprint, or however
long ahead your team specifically plans out as a
distinct project or deliverable – and so you shouldn’t
fake it! Putting a date on a roadmap, even if it’s vague
like ‘Q3 2016’, will more often than not end up setting
expectations you don’t deliver on and cause undue
stress and finger-pointing among various stakeholders.
While ideally, as the awesome product manager that
you are, you’d like to think that you can put a rough
estimate on something and stick to it, your estimates
suck (from a great book called Rework I recommend
everyone reads!). You don’t know what bugs are going
to creep up and change your plans, and even if you
did, by the time you get to ‘Q3 2016’, your product
strategy might need to adapt and change based on
what’s going on in the market, your users, your
competition, etc.

USE CASES AND SCENARIOS
17
1. A comprehensive list of scenarios that happen when
users are interacting with the product: logged in, not
logged in, first visit etc. Ensures that all possible
actions are thoroughly considered, as well as the
system behavior in each scenario.
2. Use cases are necessary, due to the fact that they will
demonstrate how systems react when they are utilized.
A use case describes how a system helps a user
achieve their objective. Unlike a user scenario, a use
case is more orientated to the system’s habits instead
of the user. The language in which a use case is
composed will be basic and the writer of a use case
must avoid technical terminology. A use case will not
consist of too much context about the user or their
emotional feedback to an interaction.
3. Use cases are necessary, due to the fact that they will
demonstrate how systems react when they are utilized.
A use case describes how a system helps a user
achieve their objective. Unlike a user scenario, a use
case is more orientated to the system’s habits instead
of the user. The language in which a use case is
composed will be basic and the writer of a use case
must avoid technical terminology. A use case will not
consist of too much context about the user or their
emotional feedback to an interaction.
4. What is even more intriguing is what make use of
stories in the specification. These consist of non-
functional requirements– there is no organized ways of
recording quality requirements in user tales. One issue
is that numerous quality requirements are revealed at a
system level. It begs the question where crucial quality
requirements can be specified. User tales are
developed not to include requirements of behavior.
5. This needed habits is intended to arise from
communication in between users and designers. Also
there are no characteristics of the specified system
recorded. The various other vital requirements aspect
that is not documented straight in user stories is the
quantifiable fit requirements

USER FLOW
19
1. A visual representation of the user’s flow to complete
tasks within the product. It’s the user perspective of the
site organization, making it easier to identify which
steps could be improved or redesigned.
2. Flows are just as important to good interfaces as
individual screens are. Customers don’t land on
screens from out of nowhere. Specific sequences of
actions lead customers through your app as they try to
accomplish their tasks.
3. But as important as they are, flows are hard to
communicate during the design process. Drawing out
every state of a flow is too time-consuming. And
drawings become instantly outdated as screens
change. On the other extreme, flows written down into
stories or paragraphs are hard to reference and they
don’t easily decompose into checklists for design and
review.
4.

USABILITY TESTING
20
1. One-to-one interviews in which the user is asked to
perform a series of tasks in a prototype or a product.
Validates and collects feedback of flows, design and
features.
2. One of the best parts about this kind of testing is that it
can be done with almost anything, from concepts
drawn on the back of napkins to fully functioning
prototypes. Steve Krug recommends testing things
earlier than we think we should and I agree – get out of
the building as soon as possible.
3. Test what the product could be so as to shape what the
product should be. Even loosely defined UI sketches
can be a great way to evaluate a future product. In fact,
recent research shows that lower-fidelity prototypes
can be more valuable concerning both high and low-
level user interactions.
4. Where we conduct tests affects how we perform and
document our work. For instance, if we’re testing a new
mobile app for a retail chain, we might go to the store
itself and walk the aisles; if we’re working on “general”
office software, we might test it with coworkers in a
different part of the office; etc. The point is: let context
drive the work.

A/B TESTING
21
1. At its core, A/B testing is exactly what it sounds like:
you have two versions of an element (A and B) and a
metric that defines success. To determine which
version is better, you subject both versions to
experimentation simultaneously. In the end, you
measure which version was more successful and
select that version for real-world use.
2. This is similar to the experiments you did in Science
101. Remember the experiment in which you tested
various substances to see which supports plant growth
and which suppresses it. At different intervals, you
measured the growth of plants as they were subjected
to different conditions, and in the end you tallied the
increase in height of the different plants.
3. A/B testing on the Web is similar. You have two designs
of a website: A and B. Typically, A is the existing design
(called the control), and B is the new design. You split
your website traffic between these two versions and
measure their performance using metrics that you care
about (conversion rate, sales, bounce rate, etc.). In the
end, you select the version that performs best.

A/B TESTING – HOW ITS DONE
22
— What To Test?
— Your choice of what to test will obviously depend on
your goals. For example, if your goal is to increase
the number of sign-ups, then you might test the
following: length of the sign-up form, types of fields in
the form, display of privacy policy, “social proof,” etc.
The goal of A/B testing in this case is to figure out
what prevents visitors from signing up. Is the form’s
length intimidating? Are visitors concerned about
privacy? Or does the website do a bad job of
convincing visitors to sign up? All of these questions
can be answered one by one by testing the
appropriate website elements.
— Even though every A/B test is unique, certain
elements are usually tested:
1. The call to action’s (i.e. the button’s) wording, size,
color and placement
2. Headline or product description,
3. Form’s length and types of fields,
5. Product pricing and promotional offers,
6. Images on landing and product pages,
7. Amount of text on the page (short vs. long).
— Create Your First A/B Test
— Once you’ve decided what to test, the next step, of
course, is to select a tool for the job. If you want a
free basic tool and don’t mind fiddling with HTML and
JavaScript, go with Google Website Optimizer. If you
want an easier alternative with extra features, go with
Visual Website Optimizer (disclaimer: my start-up).
Other options are available, which I discuss at the end
of this post. Setting up the core test is more or less
similar for all tools, so we can discuss it while
remaining tool-agnostic.
— You can set up an A/B test in one of two ways:

A/B TESTING – HOW ITS DONE
23
1. Replace the element to be tested before the page
loads. If you are testing a single element on a Web
page—say, the sign-up button—then you’ll need to
create variations of that button (in HTML) in your
testing tool. When the test is live, the A/B tool will
randomly replace the original button on the page with
one of the variations before displaying the page to the
visitor. The call to action’s (i.e. the button’s) wording,
size, color and placement etc.
2. Redirect to another page, if you want to A/B test an
entire page—say, a green theme vs. a red theme—
then you’ll need to create and upload a new page on
your website. Form’s length and types of fields.
3. Once you have set up your variations using one of
these two methods, the next step is to set up your
conversion goal. Typically, you will get a piece of
JavaScript code, which you would copy and paste
onto a page that would represent a successful test
were a visitor to arrive there. For example, if you have
an e-commerce store and you are testing the color of
the “Buy now” button, then your conversion goal would
be the “Thank you” page that is displayed to visitors
after they complete a purchase.
4. As soon as a conversion event occurs on your
website, the A/B testing tool records the variation that
was shown to the visitor. After a sufficient number of
visitors and conversions, you can check the results to
find out which variation drove the most conversions.
That’s it! Setting up and running an A/B test is indeed
quite simple.

A/B TESTING – DO`S
24
1. Know how long to run a test before giving up. Giving
up too early can cost you because you may have
gotten meaningful results had you waited a little
longer. Giving up too late isn’t good either, because
poorly performing variations could cost you
conversions and sales. Use a calculator (like this one)
to determine exactly how long to run a test before
giving up.
2. Show repeat visitors the same variations. Your tool
should have a mechanism for remembering which
variation a visitor has seen. This prevents blunders,
such as showing a user a different price or a different
promotional offer.
3. Make your A/B test consistent across the whole
website. If you are testing a sign-up button that
appears in multiple locations, then a visitor should see
the same variation everywhere. Showing one
variation on page 1 and another variation on page 2
will skew the results.
4. Do many A/B tests. Let’s face it: chances are, your
first A/B test will turn out a lemon. But don’t despair.
An A/B test can have only three outcomes: no result,
a negative result or a positive result. The key to
optimizing conversion rates is to do a ton of A/B tests,
so that all positive results add up to a huge boost to
your sales and achieved goals.

A/B TESTING – DON`TS
25
1. When doing A/B testing, never ever wait to test the
variation until after you’ve tested the control. Always
test both versions simultaneously. If you test one
version one week and the second the next, you’re
doing it wrong. It’s possible that version B was
actually worse but you just happened to have better
sales while testing it. Always split traffic between two
versions.
2. Don’t conclude too early. There is a concept called
“statistical confidence” that determines whether your
test results are significant (that is, whether you should
take the results seriously). It prevents you from
reading too much into the results if you have only a
few conversions or visitors for each variation. Most
A/B testing tools report statistical confidence, but if
you are testing manually, consider accounting for it
with an online calculator.
3. Don’t surprise regular visitors. If you are testing a
core part of your website, include only new visitors in
the test. You want to avoid shocking regular visitors,
especially because the variations may not ultimately
be implemented.
4. Don’t let your gut feeling overrule test results. The
winners in A/B tests are often surprising or unintuitive.
On a green-themed website, a stark red button could
emerge as the winner. Even if the red button isn’t
easy on the eye, don’t reject it outright. Your goal with
the test is a better conversion rate, not aesthetics, so
don’t reject the results because of your arbitrary
judgment.

WIREFRAMING
26
1. A visual guide that represents the page structure, as
well as its hierarchy and key elements. Useful to
discuss ideas with team members and clients, and to
assist the work of designers and developers.
drive the work.

USES OF WIREFRAMES
27
— Wireframes may be utilized by different disciplines.
Developers use wireframes to get a more tangible
grasp of the site’s functionality, while designers use
them to push the user interface (UI) process. User
experience designers and information architects use
wireframes to show navigation paths between pages.
— Business Analysts use wireframes to visually support
the business rules and interaction requirements for a
screen.
— Business stakeholders review wireframes to ensure
that requirements and objectives are met through the
design. Professionals who create wireframes include
business analysts, information architects, interaction
designers, user experience designers, graphic
designers, programmers, and product managers.
— Working with wireframes may be a collaborative effort
since it bridges the information architecture to the
visual design. Due to overlaps in these professional
roles, conflicts may occur, making wire framing a
controversial part of the design process. Since
wireframes signify a “bare bones” aesthetic, it is
difficult for designers to assess how closely the
wireframe needs to depict actual screen layouts.
— To avoid conflicts it is recommended that business
analysts who understand the user requirements,
create a basic wire frame and then work with
designers to further improve the wireframes. Another
difficulty with wireframes is that they don’t effectively
display interactive details because they are static
representations.
— Modern UI design incorporates various devices such
as expanding panels, hover effects, and carousels
that pose a challenge for 2-D diagrams.
— Wireframes may have multiple levels of detail and can
be broken up into two categories in terms of fidelity, or
how closely they resemble the end product.

WIREFRAMING – LOW FIDELITY
28
1. Resembling a rough sketch or a quick mock-up, low-
fidelity wireframes have less detail and are quick to
produce. These wireframes help a project team
collaborate more effectively since they are more
abstract, using rectangles and labeling to represent
content.
2. Dummy content, Latin filler text (lorem ipsum), sample
or symbolic content are used to represent data when
real content is not available.is: let context drive the
work.

WIREFRAMING – HIGH FIDELITY
29
1. High-fidelity wireframes are often used for documenting
because they incorporate a level of detail that more
closely matches the design of the actual webpage, thus
taking longer to create.
2. For simple or low-fidelity drawings, paper prototyping is
a common technique. Since these sketches are just
representations, annotations—adjacent notes to
explain behavior—are useful. For more complex
projects, rendering wireframes using computer
software is popular.
3. Some tools allow the incorporation of interactivity
including Flash animation, and front-end web
technologies such as, HTML, CSS, and JavaScript.

PROTOTYPING
30
1. One-to-one interviews in which the user is asked to
perform a series of tasks in a prototype or a product.
Validates and collects feedback of flows, design and
features.
drive the work.

REFERENCES
31
— https://uxdesign.cc
— http://www.wireframeshowcase.com/
— http://uxmag.com/
— http://theuxreview.co.uk/
— http://www.ixda.org/
— http://www.mindtheproduct.com/
— http://ux.walkme.com/
— https://uxapprentice.wordpress.com
— http://www.uxbooth.com/
— https://www.smashingmagazine.com
— http://www.wired.com/
— https://signalvnoise.com
— http://cognition.happycog.com/
— http://www.uxapprentice.com/
— http://boxesandarrows.com/
— http://www.ux-lady.com/
— http://www.thedesigngym.com/
— http://www.servicedesigntools.org/
— http://www.storyboardthat.com/

THANK YOU!
QUESTIONS?
32
amanmalhotra911 @amanmalhotra911 amanmalhotra911@gmail.com

Product UI/UX : How a product takes shape

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (15)

Similaire à Product UI/UX : How a product takes shape

Similaire à Product UI/UX : How a product takes shape (20)

Dernier

Dernier (20)

Product UI/UX : How a product takes shape