How we help IBM i shops understand their web app needs
We, in Fresche’s Web Application Development team, are frequently called upon to consider a new business application, and estimate how much it will cost to build it.
With the amount of detail we typically have at this point (to wit: almost none), we can plausibly only suggest that it will cost more than a breadbox and less than the Death Star (we think). Hence, the application discovery phase of a project.
What is a Discovery?
There are a couple of different discoveries that we can undertake: a strategic modernization Discovery, and the Web Application Discovery. The former is a comprehensive strategic assessment of an IBM i shop’s infrastructure, applications, and business vision. The latter is a much more focused endeavour, looking at a specific need. We’ll be discussing the Web Application Discovery in this article.
The Web application discovery phase aims to understand what is needed and estimate the cost of building it. Once it has been scoped and estimated, the decision to proceed or not is made. The goal is to understand enough of the users’ needs so as to make a reasonable estimate of the cost to build. Estimates aren’t really meant to be accurate (in fact, the words estimate and accurate mean different things), but they can be more or less close to the mark, and the application discovery process helps us get closer to that mark.
Key to the whole process is understanding the user needs, and the value that answering those needs provides. This really means getting close to the ultimate users of the application and living in their world. To effectively do this we need to cultivate a certain way of thinking.
The Discoverer’s Mind
The discoverer has an interesting challenge: to find out the customer’s real needs, and to propose a solution that meets those needs.
Why do we say “real needs”? Having worked in software development for many years, all too often we have been in the situation in which the customer states “we need x, y, and z”, only to find out later that they merely wanted these things (sometimes without even knowing why). And to everyone’s later dismay realizing that some of those wants didn’t serve the needs they truly had. So we want to unpack what they need, and the value that this provides them.
To truly understand their needs, we need to be in their world. We need to abandon our preconceptions about what we think we know about it, and empathize with their problems. To consider a discovery through different lenses, try looking up some of the synonyms for “discovery”: detection, disclosure, encounter, introduction.
We have a lot of experience building software, and we think we know a lot about it. And yet with that expertise comes the risk of believing that “we know better”. The zen concept of Shoshin, or “beginner’s mind” can be helpful here. Although we have many years of experience in software and solution development, we need to try and think like a beginner, and soak up the world of our customer. We need to be vigilant about not prematurely pruning the decision tree, so to speak.
The Discoverer’s Toolkit
Web application discoverers have many different tools and strategies at their disposal. Here are some of them:
Setting the stage
Discovering a whole new world, understanding key needs, and eventually proposing solutions is not a trivial task. Having a good start is imperative to success. We kick things off with two very simple, yet important, questions.
- What are your goals?
- How will you measure success?
These two questions are perfect for forming the foundations for the discovery activities to follow. They help everyone clearly understand the main goals and the key Measures of Success (MOS).
Don’t be afraid here. Jump in and put them up on a white board with reckless abandon. You are not writing them in stone, because this is a discovery and you are just getting started! Almost every activity in a discovery should end with a review of the goals and MOS to see if we are still aligned or if we need to make adjustments.
Other important things to consider when defining goals and MOS are to consider the audience. We want to home in on the true users of the application. So we really want to find the right people.
Personae, User Stories and Interviews
We now have some high level goals and MOS. Up next, who is going to use this thing? Who are they? Are we talking to the right people? The real users of the proposed product?
Often the needs are delivered by an intermediary, such as an IT team member or manager. We’ve been in the unfortunate position of having an intermediary tell us that they don’t want to give the users a voice, because users will ask for the moon. We really need the actual users telling
us about their world and what they do.
Sometimes we are told an application will service user A only to find out later there is Manager B and Customer C who no one considered. We need to be conscious of all user types, no matter their level of interaction with an application. A simple activity we can do here is map out the typical workflow of the “jobs” or “operations” to be completed. This helps us identify the user types, or roles.
Now that we know our different user types (personae), we can dig deeper to understand them. So how do we figure this out? Let’s hear the story straight from the source: for our next Discovery activity we interview users.
This provides insight to what they need to do, and why (the user stories). During these interviews it is important to keep an open and unassuming mind. We’re looking to identify nuances or subtle things that a user does. It is not just the “What” or “How” a user does something, it’s also the “Why”.
Questioning the Answers
Consider the “Five Whys”, made famous by its use at Toyota. Although this method of inquiry is typically used as a troubleshooting strategy, there is no reason why you can’t think this way when learning about user needs.
For example, we were doing a discovery for an application where dispatchers assigned jobs to contractors. The stated need was “We need to know how jobs are allocated to contractors”.
From the managers, we heard:
- Why? So we have a better idea how many jobs a day we complete
- Why? We want to maximize the number each contractor gets
- Why? It gives the contractor more opportunity to maximize their pay
- Why? Because we can better plan the jobs of the day
- Why? It helps us better serve our customers
From the dispatchers, we heard:
- Why? So we have a better idea how many jobs a day we complete
- Why? We want to maximize the number each contractor gets
- Why? We want to be fair to our contractors
- Why? Because we want happy contractors
- Why? It helps us better serve our customers
Notice that there are some slight variations in the reasons between user groups. This was new and enlightening. Armed with this key information it helped us identify key metrics that we included into the user UI. Everyone wins!
Wireframing (because a picture is worth a thousand words)
Before we start slinging code we like to validate our customers’ thoughts and vision with a wireframe. A simple visual representation of how a proposed application will work, a wireframe can be as simple as some sketches on paper or as interactive as an HTML skeleton of the proposed application. The key is to illustrate what the users will do and how it solves their problems.
We use a wireframe to share our thoughts with the customer frequently and make sure we are going in the right direction and speaking the same language. Like the Goals and MOS the wireframe is another artifact we can reference often and modify organically as the Discovery pushes on.
Although there are many different tools and strategies regarding wireframes, they all share some of the same “moments of zen”:
- Fail fast and often
- Get user input early and often
- Grow the wireframe together
- “A designer has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.”
The Road Goes Ever On
There is a satisfaction, a joy even, in learning what people do. There is nothing quite like the “aha” moment when we truly understand something, especially when a simple thing is drilled into and found to be more nuanced than it appeared. And this can go both ways: the users know that they have been heard, and they have been understood. Nothing facilitates user engagement like the shared understanding built during the discovery. Now they have some skin in the game, which is exactly how to finish the Discovery phase and take the next steps.
