Storyboards and Wireframes
Now that our team has several high priority scenarios identified for the MyFlix application, they'll move right into the storyboarding and wireframing process. We'll be following the progress on Trello along the way.
-
Kelly: All right, let's start storyboarding some of our scenarios, why don't you drag that card into the storyboarding column?
-
Pete: Oh, I see, so when we do a step the card goes into the respective column? That's pretty helpful.
-
Kelly: Exactly, and trust me, once we have several people working on the project and tons of scenarios, this will be a huge help to keeping things organized.
-
Pete: It's like an assembly line...
-
Kelly: Very good observation, that's a good way to think about it, there are certain things that we need to do at each step of the way to add value to the initial user scenario, eventually there will be more columns and that value add will include the actual coding of the features.
-
Pete: I can't wait for that! So what's this storyboarding all about, like in movies?
-
Kelly: Yup, in the same way directors use storyboarding to describe complex shots and action sequences, we'll use storyboarding to describe interactions with our application.
-
Pete: Why do we need to do that, didn't we just describe them in the scenarios?
-
Kelly: Haven't you ever heard that a picture is worth a thousand words?
-
Pete: True, but then couldn't we have done that in the first place when we were thinking about scenarios?
-
Kelly: Remember, Pete, that it was pretty quick to write down our scenarios, drawing these storyboards will take a bit more time. We could have come up with some scenarios that we decided to throw out, or edit. We kept it simple at first, now we'll increase the detail and specificity.
The storyboards in this book were made with a tool called StoryboardThat: https://www.storyboardthat.com. If you are great at drawing you might have just as much fun sketching out you own storyboards on paper, and it can even be faster that way. However, using a tool like this can ensure consistency across your team, so everything always looks the same and you can focus on the interactions.
-
Pete: This is pretty cool Kelly, it's like a little comic book maker, I was worried I would have to be drawing pictures, I'm not too great at that.
-
Kelly: These things are what we call "low-fidelity," the idea is not to be Picasso, but simply to get key points across, just showing the interaction visually can provide a lot of information.
-
Pete: What kind of information?
-
Kelly: Context. It's one thing to say something, but another to see it, can't you think of anything that looked good on paper, but upon seeing it you thought otherwise?
-
Pete: Ha ha ha, yeah now that I think about it, my dad had this whole plan for a "man cave" in our basement, it looked great on paper: bar, pool table, fun stuff on the wall, but whooo boy, when we got the concept design back from the contractors, it looked like a bad frat house.
-
Kelly: Well there you go, we are trying to do similar things here so we can direct our efforts correctly, without spending too much first. What ended up happening?
-
Pete: We changed a bunch of stuff around, and it ended up looking a lot better in the end.
-
Kelly: That's what I like to hear. So let's get started, why don't you describe each step of the scenario and I'll draw out a frame.
-
Pete: All right, so let's say Blake is sitting on his couch, in his apartment and searching on the Internet for that Independent film...
-
Kelly: Something like this?
-
Pete: Yeah exactly, ok so he types in the name of the movie into a search engines and then searches.
-
Kelly: Ok got it:
-
Pete: And then when his search results come up, he'll hopefully see that the movie has a profile page on MyFlix, and he'll be curious cause it will say something like "watch online now."
-
Kelly: All right I see what you're saying.
-
Pete: Ok, so now he is on this movie profile page, and sure enough it's the movie that he is looking for, but he obviously can't watch it because he doesn't have an account, so it shows clearly that he needs to sign up to watch or something like that.
-
Kelly: Got it.
-
Pete: Hi, nice font on the movie title, I like it. All right so now he has to do all the sign up things, which I guess we aren't being too specific about right now.
-
Kelly: Right.
-
Pete: So then, he probably is "doing signup things" and has to use a credit card to enter payment information.
-
Kelly: Like so?
-
Pete: Perfect. Finally since he signed up he's able to watch the movie, and so he's enjoying the movie from the comfort of his own home.
-
Kelly: Like this:
-
Pete: Yeah there we go!
-
Kelly: One question though Pete, how does the movie get to the screen from his laptop?
-
Pete: Well didn't we say he used the browser on his TV? Or I guess he could just use a monitor cable from his computer?
-
Kelly: Ok cool, just want to make sure you were thinking about that. So here's our completed storyboard for the "Joining MyFlix"
-
Pete: Nice, that looks pretty great. Now we'll do the next one?
-
Kelly: Yeah in a moment, first let's attach the storyboard to our scenario card:
-
Pete: Oh that's right, cool, it just shows up on the card.
-
Kelly: Yeah and you can see how we've added more value to this scenario.
-
Pete: All right, I get the hang of this, let's move the "Adding Content" card into storyboarding and get started.
-
Kelly: Are you sure that one needs a storyboard?
-
Pete: Well yeah, isn't that the next thing we have to do, I thought we had to storyboard all of our scenarios.
-
Kelly: Not exactly, it's not as simple as that, you don't always have to make a storyboard for every one of of your scenarios, only the ones that are difficult to conceptualize.
-
Pete: Well how do you know when to and when not to?
-
Kelly: Well storyboarding can be thought of a good communication tool, either with yourself, or others on your team. It can be helpful, after some time, to review a storyboard, and you know exactly what is going on. But sometimes the scenarios are so straight forward that a storyboard is overkill. Let's take a look at that adding content scenario:
Carrie has several new episodes of a new TV show that she needs to distribute. She accesses the MyFlix administration system and queues several videos for upload, as they are uploading she fills in meta data, and sets their release dates.
-
Pete: Yeah looks pretty complicated, she's gonna have to use several screens, and click on different options and stuff. I'd say worth a storyboard.
-
Kelly: Well Pete, I think once we get to the next step you'll realize that this scenario will benefit more from a wireframe which will show more user interface details. As it is, pretty much all Carrie is doing is using the app, so any storyboard, would just be lots of frames of her, at her desk, clicking on the computer screen.
-
Pete: So if you are just clicking on a screen, it's not worth storyboarding?
-
Kelly: You can kind of think about it like that, but more generally, storyboards are helpful where the environment and multiple users or personas are involved. If it's just a single user, using a computer interface, most of the interaction can be captured in a wireframe.
-
Pete: Well what would be a good candidate for a storyboard?
-
Kelly: How about the "car mode" on your cell phone?
-
Pete: What do you mean?
-
Kelly: Well think about that scenario, you are in your car, and you need to fire up some navigation app on your phone. There are lots of phones that have a car mode where you see a few important apps you would need, and they have huge icons so you can press them quickly after glancing away from the road.
-
Pete: Sounds dangerous Kelly.
-
Kelly: Well I mean, yeah, but that's not the point, the point is that in that storyboard you would have the context of the car, you'd see the big icons, you'd see the situation and environment where the interaction takes place, and how it informs the design of the feature. Why don't we try a more complicated example that would benefit from a storyboard.
-
Pete: Ok which one?
-
Kelly: I think the "Inviting a Friend" is a good one.
-
Pete: All right, I just dragged it into the Storyboard column:
Blake's friend Katie has a unique taste in films herself and one which Blake respects. He figures she would be into the selection and usefulness of the MyFlix application so he sends her an invitation through the application because it will allow her to sign up with the first month free. When Blake learns later that Katie did create an account, he chooses to follow her so he can watch her public queue and watch history, and find new films that he might like to watch based on her opinion.
-
Kelly: So what's going on in this one, do you see why it would benefit from a storyboard?
-
Pete: Yeah, because we have two users, Katie and Blake, and Blake uses the app, and then something happens that Katie needs to deal with, and then Blake does something. So that back and forth would be best captured in a Storyboard?
-
Kelly: Great Pete, you'll be an agile planner yet, care to put together the storyboard?
-
Pete: Absolutely, here's one:
-
Kelly: I like that, and then what?
-
Pete: Yep, let's add it to the scenario card.
-
Kelly: Very good. We are moving right along, now why don't we add some wireframes to these scenarios!
Our team has made a few storyboards of high priority scenarios that have helped to clarify the desired interactions. Next, we'll move into building wireframes for a few of the scenarios. Remember that wireframes focus on the layout and interaction, not so much on the design. This is where our application really starts to get down in the details and we get closer and closer to starting the building process.
We group wireframes with storyboards because not every scenario requires a storyboard, and the work on storyboarding naturally flows into creating wireframes.
-
Kelly: Ready to make some wireframes Pete?
-
Pete: Ok, but not so sure I know what you mean.
-
Kelly: Wireframes are how we are going to actually design the parts of the MyFlix app.
-
Pete: Like draw the forms and interfaces and views?
-
Kelly: Correct, now that we have a few scenarios, some of which have really rough pictures of user interfaces, we now need to get serious and design what the interfaces would actually look like at each step of the way.
-
Pete: Oh I think I'll like this, it sounds like we are a lot closer to building.
-
Kelly: Yeah we are, Pete, we are getting less general and a more specific.
-
Pete: Awesome, we'll I think we should use Photoshop for this, so we can show good detail, I'll start by figuring out a good color scheme for MyFlix and design a logo, that way our wireframes will look professional...
-
Kelly: You're getting ahead of yourself again Pete, we don't care at all about what the app is going to look like at this point.
-
Pete: Sure we do, it has to look good or no one would use it.
-
Kelly: Do you use Craigslist?
-
Pete: Yeah sure I do, but what does that have to do with anything?
-
Kelly: Does it look good?
-
Pete: Not really, it's so simple it looks like they didn't do much design at all.
-
Kelly: Well then why do you use it?
-
Pete: Well because it just works, I can find or sell stuff easily and everyone else is using it.
-
Kelly: So maybe things don't have to look so good for people to use them.
-
Pete: Oh... I guess not, still though, can't we have a little design?
-
Kelly: Pete, that distracts us from the interaction, the point of wireframing is to focus on just the basics, the interactions, and then layer on design once we are building the thing. Patterns will emerge along the way, and then those patterns can be incorporated into the design. Also, by spending a lot of time on design, you can box in yourself to a certain way of doing things. Wireframes should be able to be made rather quickly so you can try different ideas.
-
Pete: Yeah that's true it would take me a little while to come up with a good design.
-
Kelly: Yeah, and remember as with all things, we want to do a minimum amount of work, to yield the maximum results, or feedback to each step of the Agile planning process. I have an idea for a tool we can use that will make this easier.
As we move into wireframing our scenarios, a really good tool to use that will support the process is Balsamiq Mockups: http://balsamiq.com/products/mockups. It is purposely "rough" and prevents making things "pixel perfect". That way, you can focus on the interactions and layout. There is also a huge included library of common web application elements to make your designs look consistent.
-
Kelly: We're going to use Balsamiq to make our wireframes.
-
Pete: These look kinda ugly, I don't want our app to look like that.
-
Kelly: It won't look like these Pete, it's supposed to be ugly, that way we don't get distracted at all about design. Remember, focus on interactions.
-
Pete: Ok so how do we do this?
-
Kelly: First let's move the scenario card into the Wireframing column on Trello:
-
Kelly: Next, let's take a look at our first scenario and its storyboard, what is the first part of the application that's mentioned?
-
Pete: It's the movie page where Blake can sign up.
-
Kelly: Right, so we'll start with wireframing that page. Think about all the elements that need to be on that page for the scenario to take place. How about we each come up with wireframes for what we think would work and then compare?
-
Pete: All right, sounds good to me.
Pete's Initial Joining MyFlix Wireframes
Kelly's Initial Joining MyFlix Wireframes
-
Pete: Kelly, your wireframe isn't very good, it's so simple...
-
Kelly: Thanks for the kind words Pete, why don't you tell me about your wireframe.
-
Pete: Sure, well this is the public movie page that Blake would find, it has the movie title and description, and the button to sign up to watch, and then obviously there will be a menu bar up top with search, and then breadcrumbs for the navigation, maybe some links to other popular movies...
-
Kelly: Stop right there, what does any of that stuff have to do with the scenario at hand?
-
Pete: Well it's all part of the app, it needs to be in the wireframe so people know what is going on.
-
Kelly: No it doesn't, your wireframe is overly complicated, the point of the scenario is lost among a whole bunch of features that we aren't developing.
-
Pete: I thought we were going to have reviews?
-
Kelly: Maybe later, but for now, and for this scenario, especially because it's one of our first, we only want to show the bare minimum of the interactions. We won't show navigation until we have built other things to which to navigate.
-
Pete: But Kelly, we will need navigation, why not just put it in.
-
Kelly: Again, because we want to focus on the bare minimum and not over design the interactions prematurely. We might have whole other scenarios that deal with some of the extra things you included. Remember the core of our application is people watching movies online, so we'll build that first and add to it. We don't want to add a search box, just because it looks nice, it needs to have a whole scenario backing it.
-
Pete: Oh yeah, well what's so good about your wireframe?
-
Kelly: Well for one, it's super simple, and shows just the basics. Blake would land on this page from his search, read the description and know this is the movie he was looking for, and he'd see this blurred out movie player, so he's thinking "wow I could watch this right now," but the movie player is overlaid with a big sign up button. There is only one thing for the user to do, click sign up. He won't get distracted by any of the other links like in your wireframe.
-
Pete: Oh yeah I guess we do want to encourage him to sign up as much as possible. Everything about this planning process seems to revolve around doing a lot less than what I know we will need.
-
Kelly: Well when I hear "I know what we'll need," I hear a lot of confidence in assumptions, assumptions that could turn out to be incorrect. I just think it's best to be humble, validate assumptions, and let the current needs drive the features of an application.
-
Pete: Fine. We'll use your wireframe. What now?
-
Kelly: Well let's finish wireframing this whole scenario, we'll work together on it.
Joining MyFlix Wireframes
Below are each of the necessary wireframes for the "Joining MyFlix" scenario along with an accompanying description.
The user lands on the public movie page, which has the basic description of the film and a way for the user to sign up:
Clicking the sign up button takes the user to the sign up page where they enter their basic user information and payment details:
After submitting their sign up form, they are shown a page notifying them of a confirmation email:
After they've clicked the link in the confirmation email, they are redirected back to the original movie page, where they are signed in and a message notifies them that the confirmation was successful:
-
Kelly: What do you think Pete?
-
Pete: Wow this is really starting to look like an application. But what's with the email confirmation screen, we didn't talk about that in the scenario or the storyboard?
-
Kelly: That's the nature of the game Pete, as we continue to add more detail and requirements to the scenarios, we'll find that there are things we would have initially missed. For example, we'd often confirm a new user account, and that is captured in the wireframes and more generally included in the original scenario under "finally accesses his account."
-
Pete: So it's ok to add more complications to the wireframes if they are part of the context of the interaction?
-
Kelly: Yes Pete, in this case, it's not adding extra stuff, it's adding more information and realism to the interaction, so we can see each step, and how it actually might look in the app.
-
Pete: Another question: what happens if the user, for example, enters a mismatched password, or bad credit card number, wouldn't there be some sort of error?
-
Kelly: Very good Pete, that's exactly the kind of thing we'd also want to capture with a wireframe. At first it would be important, but after a while there'd likely be a pattern for how error messages and form validation are handled and we wouldn't need to wireframe it each time.
-
Pete: This scenario is getting a lot more complicated, aren't we going for the most simple?
-
Kelly: We are, but this is where things start to come into focus, we are going for most simple, or minimum viable but we have to remember that "viable" part. Good form validation will be needed for a functional interaction, and it's exactly asking questions like "what' happens if..." that help us flesh out the other necessary parts of the scenario. Let's add one more wireframe for the error situation:
-
Pete: Hey, that's what I'm talking about, this whole scenario is really clear in my mind now, I could almost start coding it from this.
-
Kelly: Yeah, "almost" there is still a little more work to do before we start coding. Why don't we add these wireframes to the scenario card in Trello and do one more set of wireframes?
-
Kelly: Ok Pete, for this wireframing exercise let's try something for our other persona, something for which we don't already have a storyboard, the "Adding Content" scenario.
-
Pete: Sounds great, I'll move that card right into the wireframing columns:
-
Kelly: All right let's read through the scenario again, and make sure we are on the same page:
Carrie has several new episodes of a new TV show that she needs to distribute. She accesses the MyFlix administration system and queues several videos for upload. As they are uploading, she fills in meta data and sets their release dates.
-
Pete: Oh boy Kelly, this is really complicated!
-
Kelly: What do you mean?
-
Pete: Well look at all this stuff going on, "queuing video uploads?", "filling in data as videos upload?". Wouldn't it just be easier to make a simple "Add video page" where you enter the file's URL and the meta data and when you submit it adds the video?
-
Kelly: I like where your head is at Pete, that would be more simple and easier to develop. And this is a great example of adjusting scenarios when we have more information. When we first wrote this, it made sense, but now that we are working on the wireframing and adding more details, it's evident that there could be a simpler way, and that is OK. We can update scenarios when we learn new things, that's what makes us Agile. What do you suggest for an updated scenario?
-
Pete: How about:
Carrie has a new episode of a TV show that she needs to distribute. She uploads the video to the MyFlix CDN server. Then she accesses the MyFlix administration system in order to add the video. She enters basic information and the release date as well as enters the associated video's URL. After processing she sees that it is confirmed for release.
-
Kelly: Hey, that is a lot better, I think that would be easier to develop as well as wireframe the interaction. We don't have a storyboard here so let's work through each part of the interaction and develop the appropriate wireframe.
-
Pete: Ok, so in the first part, she has to access the administration part of the site, so let’s have her going to a special administrator's login and entering her user information:
-
Pete: After she logs on, because, I guess this is the only thing she can do right now, she is taken right to the add a video page, even though she will probably have some sort of admin dashboard, we only have one thing, so that would be unnecessary for now:
-
Pete: On the add video page she fills out the name, description, release date, and the URL of the video file, When she clicks "add video" she’ll be directed back to the list of videos screen, where she’ll see the confirmation. and the video should be in that list... Ah ok, maybe that is the page she should see right after login.
-
Kelly: Yeah that seems reasonable, why don't we also add a wireframe for what it might have looked like before she added the video?
-
Pete: Yeah like this?
-
Kelly: Yeah all of these are great. Again you see how, out of this scenario we had to include the ideas of the "video list page" in order for the interaction to be complete?
-
Pete: Yeah, I'll add these wireframes to the Trello card:
-
Pete: Ok, great, we have some good wireframes, this is awesome Kelly, it's cool to see what the app is going to look like. Now can I get started coding up these views?
-
Kelly: Well we have just a few more steps in the process, we are getting quite close to coding, but the last thing we have to do is generate a set of user stories or user epics that will drive the development.
-
Pete: Sigh, OK let's do it!