How to Write a Great User Story: A tool for user-focused design | Edaqa Mortoray | Skillshare

How to Write a Great User Story: A tool for user-focused design

Edaqa Mortoray, Programmer, Chef, Writer

How to Write a Great User Story: A tool for user-focused design

Edaqa Mortoray, Programmer, Chef, Writer

Play Speed
  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x
5 Lessons (13m)
    • 1. Introduction

      1:19
    • 2. Creating a User Portrait

      2:36
    • 3. More about User Portraits

      2:58
    • 4. Creating a User Story

      3:23
    • 5. Conclusion

      2:28
  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels
  • Beg/Int level
  • Int/Adv level

Community Generated

The level is determined by a majority opinion of students who have reviewed this class. The teacher's recommendation is shown until at least 5 student responses are collected.

125

Students

1

Project

About This Class

Understanding the user is essential to creating a good product. Let's learn how to capture who they are.

Join Edaqa Mortoray in this interactive class, where you'll learn a technique for keeping the user as an integral part of your product design. This technique is essential for anybody in programming, graphics, or product design. This class introduces you to the basic tools we use to talk about users. These are usable on any project, large or small, and can be easily integrated into new products or existing processes.

Edaqa will go through an example of:

  • Creating a user portrait (persona)
  • Crafting the first user story
  • Understanding the user's journey

You don't need any previous experience to take this class. It's an introduction suitable for anybody interested in user experience, not only developers or designers.

After this class, you'll be able to talk about users, and will have taken a confident step through the door of user experience design.

Edaqa Mortoray is a programmer and writer, with over 20 years of experience in a variety of fields. He runs a successful technology blog, wrote the book "What is Programming?", and enjoys teaching people what he knows.

f55caf33

Music Credits: FreeBackgroundMusic B3NJ4M1N – Hope

Meet Your Teacher

Teacher Profile Image

Edaqa Mortoray

Programmer, Chef, Writer

Teacher

Hi, I'm Edaqa, a programmer, writer and chef.

For over 20 years, I've been following a diverse and exciting career path. My journey traces through several countries, filled with great people and culture. I've dedicated my time to numerous startups, and an abundance of side projects.

There's so much I'd like to share with all with you -- from programming to cooking, to the unusual creative endeavours.

I want my classes to give you the confidence you need to succeed, and the curiosity required to make the most of life.

Join me in my continuing adventures.

Recently I wrote a book "What is Programming", a dive into the fascinating profession.

I've also taken up the mantle of food stylist, as I started Edaqa's Kitchen last year. Perhaps soon ... See full profile

Class Ratings

Expectations Met?
  • Exceeded!
    0%
  • Yes
    0%
  • Somewhat
    0%
  • Not really
    0%
Reviews Archive

In October 2018, we updated our review system to improve the way we collect feedback. Below are the reviews written before that update.

Your creative journey starts here.

  • Unlimited access to every class
  • Supportive online creative community
  • Learn offline with Skillshare’s app

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

Take classes on the go with the Skillshare app. Stream or download to watch on the plane, the subway, or wherever you learn best.

phone

Transcripts

1. Introduction: Hi, I'm Antiqua, and I'm here to teach you how to ride a user story. In this interactive class, you'll learn a technique for keeping users as an integral part of your product design. You'll learn about a user persona, even create one of your own. This is how we define who our users are and how we understand them. You don't even give a face to them. From there, you'll create a years or story. This defines what your product does from the view of the user. This is the activity that they would like to perform. It includes how they would like to perform it and importantly, why they want to do this. I come from a software development background, but this approach applies to a lot more than software. In a world where hardware, software and society blend together, it's increasingly important to focus on our user user. Personas and stories are one way for teams to work together and achieve this goal. You don't need any previous experience nor any special tools to take this class. Don't worry. If you don't even have a real product, you can work with any idea from simple to the crazy or just follow along with the ideas I give. All right, let's get started and take a look at our user. 2. Creating a User Portrait: we want to start by creating a user portrait. These air, also known as personas. This is how we give a face to the user that we're going to be talking about. We can't be writing a user story if we don't know who that user is. Let's start simple. I want you to think about your product. Think about one thing that you might want the user to do or what type of user that is. Then I want you to look around, Goto a stock photo site and get an image of a real user, somebody that's going to represent who it is that we're designing for. I'll give you a moment to do that now and then. We'll continue with the user portrait. First, we're going to start with their name and age. This is Martin. He's 32 years old. Then we'll see. Where do they live? This is part of a basic demographic. Our user, Martin, lives in a small apartment in a big city. We like to think about whether this is relevant to our product or not. In this case, if we're doing a product about meeting people, it may be relevant where he lives. Next, let's ask what their job is. Our users an account manager for an advertising company. If our product doesn't focus on the work itself, we may not need to go on me details here. If your product does focus on the work, you may want to say a little bit more about what they do. The job helps establish a little bit of what our user does in life and what they might want to do with their spare time. So now we ask, What do they do? And this is again relevant to our product. Martin likes to take his grill on guitar outside in the weekends near Lake or a River. He loves inviting friends and playing music for them. This establishes what are user dozen life that may relate to our product and gives us a basis to decide the next question. What do they want to do? Martin is looking to find fellow musicians who would like to casually play some music on the weekends. Thes two questions work together. What they're doing now establishes where they are at the moment in what do they want to do ? Says where they would like to go, and this is where your product comes in. What are they hoping to accomplish with your product? This creates a basic user portrait for Martin. We know his basic demographics. We know where he lives. We know that a job is and we know what he does now. And we know what he wants to do. Finished creating this for users or and be sure to post a result to your project. 3. More about User Portraits: Now that we have a user portrait, we have a way to visualize our user. We have a better way to understand who they are. This comes from the concept of a persona in marketing, where user maybe sample from the population or created artificially from demographics off the target market. User Portrait's offer us four features to help us during product design Number one communication. They provide an easy and natural language for us to talk between teams and amongst ourselves and with the user about what the product does, who the user is and what their expectations are. Number two. Psychology. Having a user portrait lets us design for an actual person as opposed to a fuzzy concept of the user. We now have a real face to this user, and as we create more, we'll have more faces. This grounds us in the reality and lets us design for real people as opposed to fuzzy concepts. Number three Transformation. By having these portrait's by having an actual user face, it lets us challenge the assumptions about who we thought our users are. Sometimes if we develop a little bit outside and avoid, we lose track of who were developing for and we start having different notions. Stereotypes and prejudices about who are user is by giving them a face as story and desires . It helps us challenge those assumptions and make sure we're on the right track and know who our users actually is. Number four Focus. The user portrait puts the focus on the user by continual referring back for his portrait by maybe hanging on the wall, putting an interest, your system having this part of requirements. We always have the vision of the user. This is who we're developing the system for. We're not developing the product for the product itself. It is meant to be used by these people. These portrait's we have. And just keeping this in our mind helps us design a system which is user oriented. This comes with a few caveats. Number one is that we're working with a rough image here. This isn't a real person. We may have put him together from real data from demographics or Children. Somebody we think is in our target market. But we have to be aware of biases and prejudices if something isn't lining up between our desire features and the user story. It's worthwhile to investigate whether this portrait actually makes sense or we're missing something. These portrait's are not meant to be static, nor they meant to be authoritative. Over time they will morph as we had requirements the product. As we identify other users and other features, we will have to revisit this portrait and decide. Does all of it makes sense? Or do things have to change? In the end, a user portrait is just one more tool. It helps us put the focus on the user and understand how they use a system. But it will not tell us everything about our system. It's certainly a powerful tool and gives us the right motivation. But it's not everything. 4. Creating a User Story: Let's create a user's story for our user, Martin and our product. We'll start with a short form description off that story. As a user, I will create a gathering because I want to meet new people. This serves as a good header to the story for trying to catalog it or put it in an issue or feature system. Let's go into the details as a user, our users Martin. This establishes who will be doing this activity in this user story. In contrast to user, we might have a product manager or administrator. In this case, it's a user Martin, putting our focus clearly on the end user. I will create a gathering. This is the activity. Are user will be performing. Ah, gathering in our system is a way for him to meet new people, and that leads right into why he wants to do it. Because I want to meet new people. This answers why, Ah, Gavin, will it Martin find amateur musicians who want to enjoy some music and food on the weekend ? It's important to answer why? Because it establishes why they're using your product. The activity isn't necessary. There's something they want to do. It's something they will do because they want to meet new people in this case, try to keep in mind the distinction between what they're willing to do and what they actually want to do. Now, from a user perspective, we have dancer. One more thing, which is implied in our short form but isn't explicitly there. The result. What are they expecting to get out of this activity? In our case on Saturday, Martin meet some old friends and a few new ones by the lake. They eat food and play music. This result is vitally important to a user story because it establishes what the user will evaluate our product on when they go through this process. In this case of creating a gathering, they will judge success on this result, actually meeting new people. So when you write your user story right the short form and then write the long parts off all the bits that put together activity, who's doing it, why they're doing it and the result Now this is generally a very high level users story, sometimes called a large user story or refer to as an epic. We can break this down into a user journey. This journey gives us more information about what the user is doing in our product in our product. Martin he uses product on the bus and morning in the open, the app. He's gonna choose a date and he's creating a gather green. He writes a description. He chooses the location, the lake. He invites friends. He creates an open invitation to play with new people, and over the week he gets noticed is coming up until the result that he meets new people at the lake. This user story doesn't go into detail, but it's important to write down this journey, so you understand how it'll fit in. We may actually take part of this journey out to create more user stories, such as inviting his friends. This is a high level detail, but we want to understand what the experience for that is. Maybe the choosing, a date, maybe ritual calendar. This journey can be broken out to more. You're the stories, but for now, let's leave that this one user story with this subheading. As a user, I will create a gathering because I want to meet new people 5. Conclusion: great. You've created user portrait and a user story focused on one activity. This will help you focus your product design on a real user and what a user wants to accomplish in the real world. Obviously, one persona one activity will not be enough. You'll want to create more personas, capture more users. It'll be using your system and a lot more activities. They'll want to do more than just one thing. Perhaps you'll even need to break down that journey. If it's a little bit too complex, you take out the points and create new user stories to dig deeper and figure out how they work and how they fit into the picture off the user. From here, you take these user stories and develop use cases. Thes air system centric views, the requirements. We aren't covering it in this class, but I'm giving you an idea of where you go from here to create specific product requirements. Don't go overboard with user portrait in user stories. Use a little bit of common sense. These air really good for functional requirements those things that users air actively using in the product, but they don't work so good for the nonfunctional requirements like privacy, security and stability. They also don't work for some complex use cases where you have a specific requirement from one particular customer that doesn't really line up with the users, Corey. But for all those other features for all the major stories for the major existence, if your app user stories do capture the essence of what it should be doing, it also allows you to never lose track off those basic user stories. The ones white people came to your app in the first place. Those have to remain usable and simple, even as you add all the other features. You could always look back to the user portrait and those original user stories to decide if user experience is still acceptable for those users. Now go out and create more personas and more stories and keep those pictures visible so you know who you're working for. It always keep those stories handy, so you communicate with other teams and within your team and know why you're building the features at your building. Thank you for taking this class. I hope now you have a better understanding every user through user portrait and user stories. Police take a bit of time to upload your portrait and your stories to your project area. This allows us all the cable looking at and provide feedback and help each other out and see which direction we want to go. Thank you very much.