Requirements Gathering & Analysis
Discovery Phase and General Information Gathering
I usually start by asking key stakeholders or clients questions regarding the goals for the product we’re trying to design. It basically boils down to:
– Who are the target users?
– What are their (client/stakeholder) business goals?
– Expectations – what do they expect at the end of the design process?
– Considerations- things that I need to take into consideration when designing the product.
Research & Analysis
The next step in my process is to analyze given information. I conduct market and competitive research to see what similar products are out there. I also write a SWOT analysis to understand strengths, weaknesses and opportunities for the product that is being developed.
After doing my research and analysis, I then discuss with clients/stakeholders and start gathering requirements. This phase allows me to understand the features that we need to be taking into consideration when designing the product. Gathering requirements also allows me to envision how the product should be implemented.
Once I have all the requirements, I then start to document and write requirements specifications. I basically write user stories scenarios and user acceptance criteria. Additionally, I also create storyboards that provides non-technical parties the ability to understand users’ needs, their pain points, how the product can help and the best solution to resolve users’ frustrations.
The requirement specifications document will contain the following information:
1. Product purpose or goal– I always start the document stressing out the purpose or goal of the product.
2. User Roles– Majority of the time , there are several roles a user perform when using a product. For instance for Project Management application, the user’s role can be broken down into a project manager, a team member, client and so on. I always want to clearly define who the users are and what roles they will be playing when using the product.
3. User Stories– coming from an Agile background I always like to ensure that the story is clear and is written in a way that a non-technical person can understand.
4. Acceptance Criteria– For each user stories, I always want to make sure that the acceptance criteria are clearly indicated. This helps the clients/stake holders and team members envision how the product will function, how each function and feature will be developed and implemented. Writing acceptance criteria also provides me the opportunity to clarify features that were not clearly defined.
5. Task Flow– My requirements specifications always contain a task flow or a flow chart diagram to represent the process flow of the product at a glance.
After delivering the requirements specifications, I then collaborate with the stakeholders/clients or team members to identify what points needs to be added, what needs to be removed, what needs to be clarified and so forth. I take collaboration seriously as this provides me the opportunity to jot down new ideas coming from the team. Most of the time the process flow diagram allows the team to figure out items that they needed that were basically left out during the initial information gathering phase.
Design Phase & Heuristics
Point of View
I like to start the design phase with a point of view. Establishing a point of view allows me to visualize the overall perspective of how I am going to approach the design process.
After the point of view is established, I ask the client/stakeholder to provide me their design brief. Majority of the time, I end up writing the design brief myself and just have the client or stakeholder review it to make sure we’re all on the same page.
I start my design phase doing lots of sketches and wireframes. I usually create paper wireframes because these allows me to analyze which design pattern will work best for the product. Paper wireframing lets me create multiple design alternatives in a short amount of time. I also like to sketch interface and visual elements that comes to mind. I often times doodle my icons and use these doodle sketches to create high fidelity graphics.
After sketching and wireframing, I then start to create a low fidelity prototype using Balsamiq.
Rapid prototyping, helps me put together a quick interactive design. Thus, allowing me to quickly get feedback from stakeholders and team members. It also lets me make quick changes before really diving into the visual and complex elements of the prototype. It also provides a glimpse of the overall structure of the product, giving me the opportunity to identify any issues in the design before spending more time enhancing it. I also ask involved parties to review and identify any problems that they see.
Identifying issues during this phase is essential, this gives me the chance to fix what is broken and add what is missing. In this phase, I write down what Heuristic Principles were violated. I then analyze how severe the issues are and figure out an approach to resolving these issues. After creating my check list I then proceed in designing and developing the final prototype. The final prototype will be the interactive product that I’ll be using for users’ evaluation and usability tests purposes.
User Interface Design and High Fidelity Prototype
User Interface Design and High Fidelity Prototype
My design aesthetic is simple, straight forward and something users can quickly identify. I don’t like users to wonder what the function is about, I would like for them to quickly identify what an element does in an instant.
My last phase of design process is to start creating the graphical interface and mockup of the product. Here, I start using my favorite tools such as Illustrator and Photoshop. I then analyze which graphic or elements are appropriate for the product. During the visual design process, I usually end experimenting and come up with a couple of design alternatives to see what works best.
The last phase of the design process is to finalize the product’s high fidelity prototype. To complete this process I use prototyping tools such as Justinmind. I then start testing the prototype and gather the client/stakeholder or team member’s input. I then check if there are still changes needed, if there’s none and if it is decided that the prototype is ready for users’ to test, I then start establishing a user evaluation and usability test plan.
The final process is to gather the feedback, collect users’ input and make changes on the prototype based on the users’ feedback and information collected. Once everything is fixed and all other items were resolved, I then help out in creating the development plan for the product’s development life cycle.