My UX Boilerplate
Ideas to peak ahead and get started with your UX Document

A case for bad coffee
It's early in the morning on the interstate and you have reached somewhere in delaware, taking a break for a cup of morning coffee and you are out of luck today. The only cup of java you could find today smells like cigaret ash and cardboard. If you are one of those people who own a french press or an espresso machine(so what if you never get to use it), you would find yourself bickering about this and almost every other cup of coffee you find in most cafes.
But like every experienced coffee drinker knows that it's just the first two sips which taste bad and everything after it just tastes like bliss. You get that going when caffeine kicks in and remind you of why do you put yourself through this and wakes you up to make you a better person, designer, engineer or whatever you do that brings you to Delaware for christs sake.
Having a reference point to begin with like the intuition of caffeine kicking in instantly(BTW it takes at least 20 mins to get into bloodstream, try telling that to your brain) gets me started through the worst few initial steps. Most importantly saves me from all those hours of pondering over how to even begin.
It's just your mind peeking ahead and driving you to the goal. All you have to do is start.
As a front end developer I always resorted to HTML boilerplates and task runners and smooth sailing from there on. Now as a UX Designer, my tool of choice is always the good old pen paper and lots of contemplation on which font pair should I use for my document or should I work more on visual design so that it looks prettier. So to bypass this clearly unnecessary foreplay I designed a UX boilerplate.
This boilerplate consists of rudimentary but equally important elements of every UX document. *I am also attaching some articles or publications which helped me understand these concepts and would keep updating these lists. This is my boilerplate which helps me peek ahead and kick start my UX document.
UX Document?
A designer has to communicate his design and ideas with people from multiple domains and explain the goals of the project and also somehow manage to interpret research findings and incorporate them in a simple dialogue which we call the UX document.
A UX Document consists of the artifacts and deliverables from a project. Artifacts are the relics from the design process to reach the final goal which is the deliverable. The things we consider as artifacts and deliverables are very interchangeable, best example of this would be wireframes.
Problem Statement?
It is a concise description of the issue that needs to be addressed. The main purpose of the problem statement is to create a focus point for reference during the design process. It is an humble approach of stating the pain point but not discussing the solution. It completely ignores the solution because many people try to work towards reaching the predefined solution rather than trying to look for a new one.
Problems statements in a way also quantifies the design process by defining what the deliverable should accomplish. UX design process is very iterative but problem statements seem to be one of the things which do not change during the entire process. This clarity adds more context to the design process and gives the design team a sense of ownership.
Designer’s indispensable skill: the ability to write and present a solid problem statement

A problem statement takes into consideration the context, clarity, measurability and feasibility of the project which is clearly reflected in great storytelling.
Storytelling?
Storytelling with respect to UX is basically a consolidated document which helps in understanding and visualising the user research. It could make use of journey maps, personas and empathy maps to depict customer experience and an empathetic view towards quantifiable data.
Personas:
Personas are anecdotal representation of the user based on all the learnings from research which brings about empathy towards the users. Personas make the design more personal and gives the designers the ability to have mental conversations with the users and the use cases.
Journey Map and Empathy Map?
A journey map focuses more on the customer experience and depicts the user's journey from discovery to solution. Pain points and users satisfaction are visualised in the journey map. Journey maps brings quantitative data to life.
On the other hand empathy maps focus more on qualitative data and try to elaborate what the users are feeling or seeing. I believe that the data points on which both these maps are based on have a massive correlation and presenting both these documents as a single entity would serve better to accomplish a clear picture of the user story.
Wireframe?
Wireframes in most cases are design deliverables and visual representation of the solution being proposed to the problem statement. They provide scaffolding to support the designers solutions. Wireframes can be low fidelity prototype or high fidelity.

Low Fidelity versions tend to be sketches or made specifically to look like they are rough ideas to make it easy for the users to test and critique. Test users might feel more confident to comment and critique a design they feel is well under development.
High Fidelity prototypes are working prototypes which have content and colour to propose how the design works with respect to the context and also tends to look a bit polished compared to the low fidelity wireframes. They provide proof the working concept and can be used to demonstrate it to different stakeholders.

Prototypes are always used to create perspective and using dummy text(lorem ipsum) is defeating the purpose. Proper use of context and annotations for the flow provide contextual awareness to the wireframes.
Thank you for reading Part 1, I will continue part 2 with photoshop templates and best practices.

