Accessibility with TIBCO Software Inc

Advocating for accessible product development

I led a team of undergraduate and graduate multidisciplinary interns to spearhead accessibility efforts in TIBCO Software Inc. In this end-to-end human-centered design process, we identified the problem, conducted user research, and designed recommendations for the UX team to integrate accessible design practices into their workflows. As a result, our accessibility efforts successfully connected to an accessibility audit for an existing TIBCO product.

  • Team Members | Roles
  • UX Visual Designer (myself)
  • UX Interaction Designer
  • UX Interaction Designer/Software Engineer
  • Software Engineer
  • Time Jun 2019 - September 2019
  • Location Palo Alto, CA
  • Tools Sketch, InVision
  • Focus User-centered design, User research, Accessibility, Visual design
  • Methods Design of interviews, Conducting interviews, Transcription, Qualitative coding, Personas

Problem

Advocating for accessibility

  • At the beginning of the project, TIBCO has not focused on producing accessibility compliant products. [1]
  • Inaccessible technology can result in legal compliance issues, as in the Domino’s lawsuit that was taken to the Supreme Court. [2, 3]
A legal scale to represent the compliance for inaccessible technology.
  • A product built for accessibility is built for long term benefit.
  • It will save the company from doing extra work in the future and reduce work costs. [4]
A clock with an arrow wrapping around, representing rework time.
  • Accessible design removes barriers to using TIBCO products, reducing conversion rates. [5]
  • Clients with government contracts will require higher compliance levels.
A construction barrier to represent accessibility barriers for technology.

Project goals

How can the UX team make TIBCO products more accessible?

  • To provide resources for UX teams to easily integrate into existing workflows. Recommendations for accessible designs must be easy to integrate to be part of the design process to even be considered.
  • To provide recommendations that result in maximum impact, minimum difficulty. Product development teams focus on the minimum viable product. Accessibility changes should be prioritized on ease of implementation, and maximum benefit. 

Solution tl;dr

We referred to the Web Content Accessibility Guidelines 2.0 (WCAG 2.0) to create recommendations for accessible design practices for Designers and Developers.

Design recommendations

We proposed three main areas of accessibility recommendations, text, sensory, and keyboard interaction treatments. 

Poster of design recommendations for accessible software.
  • Text treatment
  • Add alternative text to images and graphs.
  • Text on a page can be resized up to 200% without loss of content or functionality.
  • Sensory treatment
  • Use more than one visual treatment (color, shape, size, etc) to distinguish indicators.
  • Ensure contrast ratio of 4.5:1 for all text and images, and 3:1 for large text.
  • Keyboard interaction
  • Add focus indicators to components.

Developer recommendations

We proposed three main areas of accessibility recommendations, HTML and keyboard navigation, and a skip to main option.

Poster of Dev recommendations for accessible software.
  • HTML navigation
  • Use proper semantic HTML elements for easier content navigation.
  • Keyboard navigation
  • Test site to ensure expected navigation.
  • Skip to main
  • Add “Skip content” for large blocks of content.

Researching the users’ needs

We conducted semi-structured interviews with 2 software developers (Devs), 2 interaction designers (IxD), and 2 visual designers (VxD) on the UX team. These interviews helped us understand user workflows and tools. Findings were synthesized into personas to guide our design process.

Key takeaways from the Dev persona

Persona image of a UX Software Developer, aka Dev.
  • “Accessible coding is nice to have, but I don’t know where to start.”
  • Activities
  • Programming using Visual Studio Code, a free and open source text editor on a daily basis.
  • Implementing specs from Zeplin specified by visual designers, which depends on the iteration speed.
  • Needs/Pain points
  • Does not know where to start with accessibility and related tools.
  • Re-doing work when designers make changes.

Key takeaways from the IxD persona

Persona image of a UX Interaction Designer, aka IxD.
  • “Not that we aren’t aware of accessibility, it’s more like a nice-to-have.”
  • Activities
  • Communicate with product managers to understand the scope and requirements on a monthly basis.
  • Deliver information architecture, sitemaps, wireframes, personas, and flowcharts for the project weekly.
  • Makes prototypes to communicate micro-interactions and conducts user testing bi-weekly.
  • Needs/Pain points
  • Difficult to get quick feedback from remote product managers.
  • Unsure how to design accessible keyboard interactions.
  • Difficult to scope a project including accessibility.

Key takeaways from the VxD persona

Persona image of a UX Visual Designer, aka VxD.
  • “I know some basics about accessible design, but there is more to learn.”
  • Activities
  • Create visual designs based on IxD concepts daily.
  • Sync up bi-weekly with developers to understand the project.
  • Present designs to product managers, IxD, and developers weekly.
  • Needs/Pain points
  • Time constraints make designing for accessibility difficult because it adds another layer of work.
  • Unclear accessibility requirements for projects by product managers make designing for accessibility difficult.
  • Resources are scattered, making it cumbersome to locate them.

Making resources for accessibility

When users develop products, documents are utilized to refer to product requirements. We conducted interviews with HR, IT, individuals with disabilities, and studied the WCAG 2.0 to create recommendations for accessible design practices for Designers and Developers. 

IxD and VxD recommendations

Designers often didn’t have clarification on accessibility requirements for projects, which are expected to be defined by product managers. This unclarity made designing for accessibility difficult for both IxD and VxD. Taking this to heart, we designed a poster to visually communicate the effect of each recommendation. To align with users’ interests in food, croissants were used as motifs.

Poster of design recommendations for accessible software.

Poster of design recommendations for accessible software.

Dev recommendations

When Devs look for help with programming, they seek answers online to gain inspiration from other people’s code. However, when it came to accessibility, Devs reported that they didn’t know where to start. To guide their learning process of implementing accessible features, we added pseudo code to the poster to show the structure of the program. A coffee motif was incorporated in the visual design to align with the users’ interests. 

Poster of Dev recommendations for accessible software.

Poster of Dev recommendations for accessible software.

Results

The accessibility recommendation posters were well received by the UX team, and successfully passed the baton to the approval of an accessibility audit for an existing product. Printed posters are now posted in the office for reference. All research and in-depth WCAG 2.0 analysis documentations were shared with them for future reference. 

The logo for a TIBCO product that had an accessibility audit.
A web accessibility logo with a green check box on top to represent a software accessibility audit.

Retrospective

Taking the lead in advocating for accessibility in industry has been a tremendous learning experience. Through interviewing the UX team, gaps in accessibility knowledge appeared clearly. This experience has helped me develop skills to identify areas for integrating WCAG 2.0, and champion accessible design practices to future projects.

If I had more time, I would take a step further to make sure accessibility is ensured in other products. Unfortunately my internship time period had concluded before the Mashery audit was launched. I will continue to advocate for and implement accessible design, as it increasingly becomes a norm in product design processes to extend technologies to wider audiences. 

Special thanks

I want to give the UX team a big shoutout for being wonderful mentors and creating a learning-friendly environment for me and the other interns. I would also like to give a bigger thanks to my mentor and visual design team manager for teaching me the ropes, welcoming me and the other interns to the TIBCO UX family, and believing in my learning process. I wish them all the best!

My mentor smiling on a boat with the sunset in the background. Four interns congregate on a sofa to take a group photo. Leanne Liu (myself) is third from the left.The UX team smiling and standing on a boat for a group photo.My manager smiling with open arms while sitting at an In-and-Out table with four platters of hamburgers and french fries.

Cited Sources

  • [1] United States Access Board. (n.d.). About the Section 508 Standards - United States Access Board. Retrieved August 21, 2019, from https://www.access-board.gov/the-board/laws/rehabilitation-act-of-1973#508
  • [2] Houck, B. (2019, July 25). Domino's Would Rather Go to the Supreme Court Than Make Its Website Accessible to the Blind. Retrieved August 21, 2019, from https://www.eater.com/2019/7/25/8930669/dominos-supreme-court-website-accessible-blind-users
  • [3] Feingold, L. (2019, October 07). Big Win for Web Accessibility in Domino's Pizza Case. Retrieved August 22, 2019, from https://www.lflegal.com/2019/01/dominos-ninth-circuit/
  • [4] W3C Web Accessibility Initiative (WAI). (2012, September 7). Financial Factors in Developing a Web Accessibility Business Case for Your Organization: Web Accessibility Initiative: W3C. Retrieved August 19, 2019, from https://www.w3.org/WAI/business-case/archive/fin#direct
  • [5] (WAI), W. (n.d.). The Business Case for Digital Accessibility. Retrieved August 19, 2019, from https://www.w3.org/WAI/business-case

TIBCO Software Inc: Enterprise Software Design

Developing skills to understand and design for complex systems

Overview
‍

I created visual designs for a dashboard page in one of TIBCO Software Inc's data-driven B2B cloud enterprise software (CES, generalized name) to allow users to make informed business decisions by automating the next best action.

I collaborated with other designers, PMs, and developers through a multidisciplinary team in this process. Based on the product structure and wireframes, I developed visually consistent and skimmable UI for the user to identify unresolved issues in project cards for the dashboard page.

  • CES Team Members | Roles
  • UX Visual Designer (myself)
  • UX Interaction Designer
  • PM & Developer
  • Time Jun 2019 - September 2019
  • Location Palo Alto, CA
  • Tools Sketch, InVision, Zeplin
  • Focus UX & Visual & Interaction Design, enterprise software

Problem

The cloud enterprise software (CES) is a data-driven product that provides a collaborative platform for users to improve business outcomes by detecting key events and automating the next best action. In this product's dashboard, a key design element to understand was the concept of "resolving issues" through an activity timeline and project overview cards.

As the single visual designer in a multidisciplinary team, my goal is to create easy to use, beautiful, and consistent designs that align with TIBCO's UX design style guide.



How can I design the dashboard for CES to be consistent with the TIBCO design guidelines, and easily skimmable to resolve issues in projects?

Solution

I created a dashboard design for business and technical users to understand their project overviews and activity in a skimmable manner. I designed the Recent activity timeline, Project snapshots cards, and the top search bar.

In creating this design, I focused on minimizing the information load for clear hierarchy and skimmability.

The final mockup is shown below.

Design Process

The design process consisted of three cyclical main parts:

  • Understanding the problem Discussion, Message, Analyze
  • Iterating designs Ideation, Feedback, Analyze
  • Creating specs for developers Develop specs for devs
The UX design process begins with understanding the problem, then iterating design, and then shipping specs to developers.

Understanding the problem

In order to understand CES, I discussed with the interaction designer and PM/developer on my team. I reviewed the interaction designer's wireframes continuously. Since CES was a complex enterprise system, I repeatedly met with my team, analyzed the my understandings, then sent questions via Slack to fill in the gaps.

Who are the users?

Business User (BU)


BU's main task is making modifications to business rules in projects. Such modifications are approved by TU.

Technical User (TU)


The TU's main tasks are to approve, reject, and delegate modifications made by BU. They also have the ability to modify projects, just like the BU.

Visual design requirements


The project card must include certain elements. The most important element is the pairing of worklist item and worklist type. Both BU and TU will immediately examine the worklist item and type when skimming project cards.

User flow for the Business User (BU)

BU's main task is to make modifications to business rules within projects.

The BU's user flow begins with knowing which project to take action. From this first step, they can validate project, view project details, address validation errors or remote changes, or modify business rules in a project. The last option allows for a flow to check out the project, edit rules, commit changes, have modifications approved by the TU, and finally un-check out the project.

User flow for the Technical User (TU)?

TU's main task is to respond to business rule changes made by BU.

The TU's user flow begins with knowing which project to take action. From this first step, they can validate project, view project details, address validation errors or remote changes, or address worklist items for a project. The last option continues the flow to address worklist items, which is done by clicking on the worklist item on the project card, approving items, and finally they can see fewer worklist items of the project card.

Iterate designs

I worked closely with the interaction designer and PM/developer when ideating visual designs. I repeatedly ideated, then sought out feedback from the CES team and visual designers in the company UX team, and analyzed my feedback.
‍
‍

My main goals were to create visual designs that were:

  • Consistent with the TIBCO UX pattern library
  • Easily skimmable for users to address unresolved items

A handful of the iterations I went through for project snapshot cards (left to middle), top navigation (horizontal bars), and activity timeline (right).

Develop specs for devs

Finally, I finished up the process by providing specs on the final designs for the developers to implement. I specified the component states, spacing, icons, transitions, and other detailed UI designs. As the final step, I uploaded the specs to Zeplin.

I cannot post the specs here for privacy reasons, but I will be happy to talk about my experience during the spec-ing process if you would like to learn more.

Reflection

During this internship, I had the opportunity to work on a total of three different projects. CES was the most memorable project for me because I learned so much about tackling design problems in industry, enterprise systems in particular.

Lessons learned and challenges faced

I was able to grow as a designer from overcoming the challenges I experienced in this project. Such challenges include (1) understanding the problem space, (2) working in a multidisciplinary team, and (3) presenting designs for a good feedback session.
‍

Understanding the problem space


First, I learned that understanding the problem space is critical even for me, a visual designer, who was not necessarily designing the structure of the product. I had a misconception that visual designers do not really need to understand the problem. I realized that this was a completely wrong mindset because any design element in the product had a specific nuance. Effective visual design must communicate the meaning accurately, and that can not be accomplished until fully understanding the product. Getting to the point of understanding the product enough to begin designing was a challenge, but probably my favorite part of designing. In fact, I fondly remember the time I spent asking questions, listening to explanations, and mapping out my understandings to create the most effective visual designs.
‍

Working in a multidisciplinary team


Secondly, I was able to grow my communication skills through joining a multidisciplinary team. Naturally, all three members of the team had variant backgrounds and expertise. I learned that communication was a critical skill--that includes speaking familiar language to my team members, clarifying design terminology, and correcting design misconceptions.

‍

Presenting designs for a good feedback session


Finally, I learned that communicating my design decisions during feedback sessions was done best after clearly explaining the product and user flows. Since I was the only visual designer on the CES team, I proactively sought feedback on my designs from the other visual designers on the UX team. I realized that the product I was tasked with was unfamiliar to other visual designers. In order to share the same understanding of the product and user flows, I created problem statement and user flow diagrams that helped me explain the product before asking for feedback to streamline feedback sessions. This method worked incredibly well because other designers were able to understand design decisions easily.

Special thanks

I want to give the UX team and the CES team a big shoutout for being wonderful mentors and creating a learning-friendly environment for me and the other interns. I would also like to give a bigger thanks to my mentor and visual design team manager for teaching me the ropes, being welcoming mentors, and being so patient with me. I wish them all the best!

< Previous


BlockStudio 3 Tutorial Design

Next >


Aircraft Turnaround Management

^ top
LinkedinDibbbleInstagram