UX Methodologies for Holistic Product Design

[Music] hi everybody my name is Pa bicki and today I'm here to talk about uh that's kind of a [ __ ] title um so who knows what this is who knows what the pink line represents okay think about how much information you just gred in like two or 3 seconds so wouldn't it be great if we could do something like this for our ux designs so maybe I think this is more what I'm going to talk about but before I talk about um sort of methodology methodologies and techniques um I just want to set a a shared context of what ux design is at least to me uh for the purposes of this talk so we sort of have the four uh temp poles of game design uh product development and we

have some levels of proficiency and understanding within that and I think every discipline would put themselves in the center of this I totally get that um we have a mixed crowd here today um Everybody belongs there but here's my pitch the reason why I think ux sits here is because we as ux designers um take the goals of all of these other disciplines and synthesize that for the player experience and we're doing that separate from UI which more sits over here so this is my blob uh I've done most jobs in the product development life cycle uh I started in QA um I've been a producer I wrote some really simple flash games uh for set toop boxes um but for the past several years uh I've been doing ux

and I love how where our discipline sits at the moment um sort of say every ux designer has a a major and a minor um so we all do ux design but we come from a variety of different backgrounds um and we have a variety of different interests along this axis so this is my UI design partner uh on my most recent project and there's hella overlap there yes I get that I think that's good I think um that should not be something to be afraid of um specifically you know game design uh also generally tends to overlap uh ux um there's a lot of room to grow in here and this is the the Blobs of all of the ux designers uh at Maxis and the key I think for successful teams is putting together blobs

that are aware of each other's overlap and don't fight that but seek to grow in interesting and new directions um so like what's your blob look like um your team the person whose job and role you want to grow into and today uh I'm hoping that here what I share with you allows you to grow your ux design blobs with that what exactly does ux do um most people think of this but for a a successful product development pipeline I think there's several steps uh before this and I'm talking through this in the context today of starting on a new project or with a new team and building from the ground up um for me wireframes are like halfway through so let's jump back to the foundation um research so certainly all

the the specs uh and and various uh documentation but also interview uh all of the leadership uh and the key stakeholders on your project and find out um I this talked about earlier today find out what everybody's goals are on the project so you know not just where the project is but where you want to get to and where everybody else wants to get to and I want to talk about that third one um deconstructs uh I'm on the mobile side we're doing deconstructs uh all the time and I think everybody does this but a lot of times you know you'll play a game for a week or two you know lunch breaks evenings and take a bunch of screenshots and that stuff sits on a shared drive somewhere and that's cool you can refer to it later when you need to talk about it um but I would propose uh take the half hour and just throw that thing into illustrator or sketch and all you're doing is laying things out horizontally

uh along the axis of time and then vertically for States and what this does is when you output this and the key is to make sure this gets output and set up on the wiki or someplace visible this creates a durable tangible output to your research time and that's one thing that I think a lot of times at least for for designers um because we're doing this all the time but it can be tricky to get leadership to give you time to do deeper research and by creating an output uh that can help in that process so audience for this is uh yourself as a ux designer but also uh design and PM um I've actually talked to uh the core PM team uh at Maxis uh to sort of start doing things or deconstructs this way um to make things usable and accessible to to other team members so once you have done your research uh

um let's talk about information architecture but maybe in a slightly different way um I would phrase there's sort of two steps here that you're basically thinking about the player journey through your feature through your game depends what what scope and scale you're talking here but you're you're basically just looking at the decisions that the player would make and do one per box and then think of all the supporting information that you'd need for that and this is a great way to get yourself in the in the mindset of a player um based on just just the player experience you're not thinking about monetization you're not thinking about any of the other stuff at this point and this also Maps really nicely um to that research piece if you're doing deconstructs being able to reverse engineer those screens and think about what the player was being asked to decide and why they were being asked to decide it so time on this is you know half hour to a couple hours it's all done in text and boxes I work

in illustrator or sketch but you can do this in in any number of ways and the idea is something super cheap and easy just to to get this out of your head and be able to put it uh in front of other people like your design partners and say hey is this like you know is this sort of what we're thinking the player is going to be going through um it's a good quick way to to sort of uh value check that um on projects we've done this on on whiteboards we've done this with not cards there's any number of ways to to do this super cheap and easy um and the benefit here is it sort of forces um you to think through the actual stepbystep portion without getting into full wire frames so you know quarter day half day but once you've done that you need to do a second pass um I call these box wires a lot of game designers will do this as part of design specs

and what you're going for here is just like um information areas circle square triangle um it would be nice because we're all professionals that your rectangles are in fact button sized 44 points fonts things like that um but it's just a quick way to sort of take that um text and color it in and get a sense of is the information uh the information order and the information priority making sense uh from screen to screen um again time for something like this you know half day to maybe two days if you're doing something big um and the audience for for for this is yourself and uh your game designers PMS as well I think that's as far as you want to take this uh because it's sort of a a value check if you're headed in the right direction but it depends on the team and Studio as to how much you can

show this to other disciplines um how much you can ask creative leadership if this is the right direction so once you have sort of a quick base idea um that flow that you designed because designers we always sort of start in the middle and then we work our way to the to the beginning and the end was probably not the uh the first time player experience um so I call that first second loss and boss it's the first time through because all you're doing is is taking your your file and just option dragging everything out pulling stuff out putting stuff in and then you think about okay first time through second time through but what about when uh the player actually lost a a session a level um and then what about if there was a a boss or a special wind condition and those are sort of the the four states uh that seem to catch the most of of these little um UI changes ux changes and by iterating uh on on all

these steps you wind up with sort of a a core flow there that's pretty well vetted against these other states now I don't think there's an output uh piece for this because it's really just sort of a work piece uh for for us as as designers but I will say take those box wires and put it into a map time is horizontal states are vertical looks maybe very much like the uh the research piece um but the idea here is that for this uh format especially when shared with other team members in a in a discussion setting it really allows people to just sort of focus on whatever they want to look at engineering will be looking at something different from product um or you might be having a discussion about a particular feature but the key uh to making this thing useful is it can't be in a digital form um so something that we do is we

actually print these out on a plotter um if you work at a big company they exist you can print to them just don't print on the glossy stuff CU that's like 100 bucks a roll print on the cheap stuff it's like 30 bucks a roll we actually buy our own paper um so that undy doesn't yell at us in Maxis and um we use it for all sorts of discussions around the the product development process it's really really great um when you know an engineer has a question on something and you'll be like wait a second I don't know if that's really the the product direction we want to go you can grab somebody else you can throw a couple people into a conversation and you can shortcircuit those Oh I thought you meant conversations that lose like a half day here and a half day there and make your game like two weeks late um mobile time frame and that I think is is sort of the the key to uh to this type of design deliverable

so at this point we're sort of halfway through we have a good overview understanding but let's talk about the the actual uh details holy [ __ ] detailed wireframes finally there okay now when you're designing your wireframes you're designing from a position of understanding what the the player journey is what the various states are and you can actually spend the time to uh get your your visual language uh set again I don't think I need to sort of belabor this point but ux is is not UI it's maybe the the foundation for UI it's the framework um but I don't think that it adds anything to the ux deliverables to set Corner radius to think about drop Shadows um those kind of things in wireframe it's similar to it's a cousin to but never the same and key um here is

that each of these screens is numbered and when you're I'm just going to go back when you're looking at something like this especially with distributed Studios this is really really great for having remote conversations because you can be talking to um different disciplines in different Studios and saying well so at the wind screen on on like 27 does does that go like does that go back to the main main HUD on 13 like no no no but we we also then need to do this power up on screen 12 oh okay and then you're talking about specific versions of those screens and that's where the the flow can get messy or also be very clean and those misunderstandings can creep in so being able to reference your numbers um also helps in in later steps on documentation this also then allows you to check everything out on device um you're creating all of these

files I'm sure you're shocked by this put it in a map take that that box flow that you built and basically fill in with all of your detailed wireframes Again by by creating a a durable output to this process you have something that other disciplines can use and listen to as well as uh speak to and and have that conversation it also gives you a nice checklist of all the stuff that you have to designed by whatever date and um don't tell anybody this but I've used this in a um DD situation where I'm saying okay we have this number of screens to design but we have this amount of time and when you have a visual record of this stuff and you can go over to the wall and just kind of point at stuff say which ones which this is sort of part of the core I think we need to do these first and these second it becomes a very quick conversation to say yes we can do that or actually this feature here it's going to be a little more important so at this point you know you're talking

a week uh maybe two depending as to how complex your game is your feature is if you're having to build a a wireframe toolkit from scratch so it's pretty heavyweight um you really want to know where you're going before you get to this point and obviously you know all of these screens can be pulled out for one-pager specs uh and for the the review and the buyin process so I think this is more for a um Team and and product development process and less for reviews and and pitching um although again it depends on your creative leadership and how willing they are to sort of like wander by and see what conversations are going on and get involved or maybe you don't want that in which case um you can position them on rolly whiteboards and you can turn them away um but I never recommend doing that um so there's a point where this physical deliverable this this model um kind of

reach it its Optimum efficiency and you really need to move into a new set of deliverables at this point um but look at how far we've come from you know sort of the the research we've thought through the the player Journey we've done box flows um all that up to to detailed wires without digging into individual pages in in the specs um where sometimes you can lose the uh the continuity from screen to screen um or the redundancy of information you're able to see all of that uh in this in this overview format so click mock um again very very easy way to just sort of get something on your device be just tapping from from screen to screen there's a billion tools for this kind of stuff um but you just you already have all

those wireframe screens you can hook stuff together like this pretty quickly um this is really great for what we call Kleenex testing basically um talking to people on other teams and getting a directional review uh and sort of a directional sense of of where your feature is um one thing that we've done on a small studio um that I think would be great to see in a large studio and we're still not quite there yet is we actually had everybody on the team do these Kleenex sessions so we wrote a script and um I gave them the The Click prototype I was like okay go find two people and interview them talk to them about our game and the engineers were awesome they were game to to try this like everybody went out and found somebody and talked about our our game to other people and it really helped um not only gather data and have that

conversation but everybody felt um really involved in the in the product development process in a way that doesn't always happen on on larger more uh sort of siloed teams so I'm still trying to figure out how to pull that off on a on a big team but we're getting there um audience for this is uh pretty much everybody you can show this to creative leadership you can even do this as a um like a a review for people who maybe aren't able to Gro uh sort of the the onepage spec format um and showing things in motion is really where ux shines especially uh in terms of the internal order of appearance um so you know ux is UI plus time right it's it's those States in between the wireframes that you've created that really is where your work can be most valuable to uh to the team

and to the game um whether you do this in you know flash or flinto whatever it is they can be very small mocks but they have to run on the device um and all of this stuff can then wind up in your specs so I'm not saying don't do specs um you'll notice that this is fairly late in the process simply because specs tend to become very heavy to maintain uh especially late in the in the game pun not intended um but when you're documenting everything you have your wireframes you have your maps and you can put your click mock up there it all becomes a sort of a good um repository not just for you know getting engineering up and running because this is the how you can build it uh style of

documentation but it's also really useful when you know 2 months later you have to go back and look at a system that you've already designed because you added this new feature or this new system and you want to figure out where it touches the other stuff you can look at your Maps you want to figure out what UI it invalidates you can look at your click marcks and you know the audience for this is obviously everybody engineering QA sort of a an ongoing thing so I don't set a time here um but the key for for I think throughout all this is the visibility of the work this is going on the wiki finally you're actually watching quote unquote real people Outsiders play so your researcher is running a test you have a prototype um and what we're all doing as ux designers

is sitting excuse me sitting there writing notes and keeping track of just sort of our our own Direction because the the team has a series of oh we know we want to change this thing later but maybe isn't necessarily in the build you want to capture all that stuff and so writing that in a Google sheet live where everybody can see it and having a um a slack chat running where people can add input is really really valuable in gathering all that feedback from different points of view throughout the team while the user tests are running um another thing we do is we have a room uh dedicated to broadcasting the the test sessions and we encourage everybody to come by just bring your laptop hang out and work it's school um the danger to that model can be um if you get um creative leadership who comes by sees a particular thing confirmation

bias kicks in yes that is exactly and then okay you've got to do damage control against that so to that point um we always sort of track the number of instances and actually this slide has changed because this is always sort of an evolving process um but the uh the idea of um the rainbow sheet is something that we're actually trying literally today um on our on our research and tracking the number of instances of particular reports of of behavior but in the recent past we've always sort of ranked stuff in a in a stack rank in a Google sheet made that visible to the team and then the key is making sure that uh you have your your sort of three the stuff that we will guaranteed need to fix stuff that we're really like to fix if we can and then the yeah who the [ __ ] is kidding ourselves we're never going to do that but it's there and we know it has to be

done at some point so once you have this uh set of user feedback you can vet that um sort of against the the team's assumptions because there's all these assumptions you've been making the entire time right and it's all about getting that information you know out in a visible way that other people can sort of weigh in and call [ __ ] on certain things and I've run through 10 steps um in a linear lift and I signed some rough times um again this is based on a you know just a simple match three title um these are intentionally small footprint tools and techniques because they need to be used at varying times throughout the the product development process you can't just do the early research stuff at the beginning and do your spec at the end end um I've never seen that actually

happen so really it's probably something more like this the reality of of what we do and the the dashed arrows sort of represent the areas where I see Studios uh iterate the most and things that sort of force that uh the rethinking it sort of tends to fit into um sort of a first scope of what exactly are we doing what's what's the framing of this and very loose very rough very fast stuff and then as you as you get sort of a sense of that you can get into sort of your more detailed and and um specific tools and techniques but I think that as ux designers we are most valuable to the to both the team and to the game the end result uh product when when we focus on doing lightweight things and and techniques um that have a t durable output uh for not just our own design

process but for the team as well and with that I'll end by asking so what methods either that I outlined here or other things that you can think of um would you employ next week next project um in your studio to contribute to both the the ux process but to the game and to the to the discipline as a whole so thank you very [Applause] much and I was told if anybody has any questions please be sure to step up to the microphone hi there uh I'm Dana I work over at uh Microsoft on Xbox games um you know I just wanted to I was curious about I really appreciate the user Journey that you kind of mapped out

there one thing that we tend to do also is um we started mapping out the uh system um architecture so kind of what some of the backend Engineering Services are and how they integrate um and I think that kind of also the engineering aspect helped us and we we would align it with the user touch points and the user Journey so you could kind of get a sense of what that whole experience was and what the tech was doing from the backside so I was just curious if that's something that you guys also add to your your Journeys or is that something you kind of discuss as a group and that impacts the decisions that you make around your user Journeys definitely um so as I I think I said at the the start the idea that ux takes the the goals of the other disciplines but also knowing the constraints like what's our budget what's our engine what's our timeline all that stuff I think to get the best design has has to be considered otherwise you wind up sort of Designing

and running out of railroad at the end of your railroad whatever the metaphor would be so how do you we don't do it explicitly um but we do all sort of sit down with with the engineers and with the other disciplines and when we do designs uh we have a cross-discipline design review um so we invite engineering to that and we ask hey what do you think about this are there suggestions that you would have of of other things yeah and the deliverables you have up front are so lightweight that it probably makes it really easy for you to iterate change based on that feedback okay thank you cool um well if there aren't any other questions I'll be across the way and wrap up and thank you very much