What does design look like?
Design is a specification for what we’re building. It’s a blueprint for the project.
If an engineer has any question during a project about what to build, that design is lacking information and is not a complete design. Furthermore, when working on a team – no matter if you’re practicing agile or waterfall methods – it’s important to have design documentation to keep everyone on the same page and for communication. That’s not to say design can’t change throughout the project – there’s no doubt it will as prototyping occurs. But everyone has an idea of how a project works and looks in their own minds, and it WILL stay that way unless someone specifically writes or draws the design out (or until the thing is actually built).
This article isn’t intended to comment on good versus bad design, but instead intended as a comment on what I (as a designer and also an engineer) expect from designers. I don’t always complete all of this documentation, but I’ve found when working on teams it gets everyone on the same page. This is good for longer-term projects, and expect that in short term projects like game jams, very limited documentation occurs, with the exception of some concepts and loose process flowcharts. I’ll use a 2D mobile application I’m currently designing with an engineer friend to illustrate some of my ideas, we’ll call that application Bloom.
So, let’s get to it. How does one start designing?
But wait!! It’s important to me to point out the differences between an idea and a design first. Here’s a table on the high-level elements of each (I’ll define the terms further down the article):
|An idea could include one or all of these elements.||A design includes elements from idea, and also everything listed here.|
Figure 1. Differences between and idea and a design.
All throughout my schooling and professional career in design for 3D and 2D user experiences, I’ve run into designers who think producing a use case, or narrative, or visual is enough information to pass off to an engineer to build a project. Sure, I can riff off of these things and ultimately build a finished product… but make all the engineer’s lives in this world easier and be specific. Maybe it’s the engineer in me that has such high expectations for this. Document clear parameters for the product. This benefits the builders, the management, and yourself. Do your thorough research on the project and make sure you’re aligning with a brand specification if applicable, and aligning what the client and stakeholders want produced in the project.
Okay NOW let’s talk the specifics of design. Let’s go through the items I’ve listed in Figure 1 above. I’d be a hypocrite if I didn’t get specific. 😉
I like to think of this as the overarching idea or purpose of the project. It provides a succinct but clarifying statement to get the point across. Maybe one to two sentences.
An example: A mobile app that has multiple parameters visualized by a user interface to drive an external actuator connected via Bluetooth.
What does the application look like? For 2D applications, this might be a rough pen-on-paper wireframe like the one in Figure 2. For 3D applications, it might be a photo of a clay model or paper prototype, or maybe even a rough 3D greybox – where basic 3D geometry is placed in a 3D environment like Unity, Unreal, or Maya/Max.
Figure 2. A first draft of a sketch I used to create the wireframes for the mobile app I’m developing.
This is a couple of paragraphs, where you might talk about use cases or the main functionalities and purpose. It might go into a description of the user demographic, the environment the application will be used in, and the purpose of the features.
What are the main features of this program? Are there any special hardware requirements or connections? It’s especially important to define what minimum viable product (MVP) is made of.
Requirements for Bloom MVP:
- Connect external device via bluetooth
- Playback default sine wave to device
- Rotation dial to adjust magnitude of waveform
- Slider to adjust pitch of waveform
- Visual waveform playback on mobile
This is similar to the concept sketch, but shows a larger picture of how the application is intended to be used. It might sketch out an environment that the application should be used in, the people who will be using it, and the hardware it’s intended to be used with. It might be a first person view of a person holding a phone in a specific public space, with another person interacting with the application.
How does anyone know how this thing works unless the experience is fleshed out? You don’t. I’ve commonly started designing a flowchart and run into a process that I initially thought might be a good idea that turned out to be totally whack. I didn’t understand exactly how it would work until I actually wrote the logic for it. So let’s take a look at an example flowchart I drafted for Bloom in Figure 3. This is V0.1, so I expect it to change upon development and testing. I’d like to point out the details associated with not being able to connect the device. This was an interaction I didn’t completely think about until I started charting. But once I created that decision point, I had to flesh out what the user would experience in each case. It really goes to show how useful one of these charts is to designing an experience.
Figure 3. An initial process flowchart for v0.1 of Bloom. Click on the image for the entire flowchart.
I’d say this should come after the flowchart, because you can find functional adjustments that directly affect UI and only have to make UI once instead of having to go back and adjust the visuals. It doesn’t have to look great – a lot of effort shouldn’t be put into the aesthetic because there’s a good chance the layout is going to change once you start developing and testing it out. Check out Figure 4 for part of the wireframe I made for Bloom using Adobe XD. A side note: Adobe XD is amazing! I know it’s basically Sketch from Adobe, but I can finally easily make pixel perfect layouts and graphics and share them with the developer without using a Mac!
Figure 4. One screen of the wireframe for Bloom. It includes pts for iOS development and basic layout. Not the aesthetic of the final product.
As for greyboxing, I stole this term from game development, where a level designer lays out a 3D environment with basic brushes and 3D polygons. I find it useful for communicating 3D spaces without all the effort of finding or creating 3D assets. For an even simpler version of this, use some sculpting clay or ball up some paper to lay out a physical 3D scene and take a photo of it. At this point, I find it’s time to start prototyping the project since we’ve got the functionality and basic layout defined.
This will be a more detailed layout with the more final art assets, also called a visual spec. For 2D, it could be exported by Sketch or XD to show where each assets sits according the the pts or pixels in the layout. It’s especially important for the designer to export each item separately so the person building it doesn’t need to either go back and forth to fetch these items, or worst case, hack them out themselves. Same goes for 3D, but the asset pipeline is very different. That’s a whole other beast, but high level involves exporting each asset to .fbx for use in engine, and making sure the units are correctly set for the importing engine.
You’ve got all this documentation, now build it!
The above is the barebones to build something. I don’t want to get into the specifics of building the application – it involves development, testing, and iteration. The documentation will change with each iteration, and for rapid prototyping, I don’t find it important to put forth a ton of effort into documentation during development, considering the application will speak for itself. Although I do find it important to document for history’s sake toward the end.
Every project is different and might actually need some other flowchart process or UI component. Or maybe even less than what I’ve defined above, based on the timeline of the project. For instance, a project containing many peripherals may call for an architecture diagram, or maybe even a network diagram. I’ve completed enough networking projects to know I probably would have benefitted from making a network diagram prior to building it as well. Who’s connecting to whom? And in what order? But this can also be encapsulated in the process flowchart I described earlier. The main point I want to make by this article is that documentation is important for effective communication.
Now that I sound like a total documentation stickler, I want to note that I do subscribe to the Cerny Method of prototyping and documenting in concurrence with each other in game development, and work in agile software development environments where it’s important to do the same, instead of waterfall where you might wait to finish the documentation step and only then move onto building. I know documentation is not the end-all-be-all, but I find it’s difficult to effectively communicate with a team without it. I hope this article inspires someone to be a little more specific when they go to design something. Your engineer friends will be happier and more effective at building what you intend.