How I Split Work: Endgame

Now that our original pitch is more manageable we can get on with the next step. What is that step you ask? It is to figure out what exactly our endgame is. Or at least, what it might be as we often get it wrong. We are OK with being wrong because changing directions is much easier than taking the first step.

Plus, as we continue on we may decide our expected result isn't quite right and have to come back. It is very common for me to reach step 4 and be like, "whelp none of this works back to step 2 or 1."

Like with the last step this has two parts to it. First, we have to decide what the end result will look like for our users or system. And second, we have to find out if it is even possible, saving this information for later.

How to find the endgame

In order to figure out what our end results are we have a few options. More, of course, may exist these will just be a few. You will often build your list by combining more than one concept.

Ask

Our first and probably the most obvious option is to just ask. We may need to ask our users or maybe your project lead, this will depend on your specific circumstances.

Also, asking may sound like the best and most direct way, but it is very common for people to not really know what they want so you may not get that great of answers back. Plus, you still have to digest and analyze a list of items.

Infer

Given we already have some data about our users and our system, we could probably infer what the expected experience will end up being. Especially if we have some or a lot of domain knowledge here.

Guess

You can also just flat out guess. As you work through this process you may find that some parts don't quite align or fit. If this happens to you, as it does to me, you may have guessed incorrectly and have to come back here.

Copy

Odds are, you are not building something 100% unique, when it comes to design or user experiences it is oftentimes best practice to copy from others. Not for your entire application sure, but do you need to create user accounts? You probably need a login form, and there are hundreds of examples of those so just pick one and get started.

The reason why copying is so effective for your users is that it removes the need for relearning anything. For example, dev.to is probably not the first website you have used that you may want to search for. Now, without thinking about it too hard, where do you want to look for that good old search bar? Not because dev.to told you so, but because that is where everyone puts it.

Create it yourself

If all else fails, or if you are really adventurous create a brand new never before seen thing. We are not going to be doing this, I am not creative enough for that.

Blurb Everything

It is very common to not come up with the right answer on the first try. In fact, you should probably expect this. Instead, I consider this process more art than science.

Usually, I just start listing out as many ideas as I can. Ideas I like stay, ideas I do not get the boot. Usually, a quick pass in my head before I spend any energy with a pen on paper.

So back to our original pitch about a movie theater ticket ordering. Since it is fairly common for people to have gone to the movies at least once, we can rely partly on existing experiences, aka copy it. Additionally, we have been given some nice requirements, we should be able to infer some from that. Finally, what we don't know, we can guess.

While writing down ideas like these, you want them to be focused on what the user experience is. Additionally, we only care about the end result at the moment, not the beginning. That is, skip the parts where you walk up or do the ordering. Only what happens after you have placed your order.

So what sort of ideas can we come up with?

1. I should receive one ticket for each person
2. My ticket should tell me what movie it is for
3. My ticket should have the time of the movie on it
4. My ticket should also have what room the movie is in
5. My ticket should have how much I paid for it
6. My ticket should give me access to the room
7. My ticket should have my discounts on it
8. My ticket should be enough for a refund
9. I should be given a printed receipt of the transaction
10. My receipt should have the total of the transaction
11. My receipt should say how much change I got back
12. My receipt should have the date of the transaction on it
13. I should get the change back with my ticket
14. If I enter and show my ticket, I should get directions to the room

Ok not a bad start, quite a lot of little things that occur when ordering some movie tickets. I am sure there are more I did not think of and that is fine, moving on.

I have conveniently listed these in a few groups. This will make step two much easier.

Viability

Now the fun part, we need to go through each of our points and figure out if they are possible or not. Ideally, since we will know if they are possible we can save notes for later.

Some examples of this can be; does your third party have an API, does android allow you to access that from your app, do you have the right access to the API, does your database support that operation, do you even have a database, you get the point.

Since this is a demo I will be answering these questions with some technical details we can come back to later. These are mostly meant for developers so we will leave them out if we ever bring this up to our stakeholders ( hint hint ).

1. I should receive one ticket for each person
   1. For this demo, you will return an array of ticket objects to be printed
2. My ticket should ...
   1. Tickets will include any key-value pair to be part of the ticket
3. I should be given a printed receipt of the transaction
   1. For this demo, you will also return a receipt that will be printed
4. My receipt should ...
   1. Just like tickets, receipts are dynamic
5. I should get the change back with my ticket
   1. For this demo, you will return the total amount of change
   2. This will be taken by the employee to return back to the customer
6. If I enter and show my ticket, I should get directions to the room
   1. We have no control over this, so we have to cut it

So now we have another fairly short list of things we have to deliver on. Or at least, things we would like to.

Thank you for reading.