The selection of prototyping tools available these days seems to be endless. InVision, Framer, and even good old paper are great solutions but today I would like to rest my case in favour of code.
The Value of Prototyping
First, let’s take a brief glimpse into why prototyping is an important step of the design process. For those of us familiar with the Agile methodology, we realize the benefits of failing early and often. Catching our mistakes early saves the business time and money. If done correctly, this is where testing our hypotheses with prototypes becomes invaluable. The diagram below does a great job illustrating the feedback loop we get from prototyping and the time we save compared to building an MVP and analyzing our data afterwords.
Google Ventures Design Sprint http://www.gv.com/sprint/
Why Code?
I am a believer that the best results come from the closest medium to production. Many of the books I read during my studies advocated for paper prototypes and simple OmniGraffle wireframes. I agree that in the right circumstances these are beneficial but with the resources that are available today, you will see greater dividends by taking it a step further.
With a simple Bower command, some fake JSON data, and a ‘ng-repeat’ directive from Angular, you basically have yourself a Twitter feed. Not only do you have yourself a Twitter feed, but you have one that lives in the browser. Testing in a browser allows you to capture the nuances of the web and will provide you with accurate feedback.
The Pros of Code
Medium: First and foremost, HTML, CSS and JavaScript will always provide the most accurate feedback. If architects had the ability to build condominiums before having them shown to a perspective buyer do you think they would? Unfortunately it’s just not viable unless you have pockets deeper than James Earl Jones voice. Showrooms are the closest thing. They give the user the real experience of walking into their new home. 3D CAD drawings just don’t always cut it. (Although, selling condos doesn’t seem to be a problem in Vancouver).
Have you ever participated in a paper prototype session? Nothing feels intuitive.
Speed: If you are a sufficient coder, I would argue that code is just as quick as any other design tool. Avoid the rabbit holes and stick to the goal at hand. Use the browser as your design tool as much as possible and if you get stumped you can always take a screenshot and make adjustments in your favourite image editor. I find components and variables to be much easier and efficient to work with in code compared to setting up symbols in Sketch. Look to scaffolding tools like Yeoman to get started quickly.
Longevity: The web isn’t the flavour of the month. It is here to stay. Learning how to code may actually aid you in using the next best tool. I would bet that those without any JavaScript experience had a steeper learning curve when it came to Framer. Best of all, the skills you learn while coding will be transferable for the rest of your life. When Framer is no longer popular 2 years from now, think of the time you invested in that one tool.
Community: The resources available on the web for HTML, CSS and JavaScript are endless. Want to dive deeper into Rails or Angular? No problem. We all know about StackOverflow. Hopefully for a simple prototype you don’t have to rely on it, but it’s there if you need it. Many of these proprietary tools have poorly written documentation and you are more likely to encounter a problem that has never been solved before.
Wow Factor: Executives love seeing things ‘live’. Send them a URL and you will be praised. Many of them don’t realize the spaghetti code that lives behind that piece of art. (Note: If your code isn’t terrible, you’re doing it wrong). To them it means progress and executives love progress.
A Reference for your team: Lastly, in that giant mess of a code lies some hidden shortcut that somebody never knew about. It isn’t surprising for a developer to say something along the lines of “I like how you did that”. Alternatively, show a developer a mock up and they will think “how am I going to do that”. The prototype should NEVER be thought of as production code but sometimes there just happens to be an easter egg along the way.
Conclusion
Before you embark on building your next prototype and testing that new proof of concept, ask yourself if it would be beneficial to build the experience in code. Maybe it isn’t sufficient, or maybe your team just doesn’t have the skill sets to make it a reality. Code is not the only answer, I’m just saying it should be one of them. At the end of the day it’s about improving the product. As Steve Krug would say “testing one user is 100% better than testing none”.
Quick design I put together for the marketing team. Medeo is now available in the USA and it is required that you choose an instance to store your data. This was a huge engineering accomplishment. Proud of our team!
It’s not everyday that I get to put my iconography skills to the test. There are so many good resources out there these days that it is hard to justify spending the time.
Our developers just rolled out a new feature that allows practitioners to take screenshots of their RTC video stream. It’s main purpose it to take photos of patients and their ailments, which can be monitored over time. While wrapping up the feature, we couldn’t find a good example of a ‘screenshot’ icon that worked at a small size. I put my rusty pixel art abilities to use and came up with a few different concepts.
When coming up with visual designs for something non-trivial, I like to begin by looking at external sources for inspiration. When it comes to icons, I found the Noun Project to be one of the best. I like to think about keywords that fit the problem I am trying to solve. In this instance, the screenshot feature is actually a way to take a picture of your patient or capture a frame of the video stream.
I copy and paste examples that I like into my art-board. If I have a good idea of what I would like to build, I will start experimenting in Sketch. If not, I will break out the paper and pens and begin sketching out some rough ideas. I find it helpful to set some sort of time-cap for these types of tasks. If you’re a visual designer, you know how easy it is to get caught up manipulating individual pixels.
Once I have some concepts together I like to get peoples feedback and come to a decision. I will add my favourites to the UI element and go through the process. In this case, taking a screenshot.
My goal today was to give our existing Two Factor Authentication feature a bit of a makeover. The architecture of our users and their information is being redesigned and it gives us a chance to rethink some of the UI components as we progress.
2 Factor Authentication has been responsible for a large percentage of our support requests. It isn't the SMS providers or intuitiveness of the UI that is responsible for the requests. It happens to be the fact that a large number of users (more than we ever imagined) change their phone numbers.
We knew this would be a small issue from the beginning but because of our limited resource and LEAN approach, we never implemented "recovery codes" or anything similar. We were relying on manual labour and a set of security questions to disable the feature if requested. Today we have built a feature for our admins that allows us to disable 2 Factor Authentication.
Medeo Grounds. A style-guide and starting point for projects.
As multiple repositories came to life and our existing architecture began to grow; it was only a matter of time before a style guide was no longer a nice to have, it was a must have.
One of my initial attractions to Medeo was their attention to, and care for design. This came as no surprise as one of the initial investors was Andrew Wilkinson, CEO of MetaLab. MetaLab was responsible for the initial designs and as expected, they were pixel perfect. But behind those beautiful designs was not a whole lot of reusable code.
At QHR, we follow agile methodologies and work iteratively to reach our goals. Third party design agencies are a great solution for many companies but for ourselves, an in-house design team eventually made sense.
Since then, we have done our best to write reusable and maintainable CSS when necessary. But as the saying goes, “the amount of people that can effectively write CSS on one project is one”. As a designer and sole contributor of CSS at Medeo the frustration sets in when beautifully crafted components begin to be replaced by specificity.
Sometimes you just have to swallow the pill, no matter how much it hurts. Spaghetti code, page selectors and the dreaded !important property are sometimes what it takes to quickly prove business value. Thankfully as our team has grown and business requirements have changed, a living style-guide or “UI toolkit” has become a necessity.
In December we started putting together a roadmap to make Medeo responsive for practitioners. The plan was sparked by 'secure messaging', a new feature that had recently been launched. Until then, the Medeo experience for care providers had strictly been limited to desktop. Messaging is almost inherently mobile, so we set out to build an MVP.
We decided that the majority of the work was to be done using CSS media queries; hiding features that we didn't need. We also ended up building some custom templates and adding one additional route for replying to a message. The decision making process could really be a post of its own, but we have used options in the past such as RESS that we didn’t find suitable for this feature
We knew that performance would be an issue with our initial MVP. There were many components being loaded in the background that we didn’t necessarily need. We held off on going the extra mile until we could validate usage. We also had higher business priorities arise. In the end I was pleased considering the amount of resources and time that went into building the feature.
UI, UX, web, graphic, interaction, product, creative, unicorn. These are just a few of the titles I see thrown around for designers these days. In my mind, there seems to be 3 distinct roles within the industry that businesses are looking to fill. Let me share with you what I think they are, and the differences between them.
Web/Graphic Designer:
Graphic designers were around long before the web. Therefore, the term was originally intended for print. When design became viable for the web, the term web designer was born. At the time, websites were very much static. Basically a digital representation of what a physical brochure might look like. Consequently, web and graphic design were very much the same, just measured in different units and done at different sizes.
"Web designer" today could really include anybody who designs for the web but the term is still mainly associated with "making static things look pretty". Really these two positions can be extremely different but for the sake of generality I have lumped them together. I wouldn't expect a web designer to be an expert at 'die cuts' and a graphic designer might not know the screen size of an Iphone 5.
In a nut shell: web and graphic designers might be great at making buttons look fantastic and shiny, but they won't necessarily know where the buttons should go and what their intended purposes are
UI/Interaction Designer:
A lot of the time UI and UX are seen as one position but the truth is they are not the same. UI or "User interface" is just one component of a users experience. UI or interaction designers primarily focus on the paths or flows that users will take to navigate through an application. Their responsibility is to define the behaviour of the application based on users actions. "If somebody clicks this button: what will happen? where will the user go? why?".
A UI designers best friend is generally a Sharpie. Interaction is not always easily represented through static wireframes or mockups, therefore it is usually a requirement that UI designers have front-end development skills to be able to build prototypes. Many companies seem to be on the hunt for UI or interaction designers who also have visual design (web/graphic) skills.
UX Designer:
Simply put, UX is all about managing the experience a user has with your product. A lot of this can be contributed to Psychology. Many of the most successful products on the market today have become so influential on our lives that they are considered "habits". They weren't all built through coincidence. Many of the best usability professionals are Cognitive Science gurus. They care about user research and building products through data. This data is then used to determine design decisions (data driven design).
I see way too many UX job descriptions that have CSS3 as a requirement and mention nothing about usability testing or user research. *Red flag.
* This has become more in-depth than I planned but I hope that clears up some of the differences between the roles. This is simply my own outlook, you are entitled to your own.
UX Designer or a "Do it all" Designer | Understand what you need
Last night I got into a powwow with 3 very intelligent minds. I can't remember how it got started, but somehow I ended up voicing my opinion on the differences between web/graphic designers, UI designers and UX designers.
When I see job postings listed as "Graphic Designer" with requirements that entail wireframes and task flows, red flags immediately go off. It can be hard hiring a developer without having a CTO. The same can be said for design. "Designer" is an extremely broad term. I plan on writing a future blog post about the differences.
The most important piece of advice I could give to early stage start-ups is to understand the position that you need to fill. Don't hire a UI designer because everybody else is. Maybe you have a front end dev on the team who is more than capable of creating a great GUI. In that case, maybe all you need is someone to create graphic assets (graphic designer).
If you are at the stage where you can afford to bring on a UX designer, great! If I were to hire a UX designer I would be focused on how they have used user research and data to implement product changes. What were the results? How did they iterate on those results? What sort of user research/testing have they done and how did that affect their design decisions? What is their lean design process?
There are plenty of other questions I could ask but the point is, how did the user affect their decisions. Not, can they create css3 gradients. "Cool" or original UI can be created by any creative mind but functional and effective UI cannot.
'Lean' and 'startup' go together like bread and butter. When it comes to UX, i'm hard pressed to find anybody who follows the entire UCD process. That goes for both large and small businesses. Each designer and team has their own take on what's best for the business. A lot of the time that means stripping out documentation, minimal user research, lo-fi ideation. You can learn more from Jeff Gothelf's book Lean UX.
What the hell does this have to do with Daniel Day-Lewis ? Well, when it comes to UX, putting yourself in the users shoes is half the battle. Who does this any better than Daniel Day-Lewis? Daniel doesn't just play the role of his character when he is filming -- he lives his character, day-in day-out. Oh ya, it's also led him to win 3 Academy Awards for Best Actor.
I think we can learn a little from this. Do a little research, put yourself in the users shoes. Not just at the office but in everyday life. "Design doesn't happen in a vacuum" (I had to say it). This doesn't involve any personas or focus groups but it does involve dedication. I'm not saying it's easy but it's just an opinion.
