About UX in software design
My Background
I work as a UX/ UI Designer, I design websites and complex systems for companies. Most of the projects are for internal use at big companies so I can’t get into details here, I sometimes do both the designing and the developing side of the products.
If it’s too complex of a system I’m usually either only the designer or given a clear and simple developing role like “Front-end Profile Page Developer” instead of just a vague “Front-end Developer”.
My skills are not only confined to HTML/ CSS but I also posses pretty good JavaScript skills, I even recently created a JavaScript library (MotionBlurJS) that can add motion blur to CSS animations.
Pivoting to Software Design
I’m pretty confident in my web development skills, so when my boss asked me if I know some software that can pause videos in specific timecodes, for presentation and instructional proposes, I just replied “no” and added “but I can build one”.
He was amused, I think, but he did let me the chance to research it, to see if any existing software was available to purchase, I did my research and after a week we had a meeting on the pros and cons of each existing solution.
The software had to be able to pause the video, make sure the viewer can read a message on screen or answer a question about the video, than immediately resume the video, all at predefined timecodes and with predefined content, of course.
I quickly transformed the meeting into a pitch to my own software solution and how I could build it with nothing but web technologies.
The pitch was very technical (which my boss loved, as he’s a technical person), I was diving into how the <video> tag works, how we can keep the timecodes synchronized with large files, how the file system will work, how we actually need two systems: viewer and editor, how we can make it work locally and online, even what the final product will feel like for the end user.
This meeting was really long with me doodling a lot on the white board, in the end I got the project, I will build the system using web technologies, it will take me 6 months and it will be an on and off project, intertwined with my regular work, I was ecstatic to make the step toward software design.
Fast forward 6 months…
The Roadshow
After all these time of development, we finally had a working beta that was tested and fixed internally, it was time to show it off to potential clients, my boss did all that deal making behind the scenes, and I only heard about our clients after the fact.
Now it was time to educate our clients about our software, show them how to use it, show them how it works and most importantly, listen to their complaints and feature requests.
This is what I called a Roadshow, it’s taking our attraction to the clients, it’s not about selling but it’s about learning how to use our product, which is far more interesting to me.
Actually using any piece of software, studying what works and what doesn’t for the users, is the reason the UX Design field was so interesting to me in the first place.
I went with my boss into the belly of the beast, a very large corporation full of people who tried my software beforehand.
They were eager to learn how it fits our pipeline and how it can fit theirs, the board room was overpopulated by them, I plugged in my laptop to their projector and hoped for the best.
“This is the Architect” said my boss and pointed at me, I liked this introduction as it did encapsulate both the development and design aspects of my work, I did all of it and it captured the design process as both the actual designing and planning of it, you know, as an architect might do.
The crowd was quiet and patient with me, some features I showed provoked a question but for the most part it went by without any major bugs or errors, I was so nervous showing it off after 6 months of development but everything went… fine.
Even better than fine, I later realized by their questions that they not only used our tool, but they loved it, it shaved off hours from their workflow and it made them not only faster and more productive, but they also felt much more accomplished and empowered by it.
What I Learned About UX and User Behaviour
This Roadshow continued to other companies and other users, they had a lot of feature requests and questions, some about our UI, some about the inner workings of the software, some were just general hopes and dreams.
I learned so much from them about user behaviour and how hard is it for them to change their behaviour, so I might as well make my software fit into their backwards way of working, here are some of my insights:
- Users are naming files to whatever they can: I know all files on all computers all over the world should be only English characters and with no spaces (like “image.jpg” or image_New.png”) but not only our users named files way too long and with spaces and periods in them (“way too long.name for a file final.final.jpg”) but also they made the filename in other languages, we had our software crashing for file names in Hebrew, Spanish, Hindi and more, we had to adjust for that.
- Users will surprise you with the options you give them, in our tool we had a user who found out she can make text bold by hitting ctrl+B on her keyboard even though we never intended it to be an option in some text fields, but it was built in and we never disabled it, so she used it everywhere, and I mean everywhere.
- Users don’t always know what an icon means, I know that’s weird but non designer people don’t always get general used icons like the Align icons, we got used to them as designers but if you’ve never used Illustrator, Photoshop, Figma or whatever design program you use, you might not recognize them, even in PowerPoint (the “design” tool for non-designers) the UI Design Team put a label beside every align icon (a fixed label, not a mouse hover label) so non-designers can easily recognize it.
- Again with the file handling as our tool is making users load up their video files, you have to be very specific about file types (mp4 file only, in our case) and most users don’t know basic information about their video file, not file size (in megabytes), not video resolution (in pixels, for example: 1920 x 1080) and some of them don’t even know the duration, they have a feel for it but I had users tell me their video was “only” 10 minute long when in reality it was 30 minutes long, I know, users can be so weird.
- Dedicate a place on the screen for panels, so users won’t accidentally press them all the time, if you must have floating panels for any reason, add these 3 features:
- make sure panels are draggable and always on top
- make sure your user can hide them at will (like pressing the TAB key on the keyboard, for example)
- make sure your user can bring them back especially if they don’t know what they pressed, for example add a button to the screen which definitely wasn’t there before to bring back the panels, keep in mind your user might have pressed TAB and than their keyboard stopped working so don’t just write “hit TAB on your keyboard” on the screen, give them a mouse/ touchscreen option.
- Users will always ask for more features you won’t do, keep in mind what your software is trying to achieve, always ask yourself or your team if it’s aligned with that.
- Don’t add features that are just a whim of some user. Users will ask for features all the time, without really thinking those through and sometimes those features will just divide your software’s UX into cross sections of users, bloating your software in the process.
- If you do implement a user’s request, try to predict what they meant and how a feature should be implemented, don’t take the request at face value. Imagine how it can be implemented into the pipeline your software creates without appearing to be an add-on that was added later.
- Consider how a feature should work in practice, did the user that requested the option to add links to a text area intended for the link to be opened in a separate browser ? in a popup browser inside your software ? the user might not even meant for it to be web links, he might wanted to link to a local PDF file, so make the feature work, don’t just do it to shut the user up.
- Give your users the information they need to discover what a certain button or a function do, most users won’t read the help documentations or watch tutorials online, make your features discoverable by adding a mouse hover label to every button, group them logically and place them only when you need to.
- Never make the user push a button when they don’t know what to expect and keep in mind that even though you’re designing software, it doesn’t mean you need an obscene amount of buttons, dials, checkboxes and other input methods, keep it simple and functional.
Summary
The users are your friends, you work with them toward a common goal, not against them, you all just want the software to be better for everybody.
UX Design and Software Design are really not that different as they both require deep understanding of user behaviour and a deep understanding of pipelines and common standards and patterns.
I think the most important thing I learned from this opportunity was to try something new, in this example I dared to take my role into a different direction that wasn’t in my job description, but more importantly that I didn’t know if I can deliver.
At the end I did deliver and I continued to build more specialized software solutions for a number of clients after that, but somehow I still look at this first opportunity in designing software and ask myself what was I thinking, I could have failed spectacularly.
Let me remind you that we all should dream bigger, if you only design for digital platforms, try to learn how to code for them, if you can code front end websites, you can try your skills in building desktop applications using Electron.
You can also build mobile apps using nothing but web technologies with Cordova or NativeScript, those platforms are just a few examples, there’s always a lot of them.
These platforms change every few years, I did bury a few in my short time as a software designer, but the idea is always the same, you can take the way you write code for the web and tweak it a bit to run as native mobile or desktop app, and that idea empowers everybody who work for the web, designers and developers alike.
