Published on | Prototyping: From UX to Front End — Medium Mahesh Kumar

Rather than thinking in screens, we are now thinking in stories.

So, I wanted to tell a brief story of my design process which I did for a B2B web application product at my current company.

To comply with my non-disclosure agreement, I have omitted and obfuscated confidential information in this case study. All information in this case study is my own and does not necessarily reflect the views of my company.

There are no stupid users. Just stupid products.

We need to build a product which will solve the user problems along with making it easily usable. We must know what, why, for whom of the product to make it successful and meaningful.

Product Objectives:

What— Product is related to desktop applications statistics.

Why — To know about the applications in one’s company and managing them, in turn, saving a huge pile of money to enterprise every year.

Who — Administrators of the enterprise companies.

We, at our company, are building this product for a concealed person (let’s call him, John) where it not only solve his problems but also the people playing similar roles in other companies as it has a great market potential.

Research

Stakeholder Interviews

I had a small discussion with John along with my management regarding what they wanted to solve and achieve through this product. I made it be clear on their Business goals and Revenue stream specific requirements of the project. Later on, I discussed the Technical requirements with the product development team.

User Interviews

I need to focus on what users want. The user interviews will reveal which design ideas will work, which won’t and may even inspire new ones to me. I had a conversation with John along with the administrator of my company about the results and tasks specifically their goals which they expect from this type of product. We had a good exchange of ideas to be noted.

I will be doing User surveys using TypeForm or Google Forms if I am short on time or the users are not in reach.

Competitive Analysis

Understanding the competition is crucial as it can provide a way to better understand the users. Moreover, if every other competitor product has a certain feature, users will obviously expect that on our product too. Sometimes, this can provide material for me to ask in user interviews and surveys, such as how they felt about this aspect or is it needed at all. I made a list of good features and task flows from analyzing those products.

Credits : https://www.linkedin.com/pulse/competitor-analysis-simple-how-to-guide-get-started-hariprasad/

Assumptions and Features

People don’t know what they want until you show it to them.

So, apart from research, I will be thinking on my own to improve the product for the user. I thought of what will be the most effective area to break into the market and differentiate our product from the rest. I also made a list of features which will be best to use and needed to the product.

Empathize

People aren’t trying to use computers–they’re trying to get their jobs done.

We need to know what our user goals will be in different scenarios to get their jobs done. We are not doing it right, if either the product didn’t meet the user goals or the user is facing problems in their jobs to be done.

User Personas

Personas will be the go-to thing we will refer to when making key design decisions related to the product. The psychology, behaviors, and demographics of target users feed into these personas.

I have created the user personas in view of the target audience. I’m not a fan of writing location, about family and hobbies etc. in the personas. I will be giving importance to the persona behaviors, technical level, frustrations, needs, and goals.

Credits : http://www.keepitusable.com/blog/?p=3428

User Stories

I phrased a few simple sentences visualizing the user in mind to meet their goals. These stories will detail the user’s motivations and needs. The sentence format will be:

As a [type of user], I want [a feature] so that I can [complete a goal].

User Scenarios

Scenarios tell us in what situations a specific user story might occur. We need to explore different contexts so that we will understand which pages they go to, where will they click and for what they’ll be looking to accomplish. I had visualized certain scenarios of the user using the product to get better features.

Credits : https://spin.atomicobject.com/2012/11/26/content-without-context-is-dead/

Customer Journey Maps

People do not launch an app to spend time learning how to use the interface, all they want is to complete a task in a short amount of time as possible.

The user needs to have the best experience while using the product i.e while performing the required tasks. So I prepared specific user goals and what they will be expecting from it, how the process is happening to achieve that task, how will be the user feel emotionally inside while doing it, is anything there, which we can improvise in this particular stage of task accomplishment.

Credits : https://cloudsmallbusinessservice.com/small-business/best-customer-experience-software.html

Red Routes

Humans are strange. We like to say we want as many options as possible. When we get them…we get confused and can’t take a decision. Hick’s Law predicts that the time and the effort it takes to make a decision, increases with the number of options.

I’ll prefer doing Red Routes instead of Prioritization Matrix as they both serve the similar purpose. This is where I prioritize the features by sorting, considering the factors like all, most, some of the time used features by all, most, some of the users.

Credits : https://vvmahesh.dunked.com/coming-soon-app

Information Architecture

User Flows

I made a chart for User flow regarding different goals and tasks the user will perform. The flows focus on how the user will go through the design for the required outcome. Occasionally for the same task, a user might either come from the direct traffic or from an organic search result.

Site Maps

Though site maps and user flows seem similar, they cannot replace each other. Sitemaps represent the product contextual structure, whereas user flows reveal different ways of navigation to accomplish various tasks.

As the product is immense, the complexity to structure the pages for navigation is also high. Based on user flows, I went step-by-step by creating the primary navigation and by adding sub-pages to them in a visual hierarchy.

Credits : https://dribbble.com/shots/1214553-Mindlab-Sitemap/attachments/162479

Page Tables

As I had decided on the pages in the sitemap, I listed out what content should be there and what and all are needed in each of the pages.

Credits : https://vvmahesh.dunked.com/coming-soon-appFeature in detail process

Conceptual Design

Sketches

This is the quick and easy, simplistic way to represent our ideas in the form of rough hand-drawn sketches. I will be using Sneakpeekit to outline my most of the project sketches. Then I’ll be creating paper prototypes to explain the navigation flow.

Iteration

Wireframing

Good wireframing makes the transition to hi-fi design smoother, saving valuable time and effort. The wireframed pages will be like the bare-bones structure for the content. After the iterations of paper prototypes, I built the wireframes using Balsamiq tool and created a clickable prototype using Marvel app.

Wireframe for a page

Iteration

Detailed Design

Style Guide

During the design phase style guides encourage consistency in the visual identity and help keep the interface system as logical as possible, which makes for a better UX. The user need not have to think and understand about the page when he comes across a new one existing in the product if the language followed is consistent. That’s why we have Google’s Material design, Microsoft’s Fluent design, and human interface guidelines.

Components list for style guide

Lastly, less is more. The more colors there are, the less impact each individual color will have. I had created a style guide with all the components existed in the wireframe pages of the product.

Style GuideCalendar SketchesTime and Date selection in calendar

Interact with the Marvel prototype of style guide:

<a href="https://medium.com/media/15b7c93838f4cea33952307cf5807b96/href">https://medium.com/media/15b7c93838f4cea33952307cf5807b96/href</a>

Visual design

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.

Based on collected feedback from wireframing, I redesigned some features and screens. I had visually designed the pages over wireframes with the help of style guide and made a visual prototype to present and share.

Visual design based on wireframeDashboard view of the application

Iteration

Validations

User Testing

There is a big difference between how people answer questions and how they really do things.

We performed the testing by sharing the prototypes with John and a few admins for feedback. We had observed how the user is performing tasks and how many steps, the time it is taking for him to accomplish them. I feel that natural way of testing is more effective than listing someone to perform those specified user tasks on your product.

Iteration

Takeaway

New users don’t sign up for your product because they are excited about learning how your UI works. They signed up because they were interested in the value that you promised to deliver.

Available for Full-time design role.

Thanks for reading. For more UI/UX design that I’ve worked, visit my portfolio or Dribbble. You can even message to my Chatbot, I made for Facebook Messenger. If you want to contact me, visit my LinkedIn or just say hi at designer@vvmahesh.in. Hope you enjoyed..!

Bringing UX design beyond screens was originally published in Prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

Bringing UX design beyond screens

Cool stuff, every week

More Articles