TOOLS:

• Figma

METHODS:

• Competitive analysis

• User interviews

• Story mapping

• User interviews

• Wireframing

• User testing

So what is Vinuit anyway?

Front end development is a much newer than its more seemingly systematic and logical (according to full stack developers) sibling, back end development. It has many assumptions—it’s about making things look pretty, it’s simple, it’s just moving a few boxes around here and there…

But as more and more software development companies, especially more senior ones like Vail Systems, Inc., begin to understand and expect a certain level of front end finesse from their full stack developers, these assumptions are continually challenged.

Front end development is difficult for many reasons:

• It’s very rarely taught in computer science programs

• Logically, it differs from back end languages like Python, C , or Java

• As a newer programming method, it lacks the processes, standards, and structure of older, back end languages

Based on ITCSS methodology and Sass, Vinuit, an internally drafted code structure for Vail developers, creates a set of standards and organizational structure to help teams have less breakable, more organized, and readable code. It is Vail’s solution for their employees’ front end dev frustrations.

But now that Vail has solved this problem, they have encountered another: How do you convince teams to use Vinuit and how do you effectively teach new code methodologies to developers?

After further initial interviews with the design team and Vinuit’s UI developer, the following was defined as scope:

Target user

Vail full stack developers at all front end dev experience levels (novice to expert)

Scope

1. Developers should be able to access and install the Vinuit code structure

2. Users of all skill levels will be able to effectively learn and use Vinuit

3. Encourage users to view and share others’ Vinuit code to better understand its benefit and use

Solution

Vinuit’s learning site is an internal tool—reminiscent of developer docs sites—that explains what Vinuit is, effectively conveys install and file content information for employees of all skill levels, and helps developers problem solve Vinuit (and other front end related) problems. More details regarding methodology follow the summary of the product’s key features.

FEATURE 1:

Information architecture for all

This product was built with one goal in mind: Providing just enough information on each page without overwhelming less experienced devs or bogging down more experienced devs.

This was accomplished by organizing navigation by user type with some integrated help from other information sources on other pages. In this case:

• Docs is for more experienced users

• Tutorials for less experienced users

• Resources for those who need CSS foundational support

FEATURE 2:

Streamlined onboarding for the less enthusiastic

FEATURE 3:

Specialized learning resources for the internal Vail developer

FEATURE 4:

Creating a support system internal devs can trust

Why this solution? : Research

Although Vail offered a preferred scope for this product, it is difficult to solve these problems well without first understanding how and why developers learn, use, and install new technologies. As well as this, Vinuit is ultimately an internal product and must match the work processes and specific needs of Vail full stack developers. I conducted the following research:

Competitive analysis

I first utilized competitive analysis to not only understand current industry standards regarding documentation sites for CSS-specific technologies but also look for any inconsistencies that could ultimately be further researched or improved upon with Vinuit’s learning site.

User interviews

User interviews were conducted to identify current employee workflows and front end dev pain points as well as confirm findings from the comparative analysis.

User story mapping

In order to better organize my thoughts and better understand current user journeys, I created 3 personas and mapped their user stories when learning new front end development.

The major points of the user journey are Onboarding, Learning, and Problem Solving. A fourth part of the user journey, which happens before all steps but is dependent on the apparent quality of onboarding, learning, and problem solving, is the Decision to Use.

Major findings from research

At the end of this exploration phase, I summarized major pain points in a series of design questions, to be tested and solved during the exploration of the solution space.

PROBLEMS:

• Developers rely heavily on search engines (e.g. Google), forum sites (e.g. Stack Overflow), and developer-focused blog sites to find the answers to their front-end problems. Since Vinuit is an internal solution, developers will be unable to problem solve using external tools.

• Many developers do not have a strong base knowledge of front-end concepts like HTML, CSS, Sass, etc. As well as this, many developers have never formerly learned front end development and struggle to understand where to start, leading to frustration.

• All developers are expected to do front end work while at Vail. However, Vail developers have extremely varied experience with front end dev work but all must be able to use and understand Vinuit. Vinuit must be accessible and usable for the least to most experienced developer, as well as stakeholders who will make the final decision about whether or not to use it.

• Developers can be wary of “unnecessary” tools and technologies. Since teams can still choose whether or not to use Vinuit for their own projects, Vinuit must provide value and compete against other external tools.

OPPORTUNITIES:

• Vail has a culture of learning and employees are encouraged to learn new skills during work time. As well as this, employees are encouraged to try new tools and technologies on their own projects.

• More senior developers and stakeholders at Vail emphasize the importance of company-wide standards and quality code.

Why this solution? : Design

Finding solutions was ultimately an iterative process, consisting of two rounds of low fidelity prototype testing and one high fidelity prototype test. Each round generally covered a different step of the user story map (Onboarding, Learning, or Problem Solving) and relevant findings were the basis for many aspects of the final design.

Sketch

Sketching is my go-to method for brainstorming design solutions. For this project, I used a storyboard format to lay out potential user flows and interaction designs.

Prototype testing

Interactive prototypes were constructed using Figma and user testing was documented via notes, audio recording and transcription, screen capture, and affinity-style analysis. I conducted three rounds of testing with internal developers.

Overarching findings and resulting design implementations can be found below.

PROTOTYPE 1:

Prototype 1 focused on the “Problem Solving” aspect of the user journey, what I initially believed to be the most difficult design problem. I designed the prototype as a quasi-search engine to glean further information about problem solving best practices.

The above findings were ultimately incorporated into the final solution in the following ways:

• Emphasis on quality docs and tutorials for learning AND problem solving.

• Inclusion of a “Vinuit” Slack channel for help, suggestions, and other forum-like activities, maintained by a team of internal “Vinuit” experts to overcome common user-generated content concerns such as moderation and trust.

• Although users prefer quality docs and tutorials, some users, especially less experienced devs, need further problem solving support via CSS foundational knowledge. This ultimately led to the overall design of the information architecture of DOCS, TUTORIALS, and RESOURCES, separated by user type with some integrated support across each. RESOURCES especially have taken on a supportive role and links to prerequisite, relevant, or extra-reading external resources are included at the top of all documentation and tutorials.

PROTOTYPE 2:

During prototype 1 user testing, I learned that users often use the same source material for learning and problem solving technology related problems. With this is mind, prototype 2 testing was centered on the “Learning” aspect of the user journey. I focused specifically on tutorial structure for diverse skill levels of front end development and learning styles.

The above findings were ultimately incorporated into the final solution in the following ways:

• Unlike my hypotheses, users did not prefer to learn via their specific learning type but instead relied upon documentation-style tutorials to learn new concepts, regardless of learning type. In the final product, tutorials become one, documentation style page with multiple information types in one place (video, code block, text, etc.). This also reduces the amount of clicks.

• Live code editors are the most important tool for affective documentation, followed by diagrams, warning callouts, videos, and, lastly, text. Tutorial documentation is structured with this in mind.

• Inclusion of obvious warning/note/tip boxes. This highlights the most important text as well as breaking up the monotony of text-heavy documentation.

PROTOTYPE 3:

This prototype combined findings from the first 2 rounds of user testing to validate reworked “Problem Solving” and “Learning” designs and also test the “Onboarding” user journey. This test more closely resembled the final design concept and only required small changes. The site-wide information architecture was also successfully validated at this point in time.

The above findings were ultimately incorporated into the final solution in the following ways:

• The onboarding process was simplified to make first-time user experience more guided and less exploratory. This was achieved by giving the user less options following the first “Get Started” step.

• The secondary navigation took on more interactivity and signifiers of engaged and disengaged sections to make the user’s location within the product more obvious.

• A “Hello World” example was added to the Overview section of “Get Started.”

• Install instructions were updated to include those unfamiliar with Sass and basic front end knowledge.

Creating Vinuit’s design system

With an extra couple of weeks towards the end of this project, I had the opportunity to create a brand and design system for Vinuit and the product I proposed. I have created a separate page for this work, which can be viewed here.

Final thoughts

Discussion

It is important to note some factors which may have negatively affected the research and prototype test results.

1. This entire product was the result of one individual UX researcher and designer (me) and as such, there may be bias or missed opportunities at every step of the process.

2. Due to the nature of the interviews, most participants participated in multiple prototype tests, leading to bias and a smaller test sample.

3. It was difficult to completely test the effectiveness of tutorial page designs in relation to the entire product as they did not contain actual tutorial content.

4. The tests were affected by the limitations of prototypes and its inability to capture all interactions, especially related to navigation and external resource links, generally reducing the overall functionality during testing.

Next steps

The project is currently as far as it can go without content. The following are suggested next steps for the project as a whole, outlined in more detail in a final report for the UI Development team:

1. Update install instructions to include necessary information for devs less experienced with Sass. As well as this, a way to confirm that Vinuit has been properly installed should be added to the install instructions.

2. Write content! Content should be built with a code-first mentality. The most important content to develop is Tutorials, followed by documentation, followed by live code editor examples.

3. User validation to ensure that the product continues to work as it should with the additional content.

4. External resources should be collected. This process has already begun and isn’t necessarily as pressing as previous steps and can be completed more slowly over time.

Reflection

Overall, this is my best UX experience to date. This project allowed me to combine my UX Research and UX Design skills and bridge the difficult gap between gathering a ton of information and making something that actually works based off of it. So what did I learn?

Story mapping and creating a list of solid design questions allowed me to more easily consolidate my weeks of research into manageable takeaways, making the jump to the iterative design stage less overwhelming. NOTE: This was my first time using design questions in my process!

The iterative design process doesn’t need to be perfect! It just needs to be based on past research and your intuition as a designer. It will work out after a few cycles of validation with actual users. Confidence and the willingness to make those initial design hypotheses is key when starting out.