17:
At my current employer we’ve spent the last few months getting ready to replace our homegrown ticket system with something more able to handle the more complex organization we’ve become. The project has evolved like most projects: Talk to users, analyze needs, document requirements, find contenders, evaluate contenders with users, and select something within the budget. Or almost within budget, if you’ve got a good case.
One of the hardest things for the project team to talk about was our maintenance production process. Over the years, it has evolved. We’ve tried to keep it simple, but it’s complicated, given the range of problems being solved, all the different people who may work on any given ticket, and the overlapping cycles in a two-week schedule. One of the complexities was the different paths and routes a ticket could go and how those different paths fit on the regular schedule. To better understand the workflow and timeline and our users’ needs, I created a diagram:
Overlaying the non-linear workflow on a linear timeline was a challenge, but it helped us understand the complexity. We didn’t have to rethink it each time.
We ended up selecting Jira, by Atlassian for our ticket system. It has the right features and configurability, and it integrates well with the new intranet platform we’re standing up (Confluence, not coincidentally also by Atlassian). We like the products, but of course the problems you’re solving are different from ours. Your diagram will be different. But you knew that already, didn’t you?
19:
At my current employer, we’re undergoing a massive re-work of our main site. Mostly backend changes, but I was given the opportunity to refresh the UI as I brought the HTML and CSS more inline with web standards. On the major customer form page, we have an email address field. While interviewing our Customer Care department, I found out that the largest number of calls they receive are for people who never received their confirmations because they mistyped their email addresses.
My immediate thought was to add a secondary email address field. It’s what you see in most cases. Our development group complained and rightly so that it’s never fun entering the same information twice and that at least some number of users just copy and paste the address anyway.
After thinking some more, I came up with what I hope is a more elegant solution. After the user enters his or her email address, a message appears in red repeating the user’s email address:
The solution depends on JavaScript, using the onblur event. For our site’s users, less than 5% have JavaScript disabled. One thing I like, though it’s subtle, is that the message explains why the user should review what they entered; they won’t receive their confirmation if it’s wrong.
07:
A few years ago, I redesigned several calendar interfaces for the Boston University community of more than 40,000 people. It was a good challenge, given the large audience and the range of user profiles. The main objective was to improve the user experience, something there wasn’t time for in the first release. My project roles included user interface designer and project manager.
Some improvements I designed included
- fewer fields on event displays and submission forms
- more logical field groupings and group headings
- client-side dynamic elements, showing what’s needed only when it’s needed
- simpler and more scannable search results
Click any of the thumbnails below to view them full size, or you can peruse (“peruse”!) the Calendar 1.1 project site on the BU Web.
31:
When I worked as an information architect at Dynamic Diagrams, I got the chance to contribute wireframes for a complete redesign of the University of St. Andrews website. The project was interesting because the project lead, Mac Mcburney, had architected the site with a CMS backend that single-sourced certain content across user groups (the standard university constituencies: students (current and perspective), alumni, parents, faculty, staff). This meant that the information groupings and layout for the same content chunks had to work across user groups, as varied as they were.
Our work at the project ended at requirements and wireframes, along with some visual design. It was interesting to see how close the final pages were, after more thorough visual design stages and implementation, to the wireframes. The site has been out a few years now and the pages are still close to the originals. That’s satisfying.
Click the thumbnails to view a PDF file of some of the wireframes I created:
28:
Okay, right: I didn’t really solve that problem. But I did lead a project a few years ago at Dynamic Diagrams, defining the information architecture for a new website for the Forum for Global Health Protection (now Emerging Health Threats).
The analysis phase included user interviews with doctors, researchers, and other stakeholders. One thing most interviews had in common was how they thought about the knowledge: by named threat, by health field, or by global region. We made sure to incorporate a tagging system in the CMS and highlighted those facets in search, including combined searches.
To explain the site’s architecture, we created a diagram. The big yellow-orange cube in the diagram represents the knowledge facets and how users can access knowledge by single or combined facets, in 3D: by layers, rows, or single cubes.
BIG NOTE OF CREDIT: Kim Looney of Dynamic Diagrams did the stunning visual design. My role was to define the requirements, define the architecture, and manage the project. Second note: It’s a large PNG file and may take a few seconds to load.
Click to see the detailed view. It may take a few seconds to load.
The purpose of the site is to share information about emerging health threats from pathogens, chemicals, and the environments (natural and human). That’s what the site’s architecture is doing.
rss feed
