Case Study
Defined and documented UX design processes and spearheaded project to bring together two different departments into a unified web app design and development project https://www.traviscountytx.gov/its
The Backstory
Travis County ITS is the branch of the local government responsible for the county IT infrastructure. So anything that doesn’t fall under the City of Austin, or State/Federal is covered by them. County park services, sheriff’s department, local elections, marriage licenses, wildfire firefighters and more. They’re kind of the glue that holds together all the things in between.
The Initial Design
There was no initial design. I was brought in fresh. They wanted someone to to shake things up and do things differently than had been traditionally done before. I was given pretty much full reign on my initial UX research and design process, and played a major role in deciding the specifics of the final implementation. There were of course waypoints that the project needed to fit within, such as the use of existing vendor technologies, which would be utilized as microservices and piped through a custom Mulesoft middleware API that would then be consumed by our web app frontend, but I was hired in part largely to define processes which the department did not have any formal experience with.
The Challenge
Travis County ITS had two departments that they wanted to begin to integrate and possibly merge in the future. The Web Team was a team primarily concerned with social media and internet marketing. They built and maintained brochure style websites in the Joomla CMS for various other departments of the county. While they had great graphic design experience, and had begun dipping their toe into intranet sites for county documentation, they did not have any formal UX processes. The other department, the App Development team, were the group responsible for building internal tools for the county, primarily using technologies like C# for the apps and Visual Basic for UI. They also did not have a formal UX design process, instead leaving the process of designing UI to the individual developers building the apps. The challenge here was to define and introduce a set of UX design processes that could be taken up by the Web Team and integrate with the App Development pipeline. I had begun thinking about this sort of issue at my previous contract at the Department of Labor. While there I had 1) strove to push as much as my design directly into code as possible and 2) attempted to push for documentation and standardization of our designers work into a living Design System. It seems to me increasingly necessary for designers to be able to scale and integrate their work into the tools of developers, and to not merely design individual parts but to design the relationships between those parts. (this thinking has been recently validated by the Design lead of Airbnb in what he calls “DesignOps”).
The Solution/s
The solution to this challenge can be divided into 3 basic points of attack
1. Define and Document UX design processes
There were no established formal processes to UX design at Travis County ITS. There were ideas about it, but defining and documenting the process was a luxury that the county hadn’t been able to afford till now. I divided my UX research process into a couple of different approaches. First, I began with user interviews. I interviewed as many people as I could. I observed them use their daily processes, asked them questions about what pain points bothered them, and logged all additional documentation given to me by team leaders .
I made extensive notes which I organized in a private wiki. I recorded all these conversations for later review. I cross referenced these notes extensively and tried to draw out patterns and common themes between them.
I shared this wiki with the department and encouraged people to add their own input, add comments/questions. I have always been a fan of wikis, but I had first started fiddling with wikis for documentation when I was at the DoL. To me this seemed like a much smarter, more approachable way to document software projects. Developers have lots of very fancy documentation frameworks (such as Atomic Design’s Pattern Lab), and while these frameworks provide some very smart automation features, civic tech orgs often have a wide diversity of stakeholders who might not be as familiar with as much code as necessary. I settled on using Nuclino to document my UX research and processes because of it’s clean simple design, speedy SPA frontend, and it’s markdown influenced input scheme that allowed for fast keyboard centric documentation formatting that was then also reflected in it’s flat file backend which could then be easily exported as txt files to basically any machine environment conceivable.
Second I researched the vendor technologies that would be used. I poured the MuleSoft, Team Foundation Server, and ChangeGear documentation. These were the 3 vendors that we would start with as a proof of concept. I tried to map as many commonalities between these systems and discussed with stakeholders in what ways they used different parts of these systems together. The purpose after all was to integrate these systems together into a single frontend using the MuleSoft middleware API. What kind of information was useful in one app that was relevant to another app’s? What data-fields were repeated? What data-fields contradicted? Identifying the disjointed parts between these pieces would be necessary in order to build a system which properly filled in the cracks. Lastly, I began wire-framing. I like wire-framing with paper and pencil. Sure I can use wire-framing apps like Sketch or Figma, but I think that’s unnecessary considering the second step in this process.
2. Implement hi-fidelity UI mock-ups directly in static code using preexisting code libraries.
This is often my preferred way of working nowadays but this was also out of necessity. I came into work bright one Monday morning and was told I needed an interactive prototype delivered within 2 weeks for the CIO presentation. Our department needed to justify the existence of this project and it was thought that the best way to do that was to give something that could actually be clicked on.
One can debate this approach to design all day, but one of the realities of working in civic tech is that you are often working up against strong internal political constraints. Private orgs also meet these sort of difficulties, but while designers/developers can often make a profit-motive argument in favor of better approaches, it’s often more difficult or even impossible to argue with the structure of the civic org itself. Civic orgs pretty much all predate modern information technology, they were set up in the days of paper records, and horse drawn carriages. Imagine how different the United States Constitution would have been had it been written in the day and age in which a literal physical representative jumping on a horse to Washington DC was no longer needed!
So that meant knocking out a basic mock-up in 2 weeks. Here’s the great thing about code. It scales, and it’s often cheap or free, and easy to copy and paste. I purchased a static HTML/CSS/Javascript framework for 15 bucks and started mocking up the visuals for the wire-frames. Fully animated, built using the most up to date and modern frontend specs like CSS Grid and Flexbox, componentized functional SCSS and heavy use of variables for visual design scheming. It was a no-brainer. I delivered on time.
3. Build Angular 6 components in code to be handed off for developer use.
Once we had buy in from the powers that be, we needed to actually start building the project. Our frontend developers had selected Angular 6 as their frontend of choice. Like many other new client-side SPA frameworks such as React or Vue, Angular 6 has a focus on componentizing UI. My goal then was to further define the layout and design of the application UI, and do so in a way that fit into the developer’s pipeline. I had already started learning a little React.js on the side, so I decided to take a class on Angular 6 and actually convert over the static components from the UI mock-up into Angular components. This repo of code would be a living design system, code named: Limestone.
Along the way I also partnered with the Web Team to utilize their burgeoning Travis County ITS visual design language. While this had a bit some high up front technical requirements for me as a designer, I am convinced that this is a necessary step for the future of designers in our modern tech industry, and civic orgs can not be left behind in this paradigm shift. It wasn’t so long ago that code and design were handled by a single “webmaster” and I think we are going to see an evolution of that relationship between design and code. Can you paint without ever touching a brush? Well I won’t pretend to answer that question fully for you here (the internet already has it’s fill of those kinds of articles), but I am personally convinced that the design of a thing is necessarily situated in it’s medium, and if you want to design something, you have to get your hands a little bit dirty.
There’s not much of an ending to this. My contract ran it’s course, the project was not continued after I left due to a lack of funding, but the processes that I laid out stayed and I hope have continued to help guide the ITS department on their new projects.
As for me, I’ve continued to study and up my development/design skills. Following working at Travis County I stood up my own cloud server system and built an extensive set of processes for automating and containerizing my development/design processes. I’m currently digesting what I’ve learned and trying to integrate these things into a hackable design/development/non-technical-stakeholder deployable tool-set that can be adapted and used by many different civic orgs. I’m also looking for my next contract, and am particularly interested in working with civic orgs who are seeking to build smart scalable, well design systems that can be open sourced and shared with everyone.
