…designs from our lead designer. This is fairly typical of how things have been going recently but it’s still frustrating and not something I’d like to encourage.
There seems to be a bit of myth surrounding the interface between designers and coders. Mostly it’s in the form or what the designer needs to give to a coder to have that coder realise their magnificent vision. I can’t share any of the wonders I’ve received as “designs” over the years but the anecdotes about me wandering over to the design department, dragging over a whiteboard and then “educating” them at the top of my lungs are not all that exaggerated.
Currently I’m doing a lot of UI work, so I’ll try to break this particular area down but most of the concepts are quite simple.
Firstly, I do not need a large design document, these steps should not be a massive undertaking for the most part. Some things really are very simple and can just be explained with a little picture and a sentence or two.
Adding a health bar for example, might require nothing more than a little picture (for something this simple even the picture might be optional) and a description of where you want it placed (“in the top right about 10 pixels in from the top and edge” – although this should be controlled in data anyway), how you want it displayed (“Can it animate smoothly into place? And can it pulse and turn red when it gets below a value X?“), if it has any art assets associated with it (“Timmy hasn’t got any art ready yet, can you put in some placeholders and he’ll overwrite them?“) and then anything else you think is valuable like the details of how health depletes – perhaps the health bar will flash and then the bar will go down in two parts, first an inner part drops rapidly, whilst another deeper shade of red behind it smoothly reduces to the new value.
There you go, we all know what a health bar is in a videogame, so it’s fairly easy for us to picture it mentally and extrapolate from such a basic description to what we would hope or expect to see. There’s probably enough for me to work with there.
For more complex UI elements you really need to just go into as much detail about each of the elements that makes them up. Describe what happens when you press a button, or select something from a list. How does the view change? Where do the values you can see come from? Is that a custom view of it that I’ll be getting from Art or is it just the ingame sprite? It might seem like a lot of work to spell out what each button does, but it’s nowhere near as much work as I’ve got to do to write the code and if I’ve connected it wrong, or it does the wrong thing like buying something instead of displaying another window then there’s more work that will have to be done to correct it later. Time spent explaining what things do is less than the time spent later to correct it + the time wasted doing it wrong the first time.
The more information I’m given, the closer I can get to the thing the designer wants me to make. That’s why I get super-annoyed when I’m given a picture that has lots of buttons, lists, icons, strings (text) and numbers with no bloody description about what anything does, comes from or what value they might have. Sometimes I’m given, as recently in fact, a series of pictures which apparently form some kind of set of states that a screen might be in. These are once again, undocumented in any way which means that I have to spend my time trying to extract meaning from pictures.
A picture might speak a thousand words but that doesn’t make the thousand word description optional! It’s description & picture or description! The picture is the optional part!
Now I’m working on “Implement Flurry Ads“, that there is the entire description – the whole design. Yep, nothing about where, nothing about which part of Flurry (I’ve extracted the info, at great length, that it’s the Rewards not the Ads they want), nothing about when they should be used, how they will be displayed. Nothing.
This is what I like to call “shit-in = shit-out” design.
Write down the following when you’re doing a UI design – I’d argue it’s generally applicable but I’ve never actually encountered a good design so here’s hoping the comments will prove useful:
- Write down what you want to see,
- How does this thing appear (does it slide on, fade in, always there? Are there sounds?),
- What information will they see (Item names, costs, descriptions)?
- Where does that information come from?
- Think about what the player will want to do with this thing,
- Describe the player DOING what they want,
- Describe what happens when they do it (pressing a button, dragging an icon, pressing back button etc),
- Maybe this is very visual will a picture help? (NB: a picture is ok but some studio create flash animations – this is VERY common),
- Iterate – i.e. go over the above a few times and imagine (eg: using your imagination) being the player using what you have so far created. Does it work in your mind? Is something not clear? Do you need to explain something more? Did you miss a bit?
- Now before you rush off to give this to your coder have you used something that isn’t in the UI library or doesn’t exist anywhere else? Is it going to require some custom code for your new super-shiny-3D-car view that almost definitely isn’t in the plan because you only just played the latest Halo and now your game MUST have 3D everything even in the UI despite it being on a PSP (Thankyou Outrun2006: Coast2Coast I dedicate this rant to you) and when you ask for it will your coder give you that look, y’know the one, the one where you see the words “Coat-hanger” and “spleen” scroll across their vision like an Amiga cracktro?
- Ok, by now you should have a description, just a line or two, for every element in the accompanying picture for your UI design – it’s probably safe to give it to your coder.
1 of 3 things will now happen:
- 5% chance = If you have done well your coder will take your design, smile, thankyou for the design and then go away happy and implement it,
- 95% chance = The coder will look it over, ask some questions, ask if you really need or want something, argue about one or two things (You really need two rows of super-shiny-3d-cars even though they won’t fit in memory and we can’t render them there yet? Grrrr) then they’ll accede and go off to implement it,
- They will look at you, the words “Coat hanger” and “Spleen” will scroll across their eyes – You. Are. Fucked.
#3 will only happen if you’ve skipped the above steps, or asked for the physically impossible – please follow the steps, at least as a basic guide. You can add more, please if you do, do tell me! Just don’t do less than the above, I’m running out of coat hangers… and designers.
Andy
