1.First things first

After few phone-calls and skype talks with the client, when we talked about project in general, we received access to the current version of the application. During one of the calls we discovered the app with the client via remote desktop. This started nearly 3-month long research phase.

2. Research

We didn't have any project documentation. We had to learn about the app by ourselves and create the document from scratch.

Research phase was about discovering what the app is all about, what are the typical tasks, what are the current constraints of the system (either in front and back-end side).

Business requirements

Encapsulating the general business requirements was easy. They were all about making the app to the today's standard. The User Interface has to be decluttered, main functionalities have to be easier to find and use. As we later found out, the devil was in the details.

User requirements

The user requirements was hard to grasp. The system was extremely complex collection of data, tables, charts, functions, filters and sections. It was hard to get our head around it. Interface of the app wasn't helping in understanding either.

One platform - two subsystems requirements

While figuring user requirements out it became clear that the system is divided into two subsystems that don't have many crossovers, yet they aren't treated this way.

We decided that it needs to be addressed immediately because goals and needs of user of each subsystem don't overlap at all.

We called these subsystems the "admin subsystem" and the "user subsystem".

Admin subsystem

This part of the system was about configure access, policies, users and groups. It wasn't particularly complex - 4 sections with table and modal settings in them.

During one of the walkthrough with the stakeholder we received the information that users of this subsystem were trained professionals who know exactly what to do. At first it didn't look important, but this information change the course of the project.

User subsystem

This is the place the main work is done. Most of the screen we analyzed in desktop version of the app, were part of this subsystem. Lot of data, tables and charts.

While getting to know the system we discovered more and more connections between the different sections. It turned out that the front-end (User interface, screens) of the user panel wasn't the biggest problem. We roughly estimated that 80% of functionalities were dependent on others that wasn't necessary in the same section. It was too hard to grasp on the back-end side.

Research has to stop, time to act

After few weeks of testing and discovering the app, we came to the conclusion that the because the complexity of the system we have to either spend another months on researching or start implementing a little part of it to gain a better understanding of the entire platform.Few months without any results isn't the best option for the client. The admin subsystem is about 10-15% of the entire platform. We decided that even though they dont' have many things in common, the system UI have to be similar to the "user subsystem".

We called the client to figure out what to do next. After the talk we all decided that the best course would be to implement Admin subsystem first.

The admin subsystem is about 10-15% of the entire platform. We decided that even though they dont' have many things in common, the system UI have to be similar to the "user subsystem".

3.Implementation and validation

Sketching and wireframing

We conduct few interviews with admin panel users in order to create task models, user journeys and personas. After that, we did expert evaluation in order to speed up the process of designing new UI.

Later we designed basic sketches of the new UI and test it with the admin user who were helping us with back-end integration. We quickly move to wireframing, because it was easier to develop and test them.

In the admin subsystem the information archtecture was pretty straight-forward and there was no need to improve it.

Benchmarking and prototyping

Benchmarking the competition and discussing theirs functionalities with the admin user helped us to decide what kind of functionalities can be helpful in everyday usage.

After few back and forth iteration with wireframes we created low fidelity wireframes and tested it in InVision. We used primary task models to find out is the usability of the user interface improved.

Designing and coding

Designing the UI that is simple and easy to use when there are dozens of elements displaying on screen at once was challenging.

Technical constraints must be considered while designing. It wasn't a simple process because we have to check many of the functionalities with the the user subsystem that wasn't explored in details by that time.

The code and design elements must be reusable within user subsystem, so there was a lot of strategic thinking and carefully designed and coded components.

Project management

The project was complex. There was a lot of information that needs to be storage and be easily accesible. We used agile methodology within JIRA and Confluence.

Briefmonkey set up the JIRA workflow and took care about project management. We started with sprints, but many delays due to discussing functionalities and possibilities made us switch to kanban boards.

Clear and easy to understand kanban board and Confluence documentation facilitate cooperation between team and the client.