My work and me

About Me

Hello, my name is Hyun — I am a designer and technologist creating symbiotic relationships between information and people. I am currently working with researchers, engineers and designers at IBM Research in Yorktown Heights, New York.
If you have any questions or have something in mind for discussion, please don't hesitate to contact me.





IBM Side Project, Code Scanner

IBM Side Project, Code Scanner

2014-15 — Commercial/Side Project :: Technologist and User Experience Designer working at IBM

Teaser image for the IBM Lighty Application Security Scanner project.

SYNOPSIS: This side project was a self-initiated case study conducted by my colleagues and I at IBM Design to create a solution for developers of small to medium sized companies to produce secure code and contribute to the development process without the assistance of security analysts.

Major Skills Applied

  • Visual Design
  • User Experience
  • Full-stack Development
  • Ad-hoc Technology Interpreter

All projects at IBM Design are worked on and produced in teams. My specific contributions for this side-project were on user experience design, front-end development, technology research, future envisioneering designs, and applying previously gathered design patterns, research, and technologies to the project.


"We have someone who understands code and build, but not security."
—Development Manager, Fortune 25 Company

APPSCAN, a suite of binary and source code vulnerability scanners offered by IBM have extremely strong engineering characteristics. However, it does not take count of usability and human interactions. Currently, security analysts deal with terrible information hierarchy, spend time learning and reading proprietary graphs, go through tree and facets of information, and attempt to connect dots where there's a lack of direction. Often when analysts identify a problem, it is more than a hassle to read and educate themselves on remediation methods; which requires the user to research first on how to actually consume and make the information actionable before even reading it. More than often, the security analyst and developers are disconnected, so they work in different schedules, communicate in different terminologies, and thus have a poor collaboration environment. *In videos / screenshots of this side project, you may see 2016 IBM INTERNAL USE ONLY CONFIDENTIAL written on the bottom right corner, this was part of the scaffold kit that I created for myself for side projects, this IP is not officially within the plans of the business. IBM ScanApp name is a parody of IBM AppScan.

As-is workflow structure.
As-is workflow structure.

The personas below were crafted by the involved designers and researcher from banking and enterprise IT companies in North America and Western Europe. The data gathered to create these personas involved shadowing and interviewing current as well as prospective clients.

The biggest problem of any AppScan product, is the fact that the security analyst and developer is locked in a linear workflow. Because of the linearity and lack of direction, the security analyst usually cannot recognize common problems and fixes; which is usually what issues arise when developers make mistakes.

A screenshot collection of current AppScan tools.
A screenshot collection of current AppScan tools.
  1. 1. Scan application
  2. 2. Prioritize vulnerabilities
  3. 3. Cross-reference and prioritize security issues with business resources
  4. 4. Communicate to appropriate developer
  5. 5. Prepare remediation and education material
  6. 6. Wait until developer take in the given information and create a patch
  7. 7. Rescan the application
  8. 8. Rinse and repeat per issue

Designing a system which includes not just an application but a suggested workflow was planned to be the solution to not only help fix security issues in the code, but relieving the analyst of common and reptitive issues by educating the developer through knowledge retention; saving not just present time and resources but the future as well.

To-be workflow structure.
To-be workflow structure.
  1. 1. Scan Application
  2. 2. Receive list of issues and fixes
  3. 3. Fix problem
  4. 4. Rescan at own pace
  5. 5. Rinse and repeat
  6. 6. Submit code

By introducing a new workflow with an easy to use and quick tool deployed per-developer, the security analyst's work is relieved of remedial tasks that are often repetitive and time consuming. The tool is designed to help track developer's skill and performance in regards to introducing security vulnerabilities in code as well as showing security issue and solution examples in a easy to read and actionable format to incentivize retention of secure coding practices in a self-paced environment. The new solution also proposes a sealed ecosystem where the developer can scan for security issues incrementally, and quickly in a single workstation before the code reaches a collaboration system and the security analyst.

IBM's interpretation of improvement of AppScan products were to make it bigger and faster.
Imagine AppScan as this hammer. IBM's solution is to provide a even bigger hammer. Solution via sheer bruteforce of speed and monolithic approach, in my opinion, was not the right way to go.
My interpretation was to arm all developers with code scanning tools that detect 85% of the most common security issues and security analysts with precision heavy weight tools that require actual analysis.
What we needed were these. The M1 Garand (top), and the 1903 Springfield (bottom). The M1 Garand was the first semi-automatic rifle to be distributed to a large force. It allowed U.S. soldiers in World War II to accurately shoot with a higher rate of fire than any other rifle fielded in battle at the time. The 1903 Springfields were wielded by skilled snipers to take out hard to reach and concealed targets. We needed to equip M1 Garands to developers and the 1903 Springfield to security analysts.


HIGH SPEED, LOW DRAG : This project was conducted in a super-fast manner. It was a project that spanned eight weeks where I worked with the designers I knew very well. By researching and acknowledging the problem from multiple AppScan projects, the foundation was very clear on what problem we needed to focus on. The execution and production stage were super exciting because this was when all of us involved in the project got to utilize the IBM Design Language to the fullest and also got to expand upon the IBM Security design team's variation of the design language. Along with visual patterns, there were sprints of motion design studies, content language establishments as well as interaction pattern studies; which all were documented and utilized later on, in the maturing stages of IBM Security's Design Language. The main end to end experience, interaction and architecture was owned by me while majority of the visual, content, and motion patterns were owned by my colleagues. Along with the actual "work", this project acted as a piece of educational material for the designers involved in the team to immerse themselves in the source code scanning space.
The project only needed to tell a story on scanning code, learning it and remediating it, so it was natural for me to find the easiest open source scanning engine to manipulate and integrate the designs with. The project was created using a LAMP stack involving PHP, and MySQL in the back-end and HTML, CSS, JS as well as the jQuery library in the front-end; all running on a Raspberry Pi for added cool factor.

  1. Hyun, Design Lead :: Technologist, UX, and Full-stack Developer
  2. Blake, Visual Designer
  3. Allison, Visual Designer, Content Designer
  4. Cameron, Visual Designer, UX Designer, Motion Designer

Similarly to other AppScan projects, being a developer and understanding security related code problems allowed me to understand the technology relatively well. All of the new ideas were aimed to improve the security analyst's ability to consolidate, and mitigate security vulnerability issues. However the biggest differentiator here is that by introducing AppScan "Light" to developers, the hope is that the developers will now catch and fix easy to fix, common issues, while the security analyst down the road using the big-daddy AppScan products can tackle more serious vulnerabilities that require more investigation and analysis. The tweet version is; this new workflow and application allows much better allocation of business time and resources in regards to IT Security.

Video capture of application login interaction.
Video capture of application responsive design.
Video capture of various micro-interactions in the application.


RESULTS were exciting... this was when we, as designers at IBM Design not only have seen the efforts of our design put onto screen and flows, but to be developed to the standards we were proud of. The project was essentially a "proof of concept"; although fully working, not particularly in match with release-ready code. The project has been packaged and recorded in a presentation deck which then were disperesed into many teams within Security Portfolio but others as well. Software Accessibility group has taken and deconstructed the process and methods of this project and adopted a lot of the interaction and visual patterns. ScanApp still gets mentioned every once in awhile in the security group. Not only this was a journey within itself with the involved designers, ScanApp was an example of what the early design team was capable of in terms of understanding and manipulation of technology and design in the cybersecurity space. This project helped the security design team gain respect and attention of influencial individuals and groups within the portfolio space.

Final Product

Video capture of a happy path use case.
Video capture of various interactions in the application.