Bluetooth Specification Workspace

The Bluetooth Specification Management Process allows for the development of new wireless capabilities and for the enhancement of existing ones. The various Bluetooth working groups — comprised of participants from member companies — lead these development efforts.

The Situation

  • Surveys and member feedback indicate that a lack of tools and automation for simple tasks are significant barriers to member engagement, introduce more errors, and cause delays in spec adoption.
  • Delays in spec adoption mean delays for product developers.
  • Lack of automation and reporting functionality means Bluetooth staff spends more time assisting members and creating reports.

“How can we improve the Bluetooth specification development system to help working groups complete specification work more quickly and easily?”


Project Goals:

  1. An integrated and automated spec development solution to reduce development time and errors
  2. Improved revision tracking and reporting capabilities
  3. Reduced member dependence on Bluetooth staff

The Team:

  • My Role: Lead UX Designer
  • Product Manager
  • Director of Specification Management (project sponsor)
  • Front-end Developer
  • Project Manager
  • Engineering Team (8)

Research

Process Evaluation

Each group worked and managed documents differently as there was no unifying process. This created incosistencies between groups, which was problematic as many participants worked in multiple groups. I worked with product, program managers and subject matter experts to create a specification development and enhancement process to establish consistent processes accross all groups.

User Interviews + Observation

Through interviews with working group members and an evaluation of existing tools, I identified several consistent pain points and developed the following design requirements:

  • Notifications are automated
  • Members can quickly identify a project’s current phase
  • Group leads can easily create review assignments and track progress, attendance, participation, and voting
  • Group leads can plan project schedules and create alerts for approaching deadlines
  • Document file structures are consistent across all group environments

Personas

Through stakeholder inputs and user interviews, we identified four personas:

Sketching Scenarios

Scenario Development + User Flows

We refined the key scenarios into user flows to demonstrate the sequence of events at the user level

Prototyping (low fidelity)

I developed a concept on how we might convey information to users at different phases of development. The tabbed structure allowed users a snapshot of information from completed phases and steps needed to complete future phases.

Concept Testing

I conducted one-on-one interviews with working group leads and members, walking participants through two end-to-end scenarios. Key areas of functionality discussed included document and review management, project status and forecasting.Through our research we learned that:

  • Overall, participants felt that the concept was a viable solution and that it would help make their work easier
  • Most participants had questions and concerns around document management, versioning, and emphasized that users need to be able to work offline
  • Participants liked that the tool clearly communicates project status

Wireframes

Pattern Library

I worked with our front-end developer to incorporate existing design patterns from our pattern library into my wireframe designs. Several of the interactions defined did not align to any existing patterns, so we established several new ones to be incorporated into our style guide.

Final Design

Reflection

What I learned:

  1. Collaboration: invaluable while working on enterprise-level projects
  2. Patience and iteration: This project was a large undertaking. The platform chosen by engineering — SharePoint — allowed developers to quickly build basic functionality. But much of the UX meant to make users’ lives easier — the nuances needed and expected — was not realized in the first release. It took many feedback sessions and subsequent releases to reach an acceptable level of usability.

What I would do differently:

  1. Rather than release a broad, partially functional solution. Releasing smaller, yet fully functional increments would have allowed us to iterate, learn and repeat for subsequent sections while continually delivering value to our members.

Next version:

We’re planning to move from document management to a structured content management system. This will allow for:

  • Modular content development with reuse and single-sourcing
  • Simplified spec maintenance
  • Improve consistency and quality