Gears Studio - Desktop App
Gears Studio was a product that internal developers used to organized and streamline the process of component based development. Gears Studio was utilized by all the in-house development teams for our customer facing products. Our team was tasked with making this customer facing so it could be delivered as part of the SDK kit for external developers.
Gears Studio: Project Overview
My Role:
Senior UX Designer
Team:
Team Size: 5
PO/BE Developer
2 BE Developers
QA
UX designer
Duration:
4 months
Deliverables:
I was responsible for Stake holder/SME/User interviews, Use Cases, Flow Diagram, Research, Wireframes, Prototypes, UI Kit and Style Guide, Usability Testing, Iconography, Personas, and Final UI design.
Process:
Discovery
Research
Interviews
Existing user issues
Evaluation of product
Company expectations
Define
Use cases
Users
Flow diagram
Personas
Ideate
Sketches
Wireframes
Brainstorming
Prototypes
User testing
Design
Final Design & Launch
Mock ups
Visual Design
UI Kit / Style Guide
User testing
Final design docs
UX/UI Review
Tools:
Accomplishments:
Challenges:
The work done continued to changed the way the company was using UX design on their projects. After the success of License Manager the team requested having a full time UX designer on the team for this product.
I introduced a more modern design style which helped to elevated the visual appearance and usability of a company product.
This project allowed me to learn quite a bit about the development process in the company.
Lessons learned:
I utilized and relied on the knowledge of the developers very heavily on this project and because of that they started to drive too many aspects of the design. Their decisions were based off their desires which lead to a few design assets having to be revisited after implementation. I should have pushed back more when I knew they were making a less than ideal choice.
What didn't work:
We had decided on a card based system to display the component information. There was every indication that this was a supported design direction from user testing. Once the product was released, this card design didn’t work for one of the internal teams whose product contains extensive numbers of components. This resulted in too much scrolling and no way for them to get an overview of all the components all at once. We ended up designing a compact version of the cards that the users could toggle on and off to solve this issue.
The project was expected in such a short time frame that during each sprint planning the team had to make challenging decisions on what features were more important and which ones we had time to implement successfully. We had to keep adjusting the designs to accommodate the development changes.
Working with such a small and extremely organized team made the UX pipeline integration during the development process very fluid and not a defined process. It was more of a, “Hay I just implemented this design can you look at it before I send it to QA?“
The product needed to be a full redesign since the current version was designed by developers and not very streamlined or user friendly, and because we needed to slim down the current features to meet the release date.
One of my biggest challenges on this product was just understanding what the product was used for, how it was used, and how each user persona would use the product. It was a developer tool used in place of certain development steps for component based development which was a very complicated, time consuming and tedious process for developers.
Gears Studio was a new and unique product that had no direct competition, so competitive research was not possible.
Gears Studio: Research & Discovery
Research existing product version:
I explored the application on my own to see if I could figure it out how to use it and I was not successful. There was no clear path which is common in most of products in the company due to the nature of the industry. I utilized the documentation and extensive interviews with stake holders and the various users in the company that interacted with the product.
This design caused users too heavily rely on following the external documentation while using the product or asking a coworker for help.
I created a site map and work flow chart of the current version to understand the complexities of its use.
Sketches:
Sketches of the product work flows for current implementation and exploration for new direction.
Interviews with SMEs:
I had various interviews and conversations with the SMEs. These included a PO ( also the lead on the project) and 2 upper level directors.
During the interviews I gathered information on the program itself, what the business requirements were and I started to get a better understanding of the different uses of the application.
Interviews with users:
I interviewed my team first, so I could get a better understanding of the product and also because they were the team that created the product and knew the most about it. This way when I interviewed other users in the company I would understand more of what they were talking about.
User interviews were conducted locally and with users from other BISims locations around the world. I wanted to make document if variants of the use changed based on the location or product being worked on. There was variations per product and per user, but not so much by location.
Various documents of interviews and the results doc used to compare the user and stake holder desires with the actual features that were implemented into the product.
Gears Studio: Define
Use Cases:
After interviewing various internal and external users, the personas and use cases started to evolve. Three main features were utilized by all users but they were not all used the same nor were the feature used by all users.
The primary functions seen here were then written up into use cases. Some of the documentation is displayed below.
Feature
Use case
API
Components
Products
• Create a new API
• Edit an API
• Create a new component - handle dependencies, create snapshot.
• Edit and existing component - handle dependencies, create snapshot.
• Update components ( binaries only, not source)
• Create a new product
• Edit a product, edit component, update a product ( version switching )
• Update and launch a product ( only thing QA, UX designers and BD’s used GS for)
Users:
There were various different users that evolved from the interviews. They could be classified into 3 main categories.
• Back End / Front End Developers
• Technical Designers
• Other ( UX designers, QA, BDs )
FE and BE developers both had similar uses for the product. The other group used the product in a very different way. It was more focused on updating and launching a product than using it to develop components. Technical designers shared various aspects from both the above users.
We had 2 main groups of user we had to consider for this product each with different usages of the application. The internal developers were power users who wanted everything set up for maximum productivity and ease of use when using the product. The external users were developers that worked on adding additional functionality and features specific to their training needs. They were going to be new to this product since this was the first external release of this developer tool.
1. BiSims employees: backend developers, technical designers, UX designers, BDs and QA. Each group had different reasons they used Gears Studio.
2. External customers made up of backend developers who would be making use of this product to develop special features required for their intended training scenarios. Much of this was ITAR so it was not developed by our company.
Not having access to the external end users meant that all the data collected was from current internal users. After getting enough information from the interviews I was able to create the user personas that we would be targeting. For the initial launch we were only focusing on the back end developers. The other users personas were not part of the MVP and as such, their specific needs were not taken into consideration at this time.
Future releases would be rolled out to address features that were in the back log.
I added a level of humor to the data so the team would be more interested in them personally to promote and increase the acceptance of the UX process within the teams at this company.
Flow Chart:
This product was very complicated in how it was used by the developers, so a flow chart of the basic functionality was created to better explain the various channels the user could use to navigate. Since the developers already knew how they used the product, this asset was more informative to all others involved.
Gears Studio: Ideation
Brainstorming:
Brainstorming sessions were held with the team to explore design of page layout and the component visualization.
Card Sort:
A card sort was conducted to determine the information architecture to be used.
Sketches:
Many design ideas were explored and reviewed with the team. Once directions that appeared to be the most promising were decided on we moved forward with creating lo-fidelity wireframes.
Wireframes:
Font sizes, icon sizes, sizing placement of elements, and many other aspects were explored and refined.
Once the ideas were mocked up into a digital format, review and design meetings were held. We discussed and explored options and made adjustments to the placement and layouts of the various features within the product.
High Fidelity Wireframes:
Iterations were being continuously made based upon team decisions, user testing and stakeholder feedback. Here is an example of the stages the start page went through.
Gears Studio: Prototype & User Testing
Prototype - High fidelity:
A full color prototype was created for the whole product. This was necessary so we could have the entire workflow functioning to evaluate if users could navigate through the entire application.
Once the prototype was completed, test scenarios were created to focus the users on specific tasks. The users would then need to navigate through the application to complete the tasks successfully.
User Testing:
Since I had to rely heavily on the team to help with understanding the product from a developers point of view, some design decisions were driven by them. The user testing helped to bring to light that even thought the team was the intended user, they didn’t necessarily have the best solutions to allow for other users outside the team to find the product user friendly.
Many different testing sessions were conducted through out the development process. They consisted of:
• A/B testing
• Click testing
• Individual in person testing ( local and remote)
The A/B and click testing were conducted to determine if the location and messaging of assets were clear. Some results proved our assumptions were correct, but some proved we were not on the right tack. Any areas where we had unsuccessful results, we came up with various solutions, then retested until the solutions lined up with the users mental model.
In person user testing was conducted on both the XD prototypes and the beta builds. We used the XD prototypes to test the overall approach to the new version of this product first. This was to ensure we had a product that was understood by the users before development started. These test were conducted in every sprint since we developed chunks of the product in each sprint. So we’d test the feature, then build and retest the beta when it was in a testable state.
Testing insights:
Some bigger revelations that came from the user testing included:
1. Users had a hard time navigating their way back to the
Start page.
2. Users had difficulty finding the switch component version
button.
3. Users had difficulty finding the add/create new
component button.
4. The notification that came up when there was an issue
with an API that locked out the editing of that page was
not noticeable enough so users got stuck.
5. Component Output Details: No indication that their are
details in the component card that can be accessed when
clicking the expand arrow.
Click Testing
In Person User Testing
Gears Studio: Design
Style Guide, Iconography, IU Kit:
Designing the UI for Gear Studio was made much simpler by the standards put in place for external products. These standards were enacted when License Manager was developed. Now all external products were going to have a consistence design style.
New icons are designed along with the final highlight color and its variants. The product logo was also updated.The UI Kit displayed below is only a portion of the entire document that was created.
Gears Studio: Develop & Launch
Final Design:
Here is the final design for the Gears Studio application with the features that were implemented. The design and the final product were well received by the company and internal developers.
Feedback:
Internal user feedback was gathered by the team after release. Many complaints from in-house developers came flooding in. Since the product was being released to external users, some of the features that the in-house devs were used to using were not available anymore. The team set up a backlog for users to post their concerns. Over the coarse of the next year, many missing features that had been removed to meet the external users requirements were added back in for the internal users.
Rounds of bug fixing and improvements followed over the next year, and updates were released. All the major needs of internal developers had been addressed and the product is now usable by all users, internal and external.
