A Tale Of Surviving In The UX Wilds

What to do with no tools, no budget, and no direction In this post Dr. D. Ben Hellar, a Senior User Experience Engineer at Next Century Corporation, reflects on his experiences with designing from paper sketches straight to prototypes. While there are some downsides to designing this way, Ben finds useful methods to make his efforts successful. I remember back in college, I had a liberal arts professor who would give out “Survival Scenarios” as a means to teach creative thinking and leadership skills. The premise was simple. You were stranded on an island where you had access to a handful of everyday things. Using only these objects MacGyver your way to safety! I was reminded of this task, as I was recently assigned to a project where I was given no tools, no budget, and no direction. Ask yourself, how you would survive the following UX disaster scenario (cue twilight zone music): I’d ask Wilson for advice, but he’s not chatty today.“You have been stranded on a project, where your only means to design are a whiteboard and Windows 7 desktop machine. Your only direction is to help the development team build an interface for a prototype tool. What do you do to survive?” To make this fun, here are some additional restrictions: You cannot use your personal machine, nor are you allowed to work from home and then email yourself work. You do not have administrative privileges to install software on the Windows 7 machine, nor is there a budget allowed to request additional software. Your project is business proprietary, therefore no cloud services or storage are allowed. All designs and files must be kept on the local network (that you can only access from that Windows 7 machine). You do not have access to the intended user base for the prototype, “They have important jobs, and are not to be bothered” Your only subject matter expert is a senior developer who “has been around long enough to know generally what they want”. Your development team is largely backend focused and has limited front end development experience. Ask yourself — what would you do in this scenario? Eliminate the Impossible “..Eliminate the impossible, whatever remains, however improbable, must be the truth” is a quote from Sir Arthur Conan Doyle’s A Study in Scarlet. While I am no Sherlock Holmes, I found myself whittling away at the possible UX approaches for this project until I finally arrived at a potential solution. This was my process of elimination: Paper Prototyping For a while, I debated the viability of paper prototyping, which is a commonly used UX technique that is useful for getting product owners and other members of a team to think about user workflow. However with a team that was inexperienced in front end design, I needed to produce more than a simple drawing, and sketching exercise to convince them of implementing my suggested designs. Low Fidelity Mockups The restrictions of this project forbade access to a budget and the use of external tools. This meant that I had no access to my typical UX design suite, tools for wireframes; such as Balsamiq and Axure were not going to work for this project. The business proprietary nature, also meant tools external to the company network were forbidden. This meant no web-based design tools would be allowed either. High Fidelity Photoshop or Illustrator Designs The same budgetary restrictions meant little to no access of the Adobe suite, many a UX’-ers bread and butter. PAINT.NET was the closest freeware alternative that I was granted access to on my Windows 7 machine. While I could have made it work, this was the equivalent of being handed a pair of scissors and being told to go cut the grass. Decision Time Instead of any of the above choices, I opted to build mockups directly in HTML and CSS. I wanted to leverage my previous experience in building front end interfaces and create mockups that could be implemented by developers who weren’t used to working with UX. I wanted to lower the barrier of communication as much as possible between myself and the development team to ensure that the developed software matched the intended design. Jumping Head First into HTML / CSS For those that are curious about how I built the mockups in HTML and CSS, this section is for you. If you are not of the mindset to care about the inner workings, feel free to skip to the following section where I discuss my lessons learned. Developing for the Web without a Web Server The restrictions of my project meant that I had to use a Windows 7 desktop and did not have access to a web server to deploy my JavaScript code, which I needed for mocking up popovers, typeaheads, and other business rules and workflows. This led me to select AngularJS as my JavaScript MVC of choice. This library allows for the dynamic including of JavaScript and HTML templates that can run in the local browser without the need for a full web server. They work natively in Firefox, and with Chrome you can get the pages to load so long as you disable the security features to allow the browser to access files from the local system. My Favorite Text Editor — Notepad++ Next, I needed to setup my development environment. I had access to Eclipse and other heavy duty development environments. But for my purposes all I needed was a simple text editor with syntax highlighting. Fortunately, I was able to download and use Notepad++ as a simple, easy to use (and free!) alternative. Gathering the Usual Suspects of Front-end Design Next, I started gathering the open source JavaScript libraries that I would use for the interface design. For my project, here’s a quick list of the front end stack I ended up using: AngularJS (v1.5.X) — my JavaScript MVC framework of choice Bootstrap with its responsive grid layout and helpful CSS classes Angular UI — Angular UI is the AngularJS rewrite of the jQuery Bootstrap UI functions, useful for providing functionality such as popovers, modals, and input type-aheads. FontAwesome for everything iconography. These technologies allowed for me to build a near complete mock website with functional workflows. I was even able to create fake data sets in JSON and stored locally in AngularJS. When the interface was ready for evaluation, I zipped up the entire directory and sent it directly to my developer team and product owners. Firefox was available on all machines, and so everyone was able to view the mockups without hassle! Reflecting on my time Every UX project is unique. In some projects you have supportive product owners, developers, and resources available at your disposal. In other projects, you may be faced with combative developers, or product owners that won’t give you the time of day. In the case of this previous project, I had supportive developers and product owners, but I had no resources and had to scrape together whatever means I could to make the project successful. The Advantages of Designing in the Browser Looking back at my time on this project, the primary benefit of designing in HTML and CSS is how it bridged the gap between developers and UX. In a typical project, I would output a collection of mockup images with a style-guide and “toss it over the fence” to the development team. From there, the developers interpret interactions and reverse engineer the mockups to the best of their ability. Often I would have to revisit their work, to adjust the developed software to look as close as possible to the intended to design. However by building my mockups in HTML and CSS, the developers were able to inspect my code and recreate my designs wholesale. The developed interfaces were near identical matches to my original mockups. Many times the developers straight copied my CSS or HTML code! This dramatically shortened the time it took to produce “production ready” software. But perhaps the most important benefit from this process was the trust that developed between myself (UX) and the development team. Whether it was because they considered me to “be one of them” because I could code, or simply because my work made their life easier, I cannot say. But at the end of the day, the developers trusted in my decisions, and I had less squabbles over minor decision tweaks, than in any of my previous projects. The Drawbacks of Having your Head in the Code Of course, designing in the browser isn’t all gumdrops and smiles; there are plenty of drawbacks, of which I’ve highlighted my top 3: Narrowed Vision.As a UX professional you can feel your vision of the overall product narrow drastically as you become concerned with the minutia of how to get pixel perfect alignment, or tracking down CSS bugs. This focus can cause you to lose sight of the overall workflow. In my project, I often jumped at new problems, trying to build a new solution instead and asking “how” instead of first asking the more important question — “Why?“ Additional Overhead.When development eventually outpaces the design of the mockups, there is additional overhead for the UX team to constantly update the mockups to the latest state of the interface. This was especially true in my project, as my mockups were used for demo purposes with customers in lieu of the actual prototype. Managed Expectations.Conversely, when the design work outpaces the development work, I found the Product Owners and Customers can get overly excited by the promise of a new and “sexy” interface. Their enthusiasm brings with it the need for additional explanation as to why the current prototype “doesn’t look” like the new interface. “The mockups look so real that they must be easy to implement” — which is not always the case! Final Words I hope you have enjoyed my cautionary tale of surviving in the UX Wilds. If this happens to you — don’t panic, don’t be overwhelmed, and most importantly don’t doubt yourself! While resource problems are challenging, they can be overcome. Simply keep moving forward, and solve one problem at a time, until you eventually reach success. More About Ben Greetings friends! My name is David Benjamin Hellar and I am also a proud alumnus of the Penn State College of Information Sciences and Technology, having graduated in 2004 with my Bachelors Degree and 2009 with my Doctorate. I work full-time as a Senior User Experience Engineer for the Next Century Corporation, a small government contractor based around Columbia, Maryland. There I design and architect interfaces for large data fusion systems and big data visualizations.