To deliver agile outcomes, you have to do more than implement an agile process; you have to create a culture of experimentation. It's this commitment to experimenting that's at the heart of a high-functioning practice of agile. This course shows you how to integrate the practice of experimentation across concept/feature testing, usability testing, and testing the software itself. Basically, you’ll learn how to answer these four big questions with experiments: 1. Should we build it? 2. Did it matter? 3. Is it usable? 4. Did it break? More specifically, after completing this course, you’ll be able to: - Identify where and how to invest your team’s scarce time and energy into better testing for maximum impact on outcomes - Coach your team on the relationship between idea, usability, and software testing to get the buy-in you need for strong interdisciplinary collaboration - Test ideas before you build them to avoid waste and help your team focus on what will really drive outcomes - Test alternative interface patterns before you build them to maximize both product usability and purposeful implementation As a Project Management Institute (PMI®) Registered Education Provider, the University of Virginia Darden School of Business has been approved by PMI to issue 20 professional development units (PDUs) for this course, which focuses on core competencies recognized by PMI. (Provider #2122) This course is supported by the Batten Institute at UVA’s Darden School of Business. The Batten Institute’s mission is to improve the world through entrepreneurship and innovation: www.batteninstitute.org.
The Importance of Comparables and Prototyping
Loading...
来自 University of Virginia 的课程
Testing with Agile
229 个评分
从本节课中
Is it usable?
The best products are tested for usability early and often, avoiding the destructive stress and uncertainty of a ‘big unveil’. In this module, you’ll learn how to diagnose, design and execute phase-appropriate user testing. The tools you’ll learn to use here (a test plan template, prototyping tool, and test session infrastructure) are accessible/teachable to anyone on your team. And that’s a very good thing- often products are released with poor usability because there ‘wasn’t enough time’ to test it. With these techniques, you’ll be able to test early and often, reinforcing your culture of experimentation.
与讲师见面
Alex CowanFaculty & Batten Fellow
Darden School of Business
You saw how to think through usability in a systematic way
using Donald Norman's seven steps and one of the big punchlines there was,
use well understood cognitive models of how a user will approach your interface.
So, here we're going to talk about comparables and proto-typing.
So you'll learn how to identify comparables and translate them forward
into prototypes that you can use for better discussions with your team,
and testing your ideas before you implement them at very high costs in the software.
Before we start, let's just talk about why it's important to prototype.
The cost of your software as you get to lots of users it's very expensive to change,
so, if you're in the early phases of a project,
play to your strengths at this phase and prototype a lot,
it is a great investment in building more valuable software at a very low cost.
So, how do you do this? Should you just start
sketching staff for making things in balsamic?
You can and that's fine.
But I highly recommend asking yourself this question about
what pattern might my user be expecting to see here to do this jobs,
to execute on this narrative that they already are familiar with?
So, what functional things have they used that they might
encounter here and find appropriate signifiers,
if you will from the Donald Norman material,
for the actions at hand?
The best way to do that is don't reinvent the wheel,
the wagon wheel so to speak,
go and find patterns.
So, this is a set of pattern libraries that you can check and if you're serious,
you should research at least two maybe three sets of
distinct different patterns because you don't want to just go to one thing,
and one's better than zero,
but two or three will really help you unlock
the potential of you and your team to arrive at the right interface.
So, let's go back to this epic story of Ted the HVAC technician and HVAC in a hurry,
and how he wants to identify a part so he can figure out his next steps and replace it,
so, we need to know the availability and the price of that part.
Now, for this interaction we have nothing built yet,
what are some ideas about what is a comparable site,
it doesn't need to have anything to do with HVAC necessarily,
what are some comparable types of sites or
applications that the HVAC in a Hurry team might go
and look at to think through patterns that might be appropriate for this task?
Take a moment and think about that.
So here are a few ideas from me because this
is a real example
that's really relevant things happening in the real world, but it's a fake company.
One is online shopping.
So, there we have the pattern of where we go and we're looking to buy something and we
may have a very specific idea about what we want in very specific terms to describe it,
or we may have very general terms like
when the HVAC technician doesn't really know what the part is,
where we want to filter down
from a few different options to something that we actually want,
so that maybe this is good.
Used car purchase is a similar type of thing.
I want a certain cars,
certain price in a nearby me,
but this one has a little more structure, so,
I thought this might be a good counterpoint to
the broader patterns that we might observe in e-commerce.
Photo search is another one.
If we find that a very visual search test well with our users,
then maybe sites where people look for photos or look
at photos for enjoyment might be a good thing,
and they maybe want to look at some just general record search applications, so,
gmail where we're looking for a particular email,
or a CRM system where we're looking for a particular customer case or something,
these might have some things that are worth looking at as well.
So, as you can see the point here is to go broad,
think about a lot of areas not necessarily topically related to your area.
So, here's an example of some stuff the team might
look at and pull if they were interested in this online shopping comparable,
and you can see they hypothetically looked at a lot of
different sites and how they approach the same thing.
So, you can see here these are all results of search for iPhone charger,
and it's interesting to see how these different sites and these
pattern libraries approach that.
So, we have a few different sites that actually sell these things that we looked at,
and then a pattern page ui-patterns
which is quite good where we look at a couple of distinct thing.
So, product page pattern that they have in
a table filter pattern that they have because we
identified that those are elements of these sites that are interesting,
and here's a little bit of a bigger view of how this might look
on how this looks on Amazon, this particular search.
Now, the right answer is not to just look at a particular site,
a larger site and say, "Oh!
Well," just because they do it,
that must be the right way to approach this general thing.
A site like Amazon,
or Walmart.com, or jet.com,
they do things because they've learned that it works well for their user experience,
their infrastructure, their big picture which is not your big picture.
So, it's important to look at these very atomically.
So, for instance, oh,
how do they deal with the job of showing multiple views of the same thing?
Or how do they sort results and allow you to modify your search?
You will see commonalities across similar types of sites that will tell you,
well, this is what a user is going to expect to see.
Another example is sites where we have automobiles for sale,
where we might look at how we could search for a car and the way that that would work,
and how the similar types of searching, and filtering,
and looking at a set of results how that
is approached by these different types of sites that sell cars.
So, maybe the team find some things
there that have more structure, that are more applicable.
Here is a prototype that draws very broadly
on e-commerce metaphors and used car search metaphors.
You can see that it has this simple search here for search by part number for
this part of our child story that has
this more structured search for when we know something about what we want,
but not everything, and then we have this other metaphor for
this kind of unique thing with the HVAC technicians have where they might upload a photo.
Now, this is one concept and I mentioned you should do at least two concepts,
you should look at at least two sets of comps and you should
consequently draft at least two different concepts from those camps,
those two or three or four sets of comps you look at.
So, this is how a product search might look after we initiate the search,
this is what the results might look at,
and this is the search parameters.
So, we've looked for an Acme,
Coolerator and it's the part type Sniggler,
and we can modify the search,
and we can look at these results.
Maybe the team finds that, hey,
actually the metaphor of sorting by most popular
is actually a really relevant thing for us
because an HVAC technician is
probably most likely to want to order what everybody else is ordering,
so, we'll sort initially by popularity,
how often things are ordered.
This is what a product detail page might look like for this kind of last step where they
can actually place the order and see what the arrival time is.
Then here's a totally different set of patterns for photo search, so,
these are places where we're searching for a car,
but on a photo site like Flickr, or Instagram,
or maybe Google Images,
and we see a really different prototype that is inspired by this photo search metaphor.
So, here we have a more general search,
we can still modify the search parameters,
we're sorting by popularity,
but as you can see a set of results are much more visual,
we roll over to see the details about them,
so this is a second concept.
What will be our next step will be to test these with actual users,
here's a different detail page for that second concept.
Brand lattice is another example I'll quickly show you,
is a product I worked on with some collaborators a couple of years ago.
This is a mood board for
graphic designers to go through a quick brand strategy exercise with their customers.
So, this is what the application more or less looks like.
Now, when we started, we knew well,
we need a sequential process because
the the mood boarding processes you pick certain images and
then you get a filtered set of words that you can pick from,
and all these things relate to each other.
So, we looked at these Wizard patterns where you can see you go through step one,
step two, step three here.
So, we looked at various travel booking sites
where you would go through and book a flight, and hotel,
and a this and that,
and sites where you would buy insurance,
you need to go through and put all this information in sequentially.
That's how we came up with this early version of what the site might look like,
and we refine these by testing them with users,
and seeing the results, and we ultimately arrived at the thing that you see here.
So, you've seen some ideas on how do you prototype?
How do you build meaningful prototypes you can see shortly
how to actually test these ideas with the users,
so that your diverging and you're creating a lot of
possibilities that may result in really high usability?
The biggest trick here is to make sure
you don't fall into the trap of thinking that you're going to predict
the user's behavior ahead of time because
nobody can do that with any kind of reliability.
So, look at well understood patterns that the user is likely to understand,
think about how you might render those into prototypes,
and then move on to actually test those with the user,
that's how you get your cheapest and best usability outcomes.
