This site is a work in progress. Last updated January 2023.

Designing a Complex App

Task Analysis and User Analysis.

This is the very start of the process, it's where you find out if there is a gap in the market, if current tools aren't solving the problem, and if you can bring something new, innovative and unique to the table. This brief article will hopefully give you enough information to know if you want to press on with the analysis stage, or to learn more about it.Performing both of these qualitative research steps is very important and not to be skipped (unless you intend to succeed entirely by accident of course). The aim of them is to get high quality information about who your target users are and what they want to achieve, this is fundamentally important to understanding the problem domain, and to figuring out if you can build something useful, and if you can, what that is.

Task Analysis

Firstly, task analysis can be broken up into different disciplines such as cognitive task analysis (understanding the goals and users) and hierarchical task analysis (understanding the process), in practice, I've found it's difficult, and indeed pointless, to separate the two as there is unavoidable overlap.As a general starting point, here some questions you should try to answer. You should answer these questions by talking to users, and just as importantly, watching them work.

What are your user's goals?
What skills/ experience are required to achieve these goals?
How do users currently achieve these goals?
- What are the day to day tasks, and how are they done?
- What are the frustrating workflows?
- What takes much longer then it should?
- What features are missing from existing solutions?
- Where do people get stuck/ confused most often?
- Where do repetitions in workflows occur?
- What already works well in the process?

You can go into as much detail as you feel is useful, for example the question "What are the day to day tasks, and how are they done?" could be a high level description of the phases of a task, or it could be a step by step breakdown of each sub-task. Use your discretion.A word of warning in the form of an observation from Thomas Green and Alan Blackwell is that users often display inventive and unexpected approaches that will not always be apparent in task analysis, so bare this in mind when making decisions about how restricted users really are.

User Analysis

Though related to Task Analysis, this is a distinct area of research, but as with the distinction between cognitive task analysis and hierarchical task analysis, in practice separating this research phase doesn't provide any benefit and doing both parts in one step is an efficient and effective way to proceed. It is important to note that this stage does not involve developing 'personas', these are too specific for our needs here, and are generally not useful in complex app design (except in the hands of experts) - a later chapter will go into detail on why that is. This stage needs to be completed by actually talking to people (virtually or in real life). The goal with user analysis is to understand who your users are by answering a series of high level questions which you can then distill into facts:

How open are you users to using different solutions? - If you are developing a tool for an existing market - What are the barriers for entry? i.e what is the killer product characteristic they would use your product for?
What is their motivation for using your product?
Do you need to take any cultural or socio-economic factors into account?
Do your potential users work alone or in teams or both?
If your users collaborate, what exactly does that mean? Simultaneous editing? Reviews? Observation? Simply Sharing files? What's actually useful here?
Is privacy and data security a paramount concern?
What is their approval process?
Would they dip in and out of your product or stay in it all day?
Will users be trained to use your product?
Will existing knowledge lead to assumptions about how your product works?
What skill levels does your product need to cater for?

One outcome of this stage of the work is that you should now be aware of the task complexity and your general user skill level, from this you can determine the granularity of control that your users will need in your app.

Don't skip this step

“If I had asked people what they wanted, they would have said faster horses.” --Henry Ford (only it wasn't, it's made up nonsense).

There are lots of idiotic statements and apocryphal quotes like this one, all of which basically give people an excuse not to talk to their users. The thing is, talking to your users about what they want is a gold mine of information for product designers. Your job is to pan through what they say, figuring out the common threads of the problems they're trying to solve. Once you've figured out the problems, you can then set to work designing the optimum solution for that problem, which you can then verify by, you guessed it, talking to your users again.However, talking isn't enough, many aspects of day to day work (frustrating or otherwise) go unnoticed by users, so the process doesn't stop after you've talked to them about their pain points, you need to actually watch them work. However if you don't find yourself in such a lucky position as I have — working in an animation studio while building animation software — it doesn't really matter, as task and user analysis can still be easily done. For example I no longer work in an animation studio but I've found screen recordings (solicited, or from live streams, walkthroughs, tutorials and so on) work just as well as standing over someone's shoulder when augmented with standard user interviews.Once you've gathered all the background information you need, you can plot your user requirements, these are the goals that people should be able to achieve with your product.In conclusion, the trick with task and user analysis is to do it early enough in the process for it to inform the Conceptual Design and the Architecture.

Google Sites

Report abuse