#MidCamp

We Redesigned Our Design Process, And You Can, Too! /

Chelsie Johnston

We Redesigned Our Design Process, And You Can, Too!

MidCamp 2016

#MidCamp

Welcome, thank you for coming. Hopefully you guys like to hear me talk as much as I like to hear myself talk...

Chelsie Johnston

Designer, Front End Developer

Web Services, The University of Chicago

@aimless_muse · chelsiejohnston.github.io · drupal.org name

About Me

A little bit about me:

More interesting facts about me: I went to college in the town where REO Speedwagon formed in 1969 (The University of Illinois in Urbana-Champaign)

Another claim to fame is that last April I was on the same flight to Rio de Janeiro as the fastest man alive, Usain Bolt. (I'm sorry to report that this didn't actually make the flight any faster.)

Chelsie Johnston

Chicago, IL

Other than those two fascinating tidbits of information, it’s probably also important for you to know that I'm a Front End Developer and Designer for Web Services at the University of Chicago. I’ve been there for about three years. I work on mostly Drupal projects— lots of site building, lots of theming. I designed built my first website at the age of 10 (it was an online Pokemon RPG, and the layout was made in Paint Shop Pro, sliced up into tables)

UChicago Web Services

Some stuff about us:

We're a smallish web shop that serves University clients
We won a Webby for www.uchicago.edu
Drupal as a service offering —affectionately named Templatron —multisite instance with around 400 sitesI'll explain a little bit about my department. We're a smallish web shop— we have around 25 people— and all of our clients are associated with the University of Chicago in some way. So: departments, graduate programs, research initiatives, museums, etc.— they don't have to come to us, but we're really well positioned to meet their needs since we're officially part of the University. / Some things we've done— we won a webby a few years ago for the main University website, uchicago.edu; we also manage and develop Drupal as a service offering— affectionately named Templatron— that our clients can spin up at a lower cost

So... perhaps you are wondering... why am I up here speaking to you about this? Who let this random girl in here?

Over the past year, I led the charge for reforming our ten-year-old process for designing websites.

I basically changed my department’s design process (and these weirdos let me)

I’m going to share my experience, in the hopes that you can get something out of it.

And that’s what I’m going to tell you how to do. I’m going to share my experience, in the hopes that you can get something out of it.

Who this is for:

Anyone interested in design methodologies
Anyone interested in process change

How'd you do that?

So... how'd you change your design process?

Anyone here tried to change a process before? Or start a new one?

Show of hands - anyone tried this before? (Narrate the reaction of the room vocally)

IT IS HARD :(

It is hard. Unless you are in charge of your own organization— it is not easy. But here's how it worked out for me. (pause.) I'm a millennial.

#millenial

I’m a millennial, so stereotypically, I love to change things.

Maybe you’ve seen this article. If you're a manager, then you have. If you're a millennial and you're as neurotic as I am, you definitely have.

(Credit: http://lmgtfy.com/?q=snake+people+chrome) ...Or maybe you’ve read the same article about snake people

But seriously...

"If I work here, I’m going to make things better (or I’m going to go somewhere else)."

The point that I’m trying to make here— and this is one of many ways I fit this stereotype— is that… If things suck, I can’t just let them continue to suck. If I work here, I’m going to make things better, or I’m going to go somewhere else.

I was fairly new to our department.

I was fresh enough to imagine a work environment where things could be different...

...but experienced enough in the department to see what about our process was currently not working for us.

I was also able to use my fork-like tongue to sniff out the fear of those around me and prey upon their insecurities to manipulate things to my own advantage.

I was really, really passionate. And I made a damn good case for what I wanted. Which was a sane design process.

Now, some useful background:

Our department has 25 people in it:

9 application programmers
5 designers/front end developers
4 managers
3 project managers
2 interaction designers
2 other

We still use waterfall…

Our Old Process

One “Design Lead” present during the discovery phase of the project
“Design Lead” would have a “Design Requirements Meeting” with the client
Three designers submit one design each in a DESIGN SMACKDOWN "friendly design contest"
Design Lead meets again with the clients after two weeks; client selects one for the three designs

I'm not gonna walk through this. I want you to know only that is complicated.

Old Process: Cons

Cost of doing this - in dollas
Cost of doing this - in time
Lots of design happening in a vacuum
Lots of the client's ideas getting lost in translation

Old Process: EXPENSIVE

One Final Design = Design Lead + (Designers * 3)

Sadness = 25 hours + (25 hours * 3)

Factor in time spent going back and forth with the client...

Old Process: Time Consuming!

Design Requirements Meeting = one day
Design brief deliverable = one week
Design Call = one day
Three designers designing = two weeks
Design presentation = one day
Client design selection & mods = one week
Revisions... etc. = the time it takes to grow a long beard
Client design signoff (approval to build) = one week

This could take 6 weeks, often longer.

Old Process: Designing in a Vacuum

Who wants to play telephone?!

~The mystical journey of client requirements~

Client -> Design Lead -> Designers 1-3 -> Design Lead -> Client -> Design Lead -> Designers 1-3 -> Design Lead -> Client -> Design Lead -> Chosen Designer

Old Process: Pros

Competition was healthy… I guess?

Our New Design Process

One designer joins the project team at the project's inception
This person is kept in the loop during the definition/documentation phase

When we think we know enough about the client's requirements to move forward with design, then the designer takes over for a few weeks.

The designer works one-on-one with the client in iterative, hands-on sessions.

Over a series of in-person meetings, the designer and the client work together to create the final design, which then gets approved by the client and built by a developer.

New Process: Pros

Cost of doing this in time and dollas is less
Design no longer happens in a vacuum; client involved in decison making
Client can build a sense of ownership over the product
Designers hate ourselves a little bit less

Out with the old...

One Final Design = Design Lead + (Designers * 3)

One Final Design = Design Lead

Sadness = 25 hours + (25 hours * 3)

Less sadness = 25 hours

More collaboration happens on the spot in design meetings, so hypothetically, there's less time spent going back and forth.

New Process: Cons

Some clients don’t like this level of involvement - it’s too much, too exhausting for them
Even though our design process changed, not everything about our overall process changed with it.

For example, we’re still using wireframes, which can communicate layout to some clients prematurely— this restricts designers’ creative power to make UX decisions

</background>

...How did you do that?

¯\_(ツ)_/¯

Actually, we started by complaining.

Complaining turned into an idea dump I condensed it into a much shorter Google Doc I identified how the main points seemed to emerge, and how they related to one another I talked to the other designers about it We drafted up some concrete changes based on our conversations I wrote out counterarguments to things in the document—and their counter-counterarguments I wanted to be prepared for every possible naysaying comment. Because of my lack of tenure in the department, because of my age, because of my gender— I was ready to be doubted. And that worked to my advantage.

"We shouldn't try something just because it's shiny and new."

The worst thing anyone's ever said to me in the workplace...

And so I became kind of this tireless defender of the new design process.

We brought this up the ranks of our department—I started by talking to the devs, building the audience as I went.

By the time this argument hit management, we already had several solid supporters.

Tips

#1: Get people angry—then use that energy for good

#2: If possible, get people angry on work time.

People need structured time in their workdays to think about nothing—to give them headspace for fixing problems

Essentialism: The Disciplined Pursuit of Less (Greg McKeown)

Front End Developer Meeting!

Every week on Friday, the front end developers get together and share the latest technologies and methods in front end development! complain for an hour!

This might not sound productive— but it can be. If you can talk about these things on work time, in a safe and honest space, at a regularly scheduled interval, you’re more likely to make something productive from it. It’s organized. You know what’s not organized? Having a giant ranting session on your lunch hour at the restaurant next door, only to quietly return to your desk and stew in your anger for the next four hours.

#3: Get a few people—the right people—on your side.

#4: Select your audience wisely.

Is who you're talking to the right person?
Is this the right time?
Are people ready for this right now?
Are you?

My roommate works in advertising as a copywriter; ad agencies will, believe it or not, have finalized copy before designing anything. We talked about this over drinks one night. And the next day, I spoke with some coworkers about how amazing it would be if we had content from our clients up front, before we designed anything. ...What if? But it wasn’t the right time. Nobody cared. People shot it down. There were bigger fish to fry. And besides, we have a hard enough time getting content from clients as it is, after we’ve developed an entire CMS. And I wasn’t ready. I wasn’t ready to defend myself. It had just been an idea. It was half baked. That was it. I knew what it would take to give an idea traction, and I hadn’t done any of it. So I let it go. For the moment. :)

#5: Always listen to criticism— and if it's relevant, do the thing.

Also, every process needs room to grow and improve when it first starts out. The only way we can figure out how to improve our processes is if we give them a test drive— see what’s working, what isn’t working. It’s a little painful— but they’re just growing pains. Be optimistic. If you really care about this as much as I'm assuming you do (if you choose to accept this challenge), you should want to understand the shortcomings of your new process. That's the only way to make your process stronger.

#5: Always listen to criticism— and if it's relevant, do the thing.

People will be less resistant to change if they feel heard.

Why?

Keep asking why until you get to the heart of the issue; eventually you'll get to a feeling

Every process needs room to grow.

Uber Pool is a new service that needs improvement in some areas. Anyone who's taken it knows that some rides are good, and some aren't. They're iterating on it.

#6: Take ownership. Even if you’re exhausted.

You’re the point person for this endeavor. You need to be prepared to answer questions at all times. You need to be listening, always— seeing how what you’re doing fits into the bigger picture of your organization. Because nobody’s paying as much attention as you are. You are responsible. Take ownership of this. Because it’s yours.

#7: And never forget—we are all just people.

People can be scared by change What if their jobs aren’t relevant anymore? What if there are parts of a new process that introduce risk?

In Conclusion:

Our process is still changing.

What’s next for us: refining this and other parts of our process, just like we did design

How our department has changed since changing our design process:

People have seen that change is possible
We've saved some money
Some people still aren’t convinced it's working— and maybe they're right. And I am listening to them.

The hows aren't as important as the whys.

Your organization is probably different than my department. You might have your own special flavors of bureaucracy or egotism to deal with. That’s normal. Don’t let that discourage you. What I want you to get out of this talk is the whys, most of all— why I believed this could happen, why it’s important… if you get hows out of it, that’s great. But the most important thing here is the bigger picture— the vision of what your organization could be. If you are really committed to that vision, people will start to notice, and your influence will grow. But it takes time. And you have to be unwavering. If you stop at nothing, you can influence things.

You can make things better— for yourself, for your coworkers, for your clients, for your fellow designers and developers and programmers and project managers...

Or—you can leave.

MidCamp Sprint

Sunday, March 20 at 10 am

UIC COMRB 909 S. Wolcott St

(across the street from the venue)

Contributors of all skill sets and levels are welcome and encouraged to join us!

Feedback

https://joind.in/talk/147a3

We Redesigned Our Design Process, And You Can, Too! MidCamp 2016 #MidCamp

We Redesigned Our Design Process, And You Can, Too! – MidCamp 2016 – #MidCamp

chelsiejohnston

We Redesigned Our Design Process, And You Can, Too! – MidCamp 2016 – #MidCamp

0 1 (function() { var po = document.createElement('script'); po.type = 'text/javascript'; po.async = true; po.src = 'https://apis.google.com/js/platform.js'; var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(po, s); })();