Writing about working ON a department instead of specific work that was done IN that department typically isn't in a UX portfolio. Knowing this, I still include the journey because of how valuable the exercise has been in developing my outlooks and attitudes of being part of a design team.
Interval is a company that started in the late 1960s and has continued growing ever since. As most large companies did in the 1980s and 90s, they built a monolithic 'IT' department that houses many disciplines. Web designers, Information Architects, UX Designers, and mobile devs are IT. The same way Java devs, AS400, Enterprise Architecture, and QA teams are IT. This leads to issues.
The web department used to get 40 page Word documents of requirements that often prescribed solutions like "add a button above X to the Y page". IAs, UX, and Designers didn't have a seat at the table to weigh in on solutions and the work being delivered made this painfully clear.
Reluctance to Change. I think I heard "we've always done..." or "historically, we always..." hundreds of times. Corporate companies with many employees that have worked at the same place are ripe for this behavior. It isn't uncommon to talk with people that have 20 or 30 years tenure. Nobody wants their cheeze moved.
Carving out a department from an already established structure inside an IT department is harder than just starting from scratch. Everyone defaults to old behaviors and even though they know that processes have changed, they "forget".
One unexpected hurdle is team members had gotten comfortable over the years. Low-quality work that takes too long to produce is often borne from complacency. It's hard to rise to the occasion when historically all ideas around innovation or modernizing our processes fall on deaf ears, so underperforming team members are to be trained and educated on ways to be more efficient and produce higher-quality work.
Making a change in a large organization is helped a ton by getting initial buy-in from someone who does have "a seat at the table". We were able to get the support of an AVP that saw the benefit and potential in shaking things up.
Having an ally looking out for your team solves many problems.
This is possibly the most time-consuming and difficult step, which begins with answering lots of questions.
What do we currently do? Establishing what actually happens in practice instead of what's supposed to happen according to some document created a long time ago says opened a lot of eyes.
What do the major players do? Huge companies have spent millions of dollars and hours working on processes, so we don't need to reinvent the wheel. We read about Google, Facebook, 37 Signals, Twitter, InVision, and countless other companies that have shared their way of doing things.
What works for us? After reading about so many different approaches, we distilled down the best practices we thought would be most effective in our environment.
How does it feel when we try it on? Once we crafted our process gumbo, we picked a small project that didn't have any timeline constraints to test the new approach. The soft-launch let us make lots of little adjustments to parts that couldn't be foreseen without actually going through the exercise.
Part of implementing new approaches for living style guides, more consistent interface design, and shared component libraries meant moving to machines for which the developers support.
Our 6-year-old Dell workstations running Windows 7 just weren't up to the task, so we pitched and successfully got funding for 27" iMacs for all 16 team members.
While this is a significant investment, the amount of hours we calculated would be saved through efficiencies from the new process should offset the additional cost within 13 months - a crucial piece of data that .
We established 2 big goals for the team that required software changes:
1. Maintaining a living styleguide and component library that are available to all designers and front-end developers, whether they're on our team or not.
2. Introducing and leveraging a rich prototyping platform for testing features and workflows pre-development.
After testing and discussion throughout the team, which was used to designing in Photoshop, we selected Sketch to be the vector design tool and the Craft plugin for InVision integration.
The IA/UX designers currently use Axure for building wireframes and we will continue to use this early in the process. Microinteractions will now be prototyped in Principle for Mac to get isolated animations perfected and approved. Once a project is ready for higher-fidelity prototypes, we had a hole that will now be filled by InVision Studio or Adobe XD, depending on the project type and type of interactions needed.
Without updating the hardware, we really wouldn't have been able to hit either of these goals in a sustainable way, so these 2 steps really go hand-in-hand, with the former informing the latter.
About 3/4 of our designers require some kind of training. Many fell into the 4-10hr training bucket, but we had a few team members that required 40+ hours of training to get them up to speed. I learned a lot about keeping current by seeing how far someone can fall behind in only a handful of years.
Training is split up between reading articles, completing Lynda courses, and following tutorials. There are infinite training resources on the web, so we were able to come up with a personalized training plan based on the holes in skillset for each person.
Ultimately, the biggest contributing issue is no formal budget for training. Not only was there no reimbursement for conference registration, travel, etc, you were also required to take personal days off to attend. Lack of dedicated resources to training is the biggest reason that people didn't stay current - I mean, if its a choice between going to the beach with your family or going to a conference with your PTO, it's a hard sell to get someone to go to a conference. We are working towards getting resources allocated to remedy this in our department so that we don't keep falling behind.
Spending time on processes and approaches are great, but the team still feared a quick regression to old behaviors by departments we would be interfacing with. To reinforce everything new, we involved the whole team in re-branding the department. Everyone submitted name ideas and logos, which we voted on. The XPERIENCE team has a unique logo and color scheme to be used in pitch decks and internal promotional colateral, name plates, and email signatures. The space the team shares is made visually unique with paint and wall graphics.
The final phase of the plan, an email is sent out to the whole of IT letting people know about the new processes and inviting them to the open house event.
Organizing an "open house" is a great way of showing off the newly-branded space and giving an opportunity for people in multiple departments to come by and ask questions or learn about the changes that are being made.
I learned so much taking part in this process about crafting better processes, finding ways to make change, and ways to improve myself.
Not everything is going to be approved. Not everything can be done at once. Working in small phases shows that you aren't just asking to change everything and also gives runway to demonstrate wins along the way. Running a tiny study that leads to implementing small changes that improve numbers for the business will prove the worth of modern UX practices. It's crucial to have an attitude of "don't just take my word for it, here's the data".
People are reluctant to change. Part of the reason a department can go downhill is avoiding all conflicts and allowing bad habits to creep in. Creating a culture of "See something, say something" is a big part of executing the plan of the new department on a day-to-day basis.
It's guaranteed you won't get everything perfect along the waay. It's ok to be wrong. It's ok to make a mistake, own it, and move forward. Trying to hide the results of a study you didn't expect, or show that the new version actually performs worse than the old one, is a death wish for your budding new department. Transparency builds trust and trust is the currency you cash in to continue to implement your UX practice.