Guide for Launching Your Next Big Idea

Top Task Analysis & Prototyping

Paul Boag

Paul Boag

Guide for Launching Your Next Big Idea

Check out a free preview of the full Guide for Launching Your Next Big Idea course

The "Top Task Analysis & Prototyping" Lesson is part of the full, Guide for Launching Your Next Big Idea course featured in this preview video. Here's what you'd learn in this lesson:

Paul dives deeper into the top task analysis process. Survey tools like PollUnit help quickly gather feedback for prioritizing tasks. Prototyping is also essential for ensuring the audience understands the product and its value.


Transcript from the "Top Task Analysis & Prototyping" Lesson

>> So basically, top task analysis involves, as we say, gathering a long list of tasks, rationalizing them down into something a little bit more manageable, getting users to vote on the tasks that matter the most, and then we analyze the results, right? I've got quite a lightweight way of doing it that I'm the first to say is not the most the official way of doing top task analysis, but it will get you where you wanna go, right?

So let's just run through very quickly how to do it. So what we're gonna do is we're gonna jump in and we're gonna create a survey. Now there's a particular app that I tend to use for doing this, which is an app called PollUnit not to be confused with Pollfish that I mentioned earlier.

Trust me, I constantly confuse them. But Pollfish allows you to add a load of ideas and for real users to vote those ideas up and down. Well, no just up, right? So I like this so I'm gonna click the heart because I want that thing. And if there's a thing that they want that's not on the list, they can add that as an idea themselves.

You've probably seen things like this. There's a lot of sites that allow you to vote on features, a lot of apps that allow you to vote on upcoming features that people want, right. So we're gonna create a survey with PollUnit. We're gonna populate that survey with our initial list of all the features that we thought of.

And then we're gonna ask users to basically vote on those existing tasks on features or suggest new ones, right? Very simple and to do. If you need more information and wanna be taken through the logistics of how to do this, check out my course on user research and testing.

Then when we've done that, we're gonna go through and we're gonna remove our duplicates. So there will be people that suggest the same thing twice. We're gonna remove those and combine their votes together. And we're gonna simplify the wording down a little bit just so that it's easier because sometimes people will write, I would really like to be able to do this, blah, blah, blah, blah.

And you could just put the feature name in there instead, just to make it easier for you to do all of that. I mean, you can use AI to help do all of this analysis. So I've written a nice prompt for you there. That will output a nice neat list for you of using the results that you've can download from POM unit.

He said trying to get the right name for it. But the long the short of it is once you've gone through this exercise, you'll end up with a nice list of prioritized features that your target audience most wants from your app, right? And that is invaluable because now you can go well, I know I get a much better idea of what I I need to build.

And you'll probably find that the top third of the list, of all the suggestions, gets the vast majority of the votes. And then it'll suddenly tail off with a lot of other random stuff that people have suggested. So it's that top third you wanna focus on for your MVP.

So you know you're building the right things now for the right audience. We're really getting there now and honing in. Now, one of the things that you might be thinking is, how do I do this top task analysis because I don't have access to my users, right? Well, this is the grumpy old man's coming back out at this point, kinda looks afraid.

The grumpy old man's, because if that is the case, you've got a big problem. Think about it, if you don't have access to your users to get them to do a top task analysis, how will you gonna convince them to use the product. You've gotta be able to get to your audience in order to be able to persuade them to use the app.

And that's why in the final section of this workshop, we're gonna explore that challenge in more depth, right? Because it is crucial to success. You need people if you need people to fulfill fill in a survey that's easy compared to get them into buy the app. So you got to find ways to get people to complete the survey and if you can't do that, then you know you're in trouble [LAUGH] all right?

Possible places you can look Reddit, Forums, Mailing lists, social media, anywhere your audience basically are. You can post and say, hey, I'm thinking about building this app, I'd really appreciate it if you spent 30 seconds voting on some possible features that I could include in it. And hopefully you'll get a response.

If you get really desperate there are services out there that will do recruitment for you to get people to complete this survey. So many testing tools will recruit people for you for as little as $1 a person to complete a survey like this. One that I use quite a lot is Askable and you can point know them those people straight up PullUnit.

So know you know your top tasks you can plan your launch features, right? And for selecting your launch features, you don't necessarily just pick the top tasks because there are other things to consider. Does it fit with the market and what you're trying to do in the market?

Is it practical? [LAUGH] Can I actually build that thing? Just to touch on our market fit, your top task analysis is absolutely a part of the market fit, is what people are demanding. But you've also got to consider your value proposition as well. So I'm sure a lot of people asked Mark to include courses on Frontend Masters that are about topics that aren't particularly relevant to developers and the goal of helping developers.

Occasionally let the old one squeak through otherwise I wouldn't be speaking as I'm not really a developer. But generally speaking, you will still stay stay focused on his value proposition which is creating great content for developers, right? You've also got to consider the competition, of course, based on your market research.

Is that feature gonna actually help you stand out from the competition? And you also need to think about the impact. Will this feature really impress your audience and create a bit of buzz, right? So those are all the market fit considerations you need to put into what features you're gonna go with.

And then there's a bit, there's a couple of practicalities. There is how easy is it to build? Is it gonna be scalable. So often you can build something that is great to begin with but isn't gonna scale as the application becomes more complicated. And sometimes you can ignore scalability and go, well, fair enough.

We'll deal with that problem when we get to it. And that's okay but just be aware that you're doing that. And then often, personally, for each feature that I'm thinking about building I create a good old fashioned user story card cuz I've been indoctrinated into these. If you haven't come across user story cards before, it's a basic statement as a, I want to, so I can, right?

So something like, as a frontend developer, I wanna learn about MVPs so I can plan my SaaS app launch, that kind of thing. So you got your features, you've got your audience, you know your market is it time to build yet? No [LAUGH] I'm still not letting you code anything.

But what [LAUGH] I am suggesting as you prototype now might be for you. Actually, the quickest way to prototype is in code, in which case that's absolutely fine, but don't try and build the actual thing yet. There are three reasons for prototyping before you try and go for the full build.

First of all, it's gonna save you effort. It's easy to waste time building features that turn out not to be fit for purpose. Even with all this research and even with all this thought, sometimes you can be surprised and that comes back to bite you. Second, prototyping avoids mistakes that will be time consuming to fix within a full build.

And ultimately that means you'll get to the market quicker because you won't make mistakes when you're actually building and it's costly. And also, prototyping can help you plan for the future, it can help you envisage the features of an app so you can lay better foundations. So I tend to start with wireframes, and I talk a lot more about prototyping in my product design course.

But I start with lo-fi wireframes to give me a bird's eye view of how the application will fit together and how all the features work together. And then I will probably do some high fidelity mock-ups for critical screens partly because that allows me to do some lightweight testing that answers three fundamental questions.

But also, because those screens can be very useful in the final section we're gonna look at which is running a test campaign, right? So what can you learn from this kind of prototyping? The what you're trying to take away here is trying to put it in front of some users in a very lightweight way and we learn three things, do they like it, right?

Does it resonate with them? Do they get excited about it? Do they get it? Do they understand what it is and how it's supposed to work and what it can do for them? And can they use it, right? Can they successfully navigate it, complete tasks, etc? Once you've prototyped up a few pages and the kind of flow of it.

You don't need to do the whole thing. I'm not insisting that every page is created as a high fidelity prototype. We've got better things to do with our lives. But once you got a few pages and a feel of how it all fits together, give it a go of testing it with something like listen this is a great app that does three very basic tests that we can try.

Again, I've talked about this in my course on user research and testing. So the three tests I tend to run are do they like it tests, which is a survey. And basically the survey ask them what words they associate with the app that you've created. Exciting, is it innovative, is it perfect for my needs or whatever else you just, words come back.

Just to get a sense of what people think about it. More details on running those in the other course. Then we can look at, do they get it? I typically use a five-second test for this. Where I show one of my high fidelity mockups or even several of them to user for a short length of time, a few seconds.

Take it away and then ask them, what was the app? What did it do? What was it about? What could I achieve via it? And then finally, can they use it? I'll ask them to show them a mockup and I'll say if you wanted to create a new task in this task app or if you wanted to create a new project in this task app, where would you click?

And then they click on the mock up and it records where they've clicked and you can see where the people are clicking in the right place, etc. I'm really skipping over this. I do go into a lot more detail in my other courses, but the principle is it's worth doing a little bit of a sanity check in a little bit of lightweight prototyping before you start building.

The bigger question is, well, should I be building a fully interactive prototype and doing a lot more thorough testing? To which the answer is yes, but not now, right? We still don't know despite all of our research, despite all of our competitive analysis, our understanding of users, we don't know one fundamental thing which Mark mentioned earlier.

Will people part with cash, right? Will people actually buy this thing? And we need to know that before we actually start getting into the heavy development cycle of proper prototyping, proper testing, etc. So just to wrap this kind of defining your MVP section up before we look at that final area.

An MVP, it's an indispensable step I would argue in creating a SaaS application. Prototyping is an indispensable part. You wanna brainstorm as many tasks as you think that users might wanna complete. You wanna identify the tasks that matter most users, work out what features are practical to actually create and then just prototype a little bit of that before you go any further.

Then once you've prototyped a little bit of it, once you feel you've done a bit of testing then we're gonna run a test campaign. And this is where the rubber really hits the road.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now