W3C - The Task

A team project co-ordinated with one of our professor. We functioned as a start-up working with W3C, our client. The project was about building on the existing W3C specification pages www.w3c.org/tr

The Problem

We were approached by our client working at W3C to redesign the specifications pages. Our task was to make the information access intuitive and also to generally improve the experience. The existing design works but users have difficulty navigating and searching for the right content. Users mostly have identified which specs they visit the most by creating bookmarks, but when they have to look for something specific it is challenging for them to search for it. The pages also have various links, such as external, internal, reference, definition etc. Our goal was to make these external links and other freatures much more intuitive.

My role


I was part of a team at Jefferson University who partnered with the W3C community to redesign the W3C specifications found at https://www.w3.org/TR/. So we conducted a survey to gather information of how many people used w3c specification and / or any other specification websites. We were also interested to know the purpose of usage, how they access, their reason for the usage and so on. We asked participants to share their email addresses so that we could reach out to them and conduct interviews. We selected a few willing participants.


How many use w3c specifications?


Frequency of specification usage.


  • Can you tell us about your experience while searching for a particular specification?
  • Have you always found the specifications that you were looking for?
  • Walk me through the last time you used a specification?
  • What is your purpose of usage of the specifications?
  • What are you usually looking for?
  • How do you usually search for your required section/specification?
  • What do you like about the current design?
  • And more to understand how we can enhance their current experience.


When we arranged all the interviews, the information given to use was too much. It was very difficult for use to identify a pattern. We started arranging sticky notes to figure out if we can see something connects. But even then it was difficult to conclude.

Keywords usage

We took a different approach to identify those similar elements which we did not succeed to identify in our affinity. We called it "keywords usage chart". Identifying the key words people used the most, in the interviews and categorized them, helped us identify the challenge.

Persona 1


My primary role is to code and find intuitive ways to make the broadcasting of shows much more accessible, eg. a media query that will help me use subtitles. It is a tough task as looking for the exact information becomes hard on the vast information database on W3C. I also need to consider how to make media accessible. As this job is very demanding, I hope not to waste much time on searching and rather spend time making the company’s product.

Usage Goals

  • Using these guidelines to check if websites and applications are following the rules and suggest appropriate actions.
  • Using the application to define media and entertainment solutions for streaming, subtitles, etc.


W3C provides me the required guidelines on how I should be developing my product or tools for consumers. Snippet codes and descriptive information about an idea is explained elaborately, which helps me in my development process. W3C is my go to standards apart from the broadcasting (ETSI) and accessibility standards (British standards for web accessibility) to which I refer.

Pain points

  • I am not sure which version of the specification I am using.
  • When I start reading, I want content upfront and not the metadata and other links.

Search/reading behavior

  • The internal website for quick references (Quick links).
  • Browser search on W3C website.
  • Using the table of contents.


  • A robust query searchability on W3C website, replacing browser search.
  • Version control and an indicator of which version am I viewing more prominently.

Persona 2


As a simultaneous implementer and tester, the nature of my work involves both looking for a specific section in the specifications and pursuing the whole specification line-by-line’. I review and reference specifications for various web standards.

Usage Goals

  • To make the content accurate (technically and grammatically).
  • To review and reference appropriate content for specific sections.


Contribute building up a platform where web authors would find a standard set of information to create websites and achieve their goals. It is crucial to consider how each set of information is defined and being consumed by web authors. I intend to create structured data that can be used for reference and a tool/guideline for users.

Pain points

  • As an advanced user, landing on the W3C TR page is annoying, generally, I look for editor's drafts.
  • The boilerplate section at the top is quite overwhelming. Some content is redundant for me.
  • Scrolling to the top of the page, again and again, to report a bug or have access to the test suit is exhausting.
  • Unfavorable print version.

Search/reading behavior

  • I bookmark all the specs I usually refer.


  • I should get all the information upfront, instead of a huge boilerplate/metadata
  • There should be a way to indicate which version I am viewing.
  • Reporting a bug could be intuitive and easy from any point of the webpage.

Journey map


We kept the colors of W3C for wireframing as well, we felt that there was no need to create a grayscale version as the colors are going to remain the same and the target demography is already aware.
A/B testing approach was needed in order to get a clearer picture of the different ideas we were considering. We devided ourselves into two teams and approached the problem in different ways. This gave us the opportunity to test alternative design decisions.

Me and Sarika Joglekar worked together and took the classic approach. An open table of content, an upfront boilerplate; it is combination of all the data about various versions, authors and copyright etc; embedded in the header. Other necessary information such as breadcrumbs was displayed alongside the primary header and lot more. A list below explains a bit more.

  • The navigation at top with drop-down to reveal version history.
  • Open table of contents with visual mark to locate section.
  • Use of icons to indicate link function within a document.
  • Need of global search for searching specifications.
  • Use of category tags w/ specification name.

Second approach: Raeesha and Ishita

User testing

After we had our wireframes ready, we did 2 rounds of usertesting and we got some constructive feedback.

Global search: Global search will work when I know of these parameters. Can collapse so save on viewport height.
Links (Icons) within spec:Alan said ‘I’m not liking the icons within the document.’ Terence said ‘I’m used to seeing the icons, but I don’t know how useful they are.’
Table of contents highlights and line marking: Alan recommended we take a look at specification that has an absurdly long table of contents, just to make sure the idea works for all specs.
Icons on the top (Header): Both of them specifically liked the ‘File a bug’ icon and even the rest. ‘More info was a little confusing.
Changing version from drop down: Terence found it difficult, expected it to be clearly written. Alan liked it and easily located and switched between versions.
Search bar on header: As long as the search bar is doing the same as Ctrl+F (Should not change that behavior of using Ctrl+F instead integrate it and use the search bar as a way to save recent searches or show search results)
Responsiveness: The specs window is usually kept open side by side in order to compare it to something else and it will be easier if it is responsive.

Style guide

Crucial to any design, we established a style guide to be followed for all our visual designs. We kept all the colors according to the current W3C website standards. We proposed a new font and some iconography to increase the readability of the text. A well-defined typography will be an important factor in this design. We were mindful of the adaptation of such changes, so we made sure the existing font would also work with all the typographical changes we recommended.

Visual Design - Web

The main task was to provide a responsive design. But it was important to first design for the desktop because most people we interviewed as well as through the survey majority preferred it. Taking that into consideration we concentrate our focus and energy on the web platform.
As this task was much more team oriented, we had to make difficult choices and compromises to create a design with which all the team members and the client was satisfied.

Visual Design - Mobile

Once the design for the desktop was ready, we started restructuring the design for responsive mobile screens. I took the initiative of designing the mobile version.


We were asked to present the work in front of an audience. We were not expecting many people to join the live call we hosted for W3C. Having said that almost 20-25 people turned up. It was an amazing experience.


We handed all the work to W3C organization. They will have complete ownership of all the design and will be using as they deem fit. All the blog posts about this project cane be found here MEDIUM