In our team, we have something called an Interaction Diagram integrated into our Design Process.
Basically it is a collection of wireframes in context – whether of the whole web product or of a simple task or activity. The diagram shows the layout of components as well as their interaction with other components.
We’re using it consistently as part of our communication with web and app developers. It has proven to be very useful since its inception a year ago (October 3, 2013).
During the heyday of IE6, front-end design was in murky waters. The front-end designer would need to employ lots of hacks, patches, and workarounds just to achieve the look and feel of a grand mock-up. Remember:
when we used table for layout?
when we used a 1×1 transparent pixel as spacer image?
when we exported images as masks to make rounded rectangles?
when we used images as gradients?
These were just a minute part of the painful challenges front-end designers faced yet nothing stopped us from adapting to the crappy non-standard browsers of that time. We moulded the web into different appearances despite the difficulties. Remember the time:
when pixel fonts were in?
when DHTML was so fancy that sites had snowflakes falling on them and cursors were customized with trailing stars?
of Web 2.0 – the proliferation of badges, loading icons, fab aqua buttons?
of letterpress typography?
of minimalism?
when full-screen images is the template of all websites?
Some of us might only relate to the last item – which we encounter 90% of the time these days. But as for the other nostalgia, there really was a time when visual designers were advantaged with the knowledge of how to implement their designs in the front-end (HTML/CSS). Because otherwise, the visual design in all its JPG glory might be so much ahead of its time that it couldn’t be implemented properly without gathering a bucketful tears of albino unicorns.
But as browsers abided by the standards, IE dieded (best thing ever), technology fast-forwarded itself to touchscreens, and mobile had identity crisis – the lines of limitations blurred out, the doors and windows flung wide open. Suddenly anything is possible and this time standards, open source, and our respective communities are even more by our sides.
It is no longer a must for visual designers to know the magic of HTML and CSS. We can now sleep soundly at night knowing that the project’s full-screen parallax slider would be implemented properly. All we need to know are three things:
There must be someone for you to collaborate with who shares your vision and knows how to technically implement the visual design
Usability – if your webpage looks like a KFC flier crumpled on the sidewalk, it will be as usable on the web as it is on the ground
Anything is possible (you will find out if it’s not) so do your homework and thing
Who will tell you what mobile is and what mobile is not? Who will tell you when to use and when not to use a back action or a cancel action and whether it should be in text or in icon? We were almost sure that after iPhone 5 it would only get longer like a lightsabre.
With the stiff competition in the tech industry, we could only say that the best is yet to come. It’s no holds barred. And nobody could tell you anything anymore. Not “you can’t do that” or “you should do it this way” or “this is the best way to do it” – not even the guidelines of operating systems could strictly dictate how designers should design.
Who could tell that your 27-inch iMac won’t be touch-capable next year?
Who could tell that we won’t need a mobile-responsive webpage for a smartwatch?
Walk your own stride but watch out for falling debris.
It was a very early morning at 10 a.m. I was half asleep, half awake when a phone call jolted me from sleepiness. The signal inside the apartment was so weak that I went outside to answer the call. It was an invitation from Chikka for an interview.
A mere seven months ago, I resigned from a night-shift job and ventured onto the mountains – equivalent to working freelance without a clear business plan. The offer from the other line was a real wake-up call for me to set focus once again into designing for the web. The position being offered was quite new to me – User Interface Designer. I said that as long as it’s on a senior level, I was interested.
Web products need to be supplied with a Technocal Document. Its content are the basic specifications of a mobile app or website in the following aspects:
Filled-up by developer
Programming Language
Filled-up by product developer
Browser Version Support
Mobile Version Support
Filled-up by front-end designer
Mobile Response
This document aids all team members involved in the project by providing with a preview of each team’s specifications. It also puts in context the capabilities and limitations of the product.
Consider this scenario:
the mobile app is in its Behavioral Testing stage
the tester is informed that the mobile app is supported under a very old version of Android
the tester ensures that the mobile app is tested on all key versions of Android
The same goes for websites wherein each team member knows that the product will not be supported in IE versions 8 and below.
A UI Review is a testing methodology conducted by a designer (UI/UX/Front-end) on web products prior to Usability Testing.
The first aspect to be reviewed is visual design and the second is usability.
This is conducted primarily to ensure that the obvious negative findings in a Usability Testing are lessened.
Consider this scenario:
a working mobile app is available for testing prior to production (launch)
a designer will conduct a UI Review
the reviewer will take note of visual design inconsistencies and usability difficulties
the designer will revise the design based on the findings
the mobile app is ready for Usability Testing
It is recommended that a UI Review is conducted on a working product rather than on a prototype or mock-up because this puts the reviewer in the context of actual usage and not just a replicated one.
