Professional
Position: User Experience Designer
Responsible for creating and distilling UX principles and design in a medium-sized company that previously had no UX. Helped pioneer the next version of their Right-of-Way acquisition software into a newer, flexible web ecosystem.
Requirements: Web-based, adaptive, next-generation
The software was written in HTML5, CSS3, JS, C#. Wire frames and prototypes were generated using Axure RP. During my time, I was responsible for the ground-up design from ideation and vision to end design and usability of CLSLiNK 3. This included performing user research, prototyping, wire frame and functional specification, in addition to requirements gathering and documentation.
Position: Lead User Experience Designer, Senior User Experience Designer / Usability Analyst
Helped develop the desktop engineering software called PEToolkit. This software was aimed at domain experts within the organization to provide fast, high-quality engineering simulations and proposals through the use of an all-in-one software suite custom tailored to specific areas of expertise.
Requirements: Desktop-based, flexible information structure, game-changing, easy to use
The software was written in WPF with C++/C# code behind the scenes. Wire frames and prototypes were generated using Microsoft Expression Blend + Sketchflow, allowing close resemblance of initial UI to the final coded project. During my time, I was responsible for the generation of several new modules (screens) as well as extending existing ones. This included performing user research, persona development, prototyping, wire frame and functional specification, as well as qualitative and quantitative usability testing.
Personal
A random deck generator for the card game Dominion by Rio Grande Games. The game has you draw 10 or 12 sets (depending on number of players) of cards from more than twice that amount, especially if you have game expansions. This program let's users select what decks from the game they want in the pool and then randomly draws out 10 or 12 sets for them to play with in a game with other optional requirements.
Requirements: low bandwidth, mobile experience, client-side only
The design of this tool was meant for a mobile experience given that this is a table-top game. Players need to be able to access this tool from a variety of places and situations, so the design was made to fit a mobile platform. This includes a small form-factor, low bandwidth foot print, and client-only scripting. With this, a user on a cellular network should only have to cache the page once and not have to hit the website again until the mobile browser's cache expires.
Posistion: Team Leader, Designer, Developer
A multi-user, client-server, web-based Collaborative Authoring system for Walden’s Paths. This system allowed a group of peers to asynchronously collaborate on a single collection of distributed web resources and the metadata associated with said resources. You can find out more information about Walden's Paths here.
Requirements: Distributed, asynchronous collaboration, web-based, utilize pre-existing REST API, facilitate group collaboration and editing
The system utilized a web-based interface that used the Yahoo User-InterfacePath Editing (YUI) JavaScript library to facilitate AJAX communication to the REST API on the server side. The server returned JSON information which was processed and rendered on the client. Collaboration was done by the formation of groups within the system and groups were given rights to create/edit/delete paths they had access to. Here individual group members could participate in a discussion on the path (collection) level which was akin to a threaded conversation, allowing them a free-prose discussion of the path. In addition to this collaboration, they were able to make comments on the page (document) level as well. These comments were similar to comments made in a source control system, documenting what had taken place during a check-in. The system allowed versioning, but at the time, the API did not have a call to view previous versions of a page.
UI work was primarily done by myself, using both YUI data tables and User Administrationhand-coded HTML/CSS/JS. CoWPaths logo was created in Photoshop to coincide with hiking path signage and to coincide with the Walden's Paths path metaphor.
This project was part of my graduate level Software Engineering course. The system was to be designed for doctors and researchers utilizing data of patients diagnosed with Parkinson's. I lead the data management team portion of the project and we were tasked with designing the database as well as an API layer with which to support storage and retrieval. This group was a cross-discipline group where I had to not only design and develop the database, develop units of the API interface, and unit test my code and other's but I also was involved in cross-team communication, requirements gathering, managing team responsibilities, and managing inter-team conflicts (which cropped up due to differing perceived expectations of different team members).
Posistion: Team Leader, Designer, Developer
This iPhone 3GS game was done for the Computers and New Media course at Texas A&M in Spring 2010. The game utilized the iPhone 3GS' built-in GPS and compass as well as Apple's map API in order to give the player a reality-augmented gaming experience.
The player must try to survive an onslaught of nefarious zombie dots. Players move and turn in the real world in order to move about the game and aim at their foes while trying to rescue survivor dots. When the player rescues a survivor, they can take a break from the onslaught with a code-breaker mini-game to earn bonus points toward free lives.
Styled like an arcade game, the only goal the player has is to survive as long as possible and achieve the highest score possible!
Requirements: Pick-up and play, pausing, fast-paced, fun to play, interactive
This was a learning experience for myself, as it was my first project in Objective C as well as a mobile platform. All custom graphics in the application were created by me save the tile icon.
Posistion: Designer & Developer
A multi-user client-server system designed for users of the MMORPG Final Fantasy XI. The system was designed to allow players to keep track of their (sometimes multiple) character, each with multiple jobs per character and the levels corresponding to those jobs.
In addition to levels players were able to track the various missions they had completed. Finally, they were able to assign numeric values of how much they would like to play a particular job or participate in a particular party type (mission, leveling, monster hunting, etc). This in turn was used in a scheduling portion of the system.
The scheduling portion of the system would have the player select what activity they wanted to do and at what time and then search the database for other players available for that time and if they were willing to perform the requested activity. The results would then be clustered using k-means clustering (k=6) on the different job's attributes (tanking, healing, physical/magical damage, etc). The user then would get to see the 6 grouped results and make a party of 6 out of the results and the system would tentatively book the event on each player's calendars as tentative. Players would receive an email message about the event and could then approve the event, blocking the time from future search queries.
Requirements: Semi-automated, easy to use, scalable, secure, client-server, scheduling, quick
The system was beta pre-viewed by a subset of Final Fantasy XI players. The system was implemented using a 3rd party calendar application. Communication was done asynchronously utilizing AJAX to interface with the server. Colors were chosen to be light. System was designed to be large scale, allowing users to query based on server, or by linkshell (guild) community. CollATE was designed to be more intimate in use, as the primary audience it addressed were groups of in-game friends that didn't have a lot of time, but wanted to do something together.
System was created as a school project and received a deal of enthusiasm by both school and the beta community. Was not made public due to maintenance costs and additional scalability development.