Dan Wanless's avatar

Author: Dan Wanless
Dan is the Development Team Lead at Cloud2

Solving business problems first

As a developer, I’m often in meetings where users are discussing their requirement to build a mobile application or their requirement to build an intranet application; which is fine but I believe the correct approach should be to separate the functionality discussions from the interface discussions.

The correct approach should be to decide what problem we want to solve and produce the correct solution to this problem AND then to produce the most appropriate UI or UI’s for the solution we have created.

Let’s talk this through an example:

We have a simple request where we want to allow our users to book their leave entitlement.

We could decide that what we need is a new intranet application that allows users to book leave or we could separate this into two parts:

  1. firstly, the problem i.e. we need to allow our user base to make holiday requests and
  2. secondly, we need to design an appropriate UI to the solution we produce

If in our fictitious example, we make some assumptions for the solution such as:

  • only one member of staff in each department can be on annual leave at one time
  • all leave requests for more than two weeks holiday requires a meeting with the user’s line manager
  • the user’s line manager must approve all annual leave

We could summarise our potential solution as follows:

  1. allow user to make holiday request
  2. check against the leave database and if another user from the department is already on leave. If so, we refuse the request
  3. we can then make a check to see if the leave request is for more than two weeks and prompt the user asking if they would like to arrange a meeting with their line manager to discuss the request
  4. if the leave request passes all the checks, we can forward the leave request onto the user’s line manager for approval

We can build the above solution independently from the UI and in an easily consumed manner. This would allow us to use this same solution with multiple interfaces, so we may decide in further discussion to produce multiple interfaces for the same application to meet all our users’ needs. For example:

  • we produce a web part to be used in the SharePoint intranet for all desk-based and mobile staff to book annual leave
  • we produce a bot to allow staff to make annual leave requests through Microsoft Teams chat

This means we are maintaining two UI’s but only one solution. So if we need to make a functional change to the underlying solution, for example, we now decide all holiday requests over one week must have a meeting with the user’s line manager we can make this change once to the solution and both UI’s will respect the change with no rework.

Similarly, if we decide that it would be really useful for our on the road staff to be able to make a holiday booking without having to type in their request we could use the same solution to produce a Cortana skill allowing users to make annual leave request via voice using the Cortana digital agent; giving us 3 ways to consume the same solution.

Obviously, this is a very simple example and this approach is not right in all cases but I believe we should try to split the problem that needs to be solved away from how we want users to consume the solution. This offers us a lot of benefits, so rather than thinking we need an intranet application to allow us to book annual leave we can tackle the problem first.

The issue being we need to allow our users to book annual leave and design a robust fully featured solution for this problem. Then as a separate workstream we can decide how users need to consume this great new solution we have designed, and this may be through a single or multiple interfaces.

← Other blog articles

Cloud2 tweets