The initial concept was a teaching tool built around the idea of limiting the choices of students to force them to be more creative in their design approaches. During this time we discussed and studied much about the concept of how limiting choices can help designers and users alike come to their results more effectively. While the initial working title of the project was “The Dice are Nice” we ultimately agreed on “Design Constraints” as the final title.
Having a physical model of the game allowed us to experiment with the game before going onto a digital prototype.
After the initial interview, I was able to establish a focused goal for the project. I then also developed follow-up questions to help create a feature list.
The next challenge became deciding on the platform to launch this product. We only had a couple of months to develop it and I was already learning and utilizing Unity for another project that I was developing alongside this. Using time to learn new technology would have taken valuable time from the UX design process so we agreed to publish the project as a WebGL application built on Unity.
With the collected information and assessment I began the documentation for the project. The goal of the documentation was to solidify our goal as well as our feature list. Due to the short development cycle, and to minimize the risk of failure, I wanted to constrain the major elements of this project to prevent feature creep.
We would still be able to test and evolve the process to achieve the project’s goal but we would not be adding features unless we could argue they would help accomplish the goals of the project in a better way.
Description: Dice are nice (working title) is an educational application that uses randomly selected parameters for students to apply to a design project. This program is built on the UNITY developer engine as a WebGL application. The program’s goal is to help students understand aspects of contrast in how they function in a graphic design composition under the guidance of a professor. The program provides a set of parameters that forces a young designer to use contrasts, size, typeface style, and serif vs sans serif in a composition.
The application will randomly generate a list of parameters for the designer.
- Two sets of 7 dice and 1 fortune cookie
- Typeset, graphic design set
- Cups work like Yahtzee
- Uses the Johann Itten color wheel. Each color has a range of colors based on the wheel.
- (1) Color dice: Currently has 3 color schemes. The outcome is 1/3
- (2) Typestyle dice: Both dice each have a single style. Outcomes are 1/6
- Dice 1 (light, black extra bold, condensed/extended) Outcome is 1/3
- Dice 2 ( Italic, bold, regular) Outcome 1/3
- (4) Size dice: 2 small size groups (12, 20, 16) (24, 36, 48) 2 large size groups (75, 100, 150) (175, 200, 225)
The graphic Design set is similar but has tint instead of a color scheme
- Has the same style and form die
- Has type face die. ( Helvetica, Futura ) ½ (Badoni, times new roman, century) 1/3
- Cups work like Yahtzee
Each shake of dice result is for a section of the class. Not individual. (Can be used by individuals as well)
“Type faces are derived by Massimo Vinnela; that you only need 5 type faces your whole career.”
Harold is a graphic design professor at a small university who has been teaching for a few years. He enjoys the history of graphic design, strong coffee, and all things Apple. His favorite typeface is Frutiger. He learns about an online application that can serve as a teacher’s aide from SIUE. He wants to expand how he teaches typography, so he gives it a shot.
Graphic Design Professor
He goes to the URL in his web browser and is greeted by a page from SIUE. It gives him the ability to log in or register. There is also a small section that explains the app and that registration is free.
He clicks on the register link and fills out his profile. It asks for his email, basic info, and to create a password. The next time he returns he will be able to log in using his email and the password he created.
Once we agreed on the required features and project goals we began discussing how we would implement this application. We talked about producing an IOS app, a web page, and an installable application among other things. Ultimately we opted to work in Unity since I was already developing an application in that for another project. During this time we also began shaving off any excessive features such as logins, that we felt may complicate things serverside.
The very first steps were building code a visually basic app that could randomly generate each parameter. Once we had a working system, we started working on basic prototypes to develop the interaction. Since this was a desktop web app we knew our input device would be a mouse, so we started planning out how that might work.
The simplest interaction would be to use radio-like buttons commonly seen on web pages. We wanted the user to be able to select the parameters they wanted and then be able to see the results to apply to their project. We experimented with ideas that expanded on the toggle switches and ultimately settled on a drag and drop function for selecting the parameters.
We tested the various prototypes on our user group to see what experiences felt best to them. The app itself is very simple, and we wanted to expand on the user’s interaction and make the experience feel more substantial. We felt requiring the user to move the elements from one array to an area of selection made for an experience that might be supported graphically to be more interesting as well.
In Adobe illustrator I designed a machine in parts that could be animated. The goal was a call to action that relied on the visual affordances of this machine. The gears turn, the dial moves back and forth, and the machine chugs up and down as if it is producing something. I wanted this machine to also have some character. The dial and gear rest where eyes might be, and the keyboard is in the place of a mouth.
My approach is to allow for user discoverability. I wanted to invoke wonder and curiosity in this experience. To help guide the user I added a flashing text that says “insert parameter “and this empty port that would indicate something is to be placed in this area.
The machine was then implemented into Unity and tested to perfect the animation as well as the interaction itself.
While the initial inspiration was retro mac icon designs in our testing among stakeholders we opted for a cleaner vector style of graphic. Below are an early concept of “pixel” art style next to its vector counterpart.
After establishing the goal for the aesthetic I then began the process of designing variations of each parameter tile. Through stakeholder discussion, we chose designs that best convey the parameter they represent. The tile design itself mirrors the shape of the port on the machine so that the user may connect the two mentally.
With an app that is largely done we comb over it to resolve anything that we thought could help the user accomplish their goals easier. We worked on the look of the app as well as the interactions needed to help them meet their goals. But what about after those goals? If someone was teaching with this tool they may want the flexibility to produce more results. They could do the process over and over again, or we can add a regenerate button. This button takes the parameters they had selected and then processes them again to generate a new set of random results, so they gain the option to start over and select new parameters or choose to run the same ones again. While this may not be needed it adds a useful tool that can save time in case they come up with a way they want to use this we may not have accounted for.