Mike Smick UX Sketch Sub Page Image

Design Thinking

This is a story about how I used design thinking to save Washington University $150,000.

I was hired as a consultant for Washington University’s public affairs department. The position was to work with the editor-in-chief of their news organization to ensure their published online articles and other curated elements were compiled into a daily email called “The Record” which was their alumni recipient email list of about 40,000. At my arrival, The Record was generated from SharePoint into HTML, which then required a lot of manual work to get it to its draft state. After that, with the Editor, I would do manual changes often until the end of the day as the various stakeholders would approve the copy and the aggregate of other stories from national media mentions were decided and linked.

So this daily email, while not highly technical for anyone proficient in HTML and CSS, it included a day’s worth of changes that were edited incrementally and shopped around the office via print out. As I worked on this, I had other tasks in this consulting role, many of which were to enable writers to utilize media in interesting ways in their stories, working around the limits of their SharePoint system.

Once all the editing was finished, I would upload the final HTML into the email system, run test sends and if those went smoothly the email was scheduled. Done. Every weekday with few exceptions.


I couldn’t help but obsess about how tedious this process was. It worked and it got done but it was a case where you didn’t want to take a day off and create a hassle for people. A chain reaction of concern. And what about control? I believed the editor should have more control over their own schedule in the day. People should be able to craft words and publish them. No need to have an “HTML Expert” on a publication that’s basically the same formatting day after day. Flow matters in the writing and editing process. Technical hurdles disrupts flow.

The Solution

For me the solution was removing the necessity for me to edit HTML manually and put the editing power back in the hands of the Editor-In-Chief. And then some good luck….

I had gotten word that the web development team in the building were starting to implement WordPress as their multi-site blog platform. I’m a long-time WordPress designer and this opened an interesting door for me. If my department were using WordPress, I now could think of fun ways to evolve what had been a pretty clunky experience in SharePoint and make an internal WordPress application to generate ‘The Record’ from custom post data.


So this has already been established above, but I’ll reiterate. The challenge was the daily email publishing process required too many interactions, and the technical requirements were too high. The bar needed to be lowered to send out this communication every day, and the control over the editing process needed to be handed back to the editor-in-chief. And in the event of exceptions happening around the publication there still needs to be ways to do the manual work. Anything created needed to be trainable and the system could start out in prototype with obscurity, but eventually would have to be able to move internally. An added plus would be if the smaller edits could be done by sending an internal URL to stakeholders rather than printing out sheets for everyone.

  • SharePoint would export the stories as a partial newsletter, but the Editor would often change headlines for length and images would get swapped out for relevance.
  • While it would be nice to tie simple things to automatically generate like publication date, even that would change depending on if the Editor was working ahead for holidays so those elements were given their own metadata fields to be filled in.
  • Number of stories, number of events, number of news links could vary, but their formatting was consistent inside their respective containers.
  • Freeing up time for the newsroom meant that other cool design ideas could be considered that could improve the experience of their readers.


As this project was kind of a skunkworks deal, the ideation period was basically me and the consideration of a process I was already deep into for many months. So I was pretty close to it. I was considering the different parts of the newsletter and how they could be generated from plain text.

“How can I get this down to near-zero manual HTML editing?”

From SharePoint these content modules were generated either as actual story summaries or placeholder text. Thankfully they were consistently formatted every day, save a couple exceptions. Now exceptions can be scary and some people let them derail meetings or entire projects. But hang on…. let’s bring in an idea from machinists and welders: “If you can’t make it perfect, at least make it adjustable.”

There’s at least some manual work eventually in almost everything. So you focus on the 97% of the time when it’s predictable and just account for and allow fallback behaviors. And you also realize that part of the job will always a little finicky and some shortcomings forgiven as long as the user has control over their workload. Journalists are already used to dealing with idiosyncrasies of whatever content management system they use. I’m playing these things in my head. “Make it adjustable, make it faster for 97% of the time, make it so the back-and-forths are a lot more pleasant for the editor, make it as good or better than most CMS experiences.”


At this point, there’s enough to go on for building a prototype. Over about 10 days I built the app while still performing my regular duties. I would run into some challenges when dealing with conditionals, where the entire section would close up based on the existence of child elements. But essentially here was the thought process during the prototype phase:

  • Take the existing record template and turn it into a WordPress theme (match output syntax)
  • Create custom fields inside a WordPress post that allows the Editor to input all the data for each section. e.g. headlines, summaries, image URLs, events, featured, news links and today’s date.
  • As the Editor saves the post, the newsletter now has an internal URL that could be shared around the office via email. Edits could be sent back via email or the user could still print out their own sheets if they preferred traditional markup. (New option retains old fallback behavior.)
  • Updated builder could be introduced quietly, let the Editor do test runs and just ensure that they aren’t losing any of their previous methods.
  • A couple new procedural things will replace the dozens of previous steps.
  • New system allows for custom email designs for special events that could be selected from the dropdown menu. This would just be new or modified templates that might accommodate new content types and could be built on as needed over time.
  • Conditional elements inside other conditional elements – this is where I needed to consult another developer to implement the ternary operator.

So how was the Prototype received? Let’s just say, better than expected. About 20 minutes of training and the Editor was very enthusiastic about testing that day. And then testing the next day, and the day after that. After about 10 days of this, word got around with what I had built.


The test period was really days upon days of live production usage. Yes it went over fantastic and they never looked back. And while there were never any cases of software breakages, there were instances where I was given a request regarding the template. You start to think, ‘should I treat it as a manual edit or try to implement something into a different template that could be called up in those cases.’

Like anything else, you can treat those requests in terms of priority and discuss that with the user(s). Do you want that feature if it creates extra data inputs every time? How often will this happen. If this request will affect the output template, will it also add fields and require a new custom post type, or blank fields cluttering the existing post type?

The answer is over a few months, I did both. I modified the template in some cases, and just did manual edits in other cases. And it was about 5% of the time where I had to worry about that. My interactions with the Editor could be about these more meaningful things related to strategy instead of the piddly HTML work i was doing before.

Doing meaningful work for people that makes a big difference in their lives creates trust and personal satisfaction on both sides like nothing else can.

What about the $150,000?

I knew from the beginning of this project that there was the benefit and the risk of taking myself out of the situation and that would compromise my contract role given any budget assessment. After conquering that part of the work, I was able to do a couple other fun projects, but a few months of this new system working so well, I was given notice that the department had taken on some employees from another team and their budget had thinned out and couldn’t afford to pay a contractor.

And in the first time in contractor history (well my history) I was given a bonus while being told it was my last day. About three weeks’ pay and I didn’t need to come back to the office I could just relax as I submitted resumes to my next role. While on the surface that might not seem like a big deal, as a contractor at a university, let me assure it is practically unheard of and I saw it as an extraordinary gesture.

I left there with a smile on my face. My builder app would be used for the next two years AT LEAST. No need for another consultant and no need for much of anything save the occasional special HTML edit. That’s how it was put to me anyway when I checked in 18 months later. So I’m quite confident I saved the university at least $150,000 just from my salary and I’m being conservative given the cost of contractor overhead and usage of my app beyond the two year mark.