Categories
0
Comment
During the heyday of IE6, frontend design was in murky waters. The frontend 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
tablefor 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 frontend 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?
Consider this scenario:
- you are the product owner of Siete Baracos (a tool that helps people with coffee measurements and ingredients)
- how will you inform the designers, developers, testers about the basic technical information of the product?
- thru a Technical Document, of course!
So here’s the basic format of the document:
Name: Siete Baracos
Description: Siete Baracos is a tool that helps people in making coffee thru measurements and ingredients.
- Website URL: http://sietebaracosapp.com
- Google Play URL: https://play.google.com/store/apps/details?id=com.siete.baracos
Platform: Web
- Purpose: Brochure
Browser
- Primary Device: Desktop Computer
- Secondary Device: iPad
- Lowest Browser Version Supported: IE 8
- Mobile Response: 768 px
Framework
- Bootstrap
Other examples:
- Template System (Python, PHP)
- CMS (WordPress)
- HTML (Bootstrap, Foundation, Web Starter Kit)
- None (Plain HTML)
Platform: Android
Device
- Primary Device: Samsung Galaxy Y
- Secondary Device: Any
- Lowest Version Supported: Froyo (2.3)
—
These basic information of the product acts as guideline and sets the context in which the product revolves around.
Now, team members will not blindly test the app using a device lower than the version stated.
October 2008
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.
User Research
- Input – research and requirements; output – design artifacts, actual product
- How did we come up with the problem and solution?
- Have one solution and validate with users
- Set target users; create personas
- Continuous user research
- Improve the product for both the business and the users
UI Review/Usability Testing
- Refer to Components Masterlist
- Refer to Usability heuristics
- Create metrics
- Create activities and tasks
- Create directions on how to assume a persona