Alternative approaches for obtaining your business application requirements

In some recent projects, clients asked us to redesign an existing fat client application. These applications allowed users to perform complex professional tasks in a business context where multiple user types are involved in the workflow. Some of them use the application all day, others only a couple of times per month.  

The challenge was multifold. We had to, at the same time:

• Redesign the individual screens, evaluating all the new features that appeared throughout the years 
• Optimize the workflow to make business processes more efficient 

In this article, we’ll cover two ways of eliciting functional and user requirements for business applications. 

The application walkthrough 

To get familiar with the business logic and the scope of our project, we always ask business analysts to give us the first briefing by explaining the different functionalities on the screen. Business analysts are usually well-positioned to do this: 

• They know the business context inside out and can explain where screens belong in a particular workflow. 
• They have a good view on the properties of the screen content (e.g. “users have to be able to filter this list on aspect x” or “the list of all x, contains y number of elements”, or “this field is maximum z characters long”) 

Most of the existing screens we come across are cluttered with information. Without much consideration, functionalities were added throughout the years using styling from a previous age. As you are probably aware, in UX, a decade is an era. At this point, we could already start doing some rework on the screens by doing a simple clean-up: 

• Omit functionalities that are no longer relevant 
• Clean-up the lay-out by regrouping information and introducing white space  
• Properly apply UI design patterns 

This minimal effort has some value, but to allow the design to focus on the user needs, some crucial aspects are missing:  

• We lack an overview of the entire user flow 
• We have little understanding of the real business context and the user needs 

The field study approach 

To dig deeper, we prefer to talk to real users of the application. With these conversations, our main objective is to discover aspects that the purely functional requirements do not cover: 

• (Professional) goals of the user 
• Drives when using the application 
• Information needs  

Throughout the years, we’ve discovered that the most efficient way to elicit these kinds of requirements are field studies where a UX researcher or designer sits next to real users when they perform their job. 

Demonstrate to us what you do and explain why you do it 

Typical questions during such field visits are: 

• “Can you explain the goal of your role? What do you try to achieve?” In the larger business context, the application is, after all, only a means to achieve a particular business goal. 
• “To achieve business goal x, what tasks do you typically perform?”. This question will allow you to understand the different tasks, how they are individually related and how they are related to the role’s business goal. In some business contexts we’ve worked in, business process analysts provided this information in the form of a BPM (Business Process Model) diagram. A BPM diagram does show how different activities in a chain are tied together but does not take into account the information needs and goals of the user in every step. 
• “What are you professionally evaluated on?” or “What’s the worst thing that can happen?”. Understanding these aspects will allow you to understand what factors to focus on during the design phase, e.g. safety, efficiency, accuracy. 
• (on a screen level) “What information do you need to make decisions?” This question will inform you what contextual information to display on the screen 
• “What information do you produce?” 
• “Who do you collaborate with?”. The answer to this question will give an insight on who does what when in the entire workflow?
• And most importantly, “Can you demonstrate how you do this (task) and explain why you do it?”   

User developed applications 

The first set of questions will allow you to design an excellent deliverable, but this last question will provide you with an extra level of insight. Aspects that it often uncovers are: 

• How people work in reality (instead of how they say they work) 
• What other means they use on the side to perform a task. Very often, interesting stuff comes up that nobody was aware of, e.g.: 
  • Printed lists that people keep in their drawer to look up information or register information 
  • Other roles users need to consult to take a decision 
  • Additional mails users need to send 
  • Applications that users have developed themselves to make their life easier 

As designers, the latter category is super interesting. These user-developed applications fulfil the needs of a user that the current applications are not able to meet. These UDAs help to identify opportunities to make the new application better. 

Summarizing field study findings 

When you’ve talked to the main roles involved in a flow, you’ll probably be overwhelmed by information and it will be hard to summarize your findings and communicate them to the people you work with. We often use a diagram that provides a holistic view of the user’s work. It combines aspects from Service Design (holistic view on stakeholders and their goals, and different touchpoints through time) and Business Process Management (flowchart with activities, decision trees). 

Figure 1: A diagram to summarize field study findings 

Design explorations with user testing 

In some contexts, it’s not possible to perform field studies. Some of the reasons we come across often are: 

• “We don’t have the budget to make you do this” 
• “We’re in a hurry to deliver. It will take too much time.” 
• “We don’t want to lose the time of our users.” 
• “The list of requirements as drawn by our analysts are complete. What else would there be to discover?” 

• “Involving users? What do they know? It’s up to product management/IT to come up with solutions.” 
• “By asking users what they need, we might give the impression that we don’t know what to do. We might lose their buy-in.” 

Multiple solutions that meet the same requirements 

Although we firmly believe there’s no good reason not to perform field studies, sometimes we just can’t do them. A possible way to compensate for this is to design multiple solutions that meet our client’s requirements. Instead of gently refining your screen design, we force ourselves to come up with various solutions. Some advantages are: 

• It keeps your designer’s mind fit. To come up with multiple solutions for the same design challenge, you’ll have to take a step back, leave all your assumptions behind and question them.  
• Most internal stakeholders (developers, analysts, managers and designers) will have a solution in mind from the start. Presenting multiple options could bring them the message that the answer they thought of is just one of the many. 
• Towards the client, it will confirm the fact that design is not an exact science and that, in most cases, there’s not just one way to solve a problem.  

Here are some means to do this: 

• Focus on quantity instead of quality. You can do this easily by:  
  • Limiting the design time and setting the number of solutions to come up with. 
  • Moving to paper prototyping instead of losing yourself in the possibilities of digital design tools to get the pixels right. The fatter the markers you use, the better this works. 
  • Involve colleagues that do not have in-depth business knowledge. At Namahn, we use a format called BOOST sessions, in which we involve colleagues during a one-hour lunch session. These sessions aim to give your project a boost by generating multiple ideas for a design challenge. 

• Look for other UI patterns to solve a design problem. Sometimes, different patterns might have benefits you didn’t think of beforehand. 

Figure 2: 8 possible solutions for an ‘end of time’ date picker 

Ask why 

Once you have all these design options, what’s next? 

• If possible, present them to actual users of the application you’re designing. Try to have a variety of roles in the room. This will allow you to discover the different contexts of use. 
• Make sure that your prototypes contain just enough information to enable meeting participants to understand the solution. Don’t lose yourself in designing details yet because people will start arguing about details and not about the concept. Presenting things in a draft state will make people understand this is the first iteration to gather insight. 
• In your communication, present the options as a first draft that you will use to discover requirements. Do not ask people to vote for the best solution and move forward. Instead, try to understand why users prefer one option over the other. This will allow you to come up with the best and final solution. 

Conclusion 

We consider the Application Walkthrough approach as a must. It helps you understand the application and the business context from an expert point of view. It’s cheap, fast and a good basis for the other two approaches. 

The Field Study approach will take more time but we think this is inevitable if you want to do a full application (suite) overhaul, from the ground up. It’s more expensive, but the best way to optimise the overall workflow and other application concepts before going into the detailed design. 

The Design Explorations with User Testing approach is a way of doing meaningful, reusable design work if a field study is not possible. It’s fun, not too expensive, and a more focused and pragmatic way of getting user feedback on specific requirements in an organisation that is still evolving towards a user-centred approach.