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?
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
