What kind of tech and enterprise work do I do?
When I first jumped into web design, my visual design background helped make the transition smoother. The web was starting to become a much more expressive medium. From interactive storytelling to text heavy websites, across the digital spectrum the web was booming. But the era of custom built agency websites, blogospheres, and custom designs was beginning to end, and the new era of Facebook Pages, site builders, and social media domination began chipping away at a lot of the entry level web makers.
Open
When my skill matured in web design and web development enough to be dangerous, a lot of my contracts with agencies ended. The industry changed fast. The economic crisis of 08’ didn’t help. Faced with the looming challenge of keeping employed, I kept pursuing more and more enterprise level UI work.
Mobile first web design was being introduced and in some places maturing. Pattern Libraries were being innovated on, and CSS influenced by Bootstrap continued to push and mold the development profession. Responsive design, web components, and JavaScript frameworks were exploding in use and in number. Some of these concepts I followed as soon as it hit the conference circuit. Some I was trained on. Much of it was a rehashing of tried and true methods of first generation web and the Web 2.0 era.
Even so, a lot of businesses didn’t care about all that. I saw this trend in university work. Attempting to convince these conservative institutions that there were benefits to modernizing approaches for internal apps and tools was a big challenge. Many people had yet to think of the costs associated with bad design. Many only focused on the surface level appeals of well designed interfaces.
Problem solving wasn’t even on the map for many places. Working with IT departments, slowly becoming more and more research driven, and evidence based, my skill set kept being sharpened to deliver results, despite institutional inertia against achieving any.
Open
By 2016 the profession and design leadership within it was paving the way for a more rational approach to enterprise work. It came at a big cost, large failures at Fortune 500’s, and big wins at big tech companies, as well as the explosion of web apps as internal tools, had pushed many companies 30 year old tech stacks to the breaking point.
IBM, Google, Amazon, Microsoft, and Apple had set a baseline for acceptable user experiences. From consumer products to enterprise tools, software had to work, had to be easy to use, and look good. Everyone expects things to just work. As a result UX and UI jobs exploded. It hasn’t slowed down.
Open
I was hired many times to be part of an internal design team, focusing on human factors and human centered design, research, and UX design. Each project and gig became bigger than the last, the problems kept getting bigger and took longer to solve. Complex business problems became the primary focus of my work.
One of my biggest challenges was convincing my employers that the cost of solving a problem, would be far less than the opportunity cost of letting that problem fester. A distinction lost among many, especially when nothing is tracked.
Human Centered Design and a In-Human environment.
Buzzwords abound in UX, but the one thing everyone is supposed to understand and work for, is solving problems. And yet, 90% of the time, picking the right problem to solve is one of the hardest parts of the job. Digital products and services, and their real world counterparts, all require the people that make these things a reality, be in sync.
When UX designers, developers, product people, and the various back of office individuals that make things work, get aligned on how to solve a problem, it’s very hard to miss the mark. But getting aligned is such a momentous challenge for many work environments.
I’ve often been front and center in the battle for supporting better alignment between different teams and craftspeople. I learned these skill early when I interned as a draftsmen. Design intent and reality often clash, and learning how the feedback mechanisms on the job site or at the engineers desk, are required for anything to be built.
In enterprise UX, large organizations have varying levels of maturity. This isn’t about 💩 jokes. A businesses product might be great, but its customer service might be falling flat, angering people whenever they reach out. Warehousing might be an island of bad experiences, accounting can’t count, or legal isn’t actually able to inform company policy. Disfunction is the enemy of problem solving and no company is perfect. Problems are made worse when they are hidden from sight.
Even when an enterprise understands that something is wrong, if you’re hired to research this problem, as I have been many times, you’re likely to be seen as a nuisance, rather than someone attempting to help.
Culture Change, Challenges, and lessons learned.
You can’t design out human nature, but when observing the enterprise environment, you shouldn’t focus on targeting specific individuals for the cause of a culture problem. A witch hunt is likely to be sparked in that scenario. What has worked for me, was to look past the obvious surface level problems, and to instead look for the existing incentives that cause these cultural problems.
I look for what tools, techniques, and feedback loops are broken. Rather than hit directly on personality driven problems that can cause those difficult political conversations, I focus on building a little empathy for the people attempting to make work happen. UX is a unique skill set for looking at tools and how people operate with these tools, and helps refocus the entire effort on how to incrementally make improvements outside the silos.
Open
There are a whole host of techniques I as a UX consultant can use to help start culture changes at an organization. But the real value comes in tracking the outcomes of this work. Answering the question, “How will we know when we have arrived?” Problem definition, research, problem solving, and execution demand at least an approach to measurement, and a way to communicate any findings up the chain of command. Enterprise UX is as much a product making exercise as it is a team building exercise.
Performance, and the bottom line.
When problems are defined, and goals tracked, you can finally focus on the job at hand. Solving those problems. This is what separates a lot of classic design professionals. Few have the patience to cut thru the long time horizons needed in large companies just to right the ship. Few care enough about the “boring stuff” of design, the endless meetings, political tact, and compromise needed just to make an incremental improvement.
But when it’s all cleared up, that’s when you really see the benefit of an enterprise environment, large amounts of resources are thrown at problems. Soon teams are coordinated to build products, services are mapped, and soon that designer that spent all that time navigating cloudy seas is now drawing up the map.
Because I can literally create maps, turning words and product definitions into visual designs, is something I excel at. Working within a team of designers, or as single contributor, I remove my ego, and design and refine. Sketching fast, and getting feedback faster, every second spend shaping user interface has impact on what is built. Every icon, every margin, every button, the choices already made before the design is created, each has an impact on the success of the product or service being shaped.
Open
Breaking up the work into small bite sized chunks, small cross disciplinary teams can take my designs and create concepts fast. I can then test these with the team present. We can all contribute to a solution after that. This democratization of design feedback allows the team to feel more involved in the refinement, and make sure the designer is kept honest with the technology reality on the ground.
Open
But sometimes your team isn’t small, and feedback per sprint cycle can’t be fully spread among a team. Between waterfall and agile there is a strange middle most companies find themselves in. This can lead to team friction. To remove this risk, a designer might have to step out of their comfort zone.
If developers aren’t available, I work with the product people involved to help gather business needs, and sometimes I can “fake” the technology layer to make prototypes work more like the final product. When built, these interactive prototypes can help the teams I work with “gut check” a direction. This in turn provides a strong piece of evidence, for or against, the success of a design sprint. Supporting development with inspectable code artifacts helps when the resources are free to wrap up final implementation.
Other times, designers like me can become the product person assigned on project, helping stakeholders and development shape a solution that would be hard to come too if all parties weren’t talking. When making software, at some point all the people involved will contribute to the process. Sharing knowledge is the key to making sure a collaborative effort isn’t put on hold when key contributors are not available.
If there is one thing I’m known for, its execution of work. What always seemed obvious to me as just part of the job, sometimes designers have a reputation for missing the mark and just not delivering. This shocks me, as I don’t think I’d get paid if this was true for me. And yet I keep hearing that I can “get things done” as an affirmation of my skill, and for doing good work in this craft.
Making digital products is a team sport. It depends on the whole team to deliver. I make sure I give it my all.
If your interested in more detailed examples of my work, check out these case studies.
...would be here if I added them.