Using User Experience to Design Technical Solutions
When designing any consumer facing touch-point, your consumers should be at the front and centre of thoughts as they will ultimately be the one using it. Building an app around the end-user will not only greatly increase pickup and engagement rate, but also ensures its usefulness and relevance.
To determine a user-centric experience, the best way is through communication and understanding the factors that make them tick. The technique we use in MotherApp is through developing user stories.
User story is a relatively new technique for technical companies to develop their software or applications in a more agile and effective way. This is especially important for complicated, long-term projects. Before we go into details below, let us quickly understand what user stories are.
In short, building user stories mean having a particular user in mind, understanding their concerns, and creating solutions that will satisfy these concerns. It is an ongoing journey, and less of a destination. To create great user experiences, that means developing an understanding of how to create the best task flow for that user based on the stories generated.
Let’s go a little deeper.
In any software development project, the end goal is usually to implement a particular information processing system using certain technologies and within certain constraints.
Take for example, a mobile application.
The traditional process of software creation typically involves very little on-going communication between the business provider(client) and the developer (tech agency). Upon project sign-off, the developer goes on with the list of requirements on hand to be met and starts researching for solutions to meet the requests of their clients.
However, here the focus is on what the business wants in the software, and it may not necessarily be what their consumers are looking for. A typical software development lifecycle (SDLC) here usually involves a certain number of phases where progress is done sequentially.
Example of a SDLC:
This is commonly known as the ‘top-down’ or the ‘waterfall model’. Though originally created to allow for deadlines to be better met within a schedule and for greater departmentalisation and control, often than not it seems to result in the opposite.
There are certain industries where the waterfall model works perfectly. However, with the complexity of the digital environment, and the coordination needed with a wide range of stakeholders, we need a model with more flexibility when designing such a software.
With this top-down method, there are high amounts of risk and uncertainty. If a given project is already in the testing stage ready for deployment, and all of a sudden- the design team discovered an important requirement that has not yet been integrated, the project will have to be postponed and re-done.
Additionally, if the software design was drawn up based on second-hand research and information, it will be hard to predict if the end product will ultimately be positively received.
Imagine the time, manpower and budgets wasted on this kind of design process.
The truth of the matter is that any kind of software design aimed for the general market should not be a two-way street but a three-way dialogue. Understanding the ‘persona’ is fundamental and even more so than the objectives of the clients or the business engaged in the project.
So what is a user-centric development pipeline like?
The first step Wendy suggests, is to develop initial insights on the current obstacles experienced with a certain product/service, or the needs of the business (which results in the software as a solution), mainly through second-hand research.
When the team has a better grasp of current problems faced, a mix of qualitative and quantitative techniques will then be employed to derive a deeper first-hand exploration through the end-users, commonly though user experience interviews. They can also be thought of as focus groups.
Through these research, a ‘persona’ is created- one who will eventually use the software developed, and whom our user stories will be gathered from.
Identifying a persona gives a better picture on who is trying to get what out of the product, particularly effective in brainstorming sessions where a backbone narrative will be drawn up. Thinking of the end users instead of simply meeting a business objective will also lead to a more sustainable and user-centric product backlog. This is the alternative to creating big chunky stacks of documents as designers can better foresee problems that will arise from the implementations of their designs.
Once the backbone narrative has been written up, the whole team working on the project gets together to do ‘story-mapping’ together. This involves the visual designer, UX designer, product managers, developers, quality assurance etc. as it allows everyone to understand and own the products before doing up the product backlog.
This avoids confusion and allows for any loopholes to be covered earlier rather than later when designing the product with a wider range of perspective. This stage is also where user stories previously gathered are especially important.
By mapping out all the possible objectives and comparing them to business objectives – it becomes easy to create user flows. When the product backlog is defined, the design team along with all parties are in sync of what is imperative for the persona’s immediate needs and what is secondary to those needs. Prioritisation is key to ensure timeliness of project delivery.
What MotherApp does is use a user-experience model as part of an iterative process.
This allows our clients to be able to experience the app first-hand before it is fully built. Not only does this prototype form the specification for engineering, it helps the client to internally communicate to their organisation, the app's design and capabilities before the final product is done.
One such example is a project we previously did for our client-Hong Kong Trade Development Council (HKTDC). HKTDC is a large organisation with exhibition, publication, e-commerce, product promotion and research divisions.
The challenge faced was to identify amongst its diverse offerings, those that will yield the largest return on investment (ROI) with a mobile solution. Thus, we performed a Mobile Opportunity Analysis to get deeper insights from both HKTDC and their visitors to determine the objectives in which a mobile solution would be most effective.
By separating the overall design process into user analysis, solution prototyping and visual design phases, this approach translates into effective app concepts in the shortest amount of time possible. To see what we have achieved for HKTDC, click here.
We believe that including end-users as part of the design process gives a bird’s eye view of the environment in which mobile solutions will be created. This for the client means more efficient and effective, trackable progress, sometimes even more than they set out for.
Not to mention, the results will be twofold- a chance for deeper market understanding and having better facilitation tools to satisfy the ever-changing demands of their market. You can test this out too- simply drop us an email at [email protected] and our team will get in touch with you.