While checking the NAP (Name Address Phone) details on my clients location in Google Maps, I saw a clear case study for implementing Schema data with proper markup code. No other work was done for the local business on Google maps, but we can clearly see a link to it’s menu. When this website was published some years ago, I implemented the markup on just the menu items to denote them as “menu”. This markup is used to better index information for findability purposes. Because every item on the menu page is designated as “menu”, Google knows that this is the menu page for this establishment, and has conveniently added a link to the menu page. This was done organically, meaning we didn’t directly tell Google to put that link there, but Google put that link there on it’s own.
The User Journey Mapping is not a documentary of every path of the user. It is meant to represent the typical user interactions to keep the design team focused on the user’s needs at all times. The map measures things like the user’s pain points to indicate where we should be focusing our time. Journey mapping can also be a measurement of success to upper management. It is a way to portray the user experience.
Two types of research can contribute to the journey mapping process:
- Analytical Research – Research from Google Analytics can be misread easily, such as a long amount of time spent on a page can mean they are delighted, or it could mean they are confused and stuck
- Anecdotal Research – Research about how the user is feeling, such as the retelling of experience on social media.
A successful journey map is based on the routine behaviors and a real desire to get to know the user on a detailed level. It also can be used to display behavior across different business verticals, such as the experience of moving between the online store and brick and mortar stores, or how the customer moves between departments of one store. Journey mapping allows us to view the total and whole experience of the user.
Presenting the Journey Map
There is no right or wrong way to present, but usually it is presented as a large infographic. It could also be a story or video. The end result is to motivate the team to create products that are usable, and to remind the team who you are building this for.
So “requirements visualization” to me means the ability to look at the project and determine if you need to document simple workflows or create high end simulations, or something in between. I think ideas are born once we put them to paper. Paper is where ideas are recorded, copied, shared, and accessed by other people (sharing). Designing the diagrams representing the user paths feels natural on paper.
The reason I needed a clickable, “*medium-end” prototype for my health care app project is because the client needed to learn what they were asking for was not what they actually wanted. Paper diagrams with user paths would not have worked here because the client could not relate to paper, but could relate to clicking.
Mobile first web design is a design and code strategy that embraces the design and code of mobile FIRST, over the desktop. This means that designers design the mobile version of your website before designing the desktop version. Why is this important? Because we are no longer serving up a modified version of desktop to a mobile device. Instead, mobile is thought about first and that forces designers to concentrate on what’s really important. Mobile websites have to deliver the entire message but only in a space about 320 pixels wide (versus desktop 1024+ pixels wide). By thinking about how to deliver the message in such a limiting amount of space forces us designers to concentrate on what pieces of the message are the most important, second most important, and so on. By re-evaluating the hierarchy of the message, we are able to pare down the message to the least common denominator. Once we have comfortably arranged this information into a small space, then adapting the design for desktop actually becomes much easier. When the screen width becomes wider, we can rest assure that the message is already delivered, and we include only the additional information as more screen real estate becomes available.
It’s about saving bandwidth, and reserving the small mobile screen for delivering your undiluted message.
But it’s not just about the design, it’s also equally about the code. Mobile-first means that your mobile code is written first, at the top of your code sheet (CSS) so that only mobile specific assets are downloaded to the mobile device. When the screen becomes wider, then the code can gracefully add on additional images and text to the desktop that is more likely to have appropriate bandwidth to support that behavior. That way we don’t download unnecessary images to the mobile device that are not really appropriate for mobile.
Responsive web design adapts to any screen width. Web design solutions are not just for mobile, nor tablet, nor desktop; it’s for every increment of measure in-between these devices. There are so many devices in the wild that have internet capability, designing solutions per device is obsolete and ineffective. We designers design for every iteration of screen size that can occur. Having a solution that is adaptive and can move fluidly between screen sizes is the essence of responsive design. The design pours from one screen size into another screen size like LIQUID, so it fills the container without leaving gaps or holes.
Web Design for Any Screen Size
When talking about web design & development, the word design encompasses many things. The most outwardly obvious reference refers to the look & feel of your web site: the colors, the font choices, and the placement of image choices. But the word design also means how well the content is organized or how the user interaction flows. All of these elements have to work together.
Content organization refers to the term information architecture. It is the skeleton, or backbone, of your web site. Without a strong, organized, & prevalent message, your web site will leave users confused and disoriented. They will not stick around to figure out what you are trying to say to them.
Get it up and running so everyone can see what it is that we are trying to build.
The same can be said about the user flow. When designing web solutions it is important to map out these interactions, build the interface quickly, then put it in front of users for testing & feedback. This concept is called rapid prototyping. The idea is that only the users can tell you what is going to work or not. By building quickly and getting faster feedback, we can avoid costly programming. Build the user interface first so everyone can see what it is that we are trying to build. Once all the user interface decisions are made, we can then move on to the heavy lifting called programming.