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 - Understand your delivery pipeline and how to prioritize process and infrastructure improvements so you can deliver faster and more often 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
197 个评分
从本节课中
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.
And so here we're going to talk about comparables and prototyping.
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 cost 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 stuff or making things in Balsamiq?
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 job and
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?
And 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.
And so let's go back to this epic story of Ted the HVAC
technician at HVAC in a Hurry, and how he wants to identify a part so
he can figure out his next steps and replace it.
So he needs to know the availability and the price of that part.
[COUGH] 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 HVACs 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 what we go and we're looking to buy something and
we may have a very specific idea about what we want and
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.
And used car purchase is kind of a similar type of thing.
I want a certain car, a certain price, nearby me, but
this one has a little more structure.
So I thought this might be a good kind of counterpoint to the sort of broader
patterns that we might observe in ecommerce.
Photo search is another one.
I mean, if we find that a very visual search tests well with our users,
then maybe sites where people look for photos or look at photos for
enjoyment might be a good thing.
And then maybe we want to look at some like just general record search
application.
So like 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 approached the same thing.
So you can see here these are all results of a search for iPhone charger.
And it's kind of 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, this site UI-Patterns,
which is quite good where we look at a couple of distinct things.
So a product page pattern that they have and a table filter pattern that they have,
because we identified that those are elements of
these sites that are interesting.
Here's a little bit of a bigger view of 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 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, 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 finds some things there that have more structure,
that are more applicable.
Here is a prototype that kind of draws very broadly on ecommerce metaphors and
used car or car search metaphors.
And you can see that it has this sort of simple search here for
search by part number for this part of our child story.
Then it 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 that 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 comps,
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 the what the results might look at and this is the search parameters.
So we've looked for an Acme Coolerator, and it's a 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.
And 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 sort
of 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, this set of results are much more visual.
We roll over to see the details about them.
So this is a second concept.
And what would be our next step?
Well, it would 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.
This is a product I worked on with some collaborators a couple of years ago.
This is a mood board for designers, graphic designers to go through
kind of a quick brand strategy exercise with their customers.
And so this is what the application more or less looks like now.
When we started we knew, well, we needed kind of a sequential process
because 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 sort of relate to each other.
So we looked at these kind of wizard patterns where you can see you go through
step one, step two, step three here.
And so we looked at various travel booking sites where you would go through and
book a flight and a hotel and a this and a that.
And sites where you would buy insurance, you needed to go through and
follow this information in sequentially.
And that's how we came up with this sort of 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 that you can actually, you'll see shortly,
how to actually test these ideas with the users?
So that you're 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'll get your cheapest and best usability outcomes.
