Preamble

This post tells the story of the lessons I learned when I prototyped a webapp over night to improve the workflow of engineers at a Fortune 500 company. What went right, what wrong and what would I do differently the next time.

What the project was about

A good friend of mine approached me and asked whether or not I would be able to help them improve the situation at their workplace. I inquired more details and found out that their employer suffers from what I succinctly call "departmentalization induced data dispersion".

This seems to be an inevitable pain of growing bigger and losing track of data scattered across or even inside departments themselves. Employees need different documents, reports, Excel sheets, PDFs, manuals / books, the company intranet, etc.

Who doesn't love sending different revisions of a file back and fourth via email? Fun for the whole family! :)

People with decision making power often overlook the pains of the engineers that need to waste thousands of dollars worth of time hunting for information to do their jobs. We are talking about highly qualified, well paid engineers and managers; Invite a team to a meeting that could have been an email and congratulations, this just cost you over a couple thousand bucks.

I love improving and or automating tedious tasks so I set out to help and built a prototype overnight.

The Problem

My friend needs to manually hunt for documents, reports, sheets, etc. to retrieve information about different hardware parts. This can get rather complicated and time intensive because there can be nuanced differences between the same part depending on where it was manufactured. Private company research papers by different researchers need to be found, consulted and referenced which can take a considerable amount of time.

The Solution

A centralized, searchable and shareable information hub to quickly filter through lots of data points. Additionally the option for future customizability in terms of automating tasks, for example automatically pulling quotes from and citing private research papers.

My approach

As a programmer I immediately thought about the architecture. How does everything fit together, how do the systems work with each other, how would I expand the functionality, how would the site be hosted, how would I maintain quality and correctness of data, etc. etc. etc.

But then I caught myself and remembered a good presentation by Jake Knapp, which I highly recommend!

• I do not need to fully build out the idea.
• Properly planning the project out (at this point) is unnecessary.
  
• We are just interested in getting feedback about the proposition. That's key.

Anybody that worked with a huge client most likely experienced the dread of writing mails for weeks if not months, ughhh. Things move slowly in the enterprise world. Before something happens, there are several approvals needed and somebody somewhere needs to get that email again and decisions get postponed and yada, yada, yada.

It's simply not worth it to put in the time for a project of this size before you get approval in writing.

We as engineers love the technical details and inner workings of things, but a person responsible for allocating budgets is most likely just interested in:

• How does this help?
• How does it look like?
• How much does this cost?
• How long will this take?

All of these points can be answered without the need for a proper working MVP, which means that the more time efficient way of handling this opportunity, or rather this proposal, is: Faking it, until you sign the deal.

What does "Faking it" mean

Let me quickly elaborate on the meaning of "faking something" tech related, because people outside of tech often have a negative view on the expression.

So for this project, let's say you have a device, be it a laptop or phone, and you want to retrieve a list of available hardware parts. In a real environment it would look like this:

The device requests data through the inter-/ or intranet from somewhere else e.g. a database on a server.

Now, if you'd want to genuinely make this happen you need to worry about the reachability of the server, credentials, security, error messages, managing the data itself and all the things that I omitted just now. None of this is impossible of course, but it costs time. Unnecessary time.

To avoid all of this, we simply can include the needed data beforehand and just pretend that we're fetching it from somewhere else. From an outside view these two methods will look exactly the same:

Real

1. Start loading animation
2. Request data
3. Receive data
4. End Loading animation
5. Use data

Fake

1. Start loading animation
2. Wait one second
3. End loading animation
4. Use data

Not only does this save time, this also reduces the points of possible failures during a presentation. 

Imagine trying to sell your product and failing right in front of your client. Yikes. Germans have a succinct word for it called "Vorführeffekt" which translates to "presentation effect" and describes the situation when you tried something and made sure it works but as soon as you present it to someone, it simply fails.

So, "faking it" is not bad in this context. It both saves you time and reduces things you need to worry about. After signing the deal, depending on how careful you were, you 'just' need to replace the code where you send and receive data.

My Prototype

1. Login

A Login-Page is a must. The service would, of course, need to be gated and controlled.

Now comes the first "fake-feature". How do you implement a Login that needs to look like it works?

You have a boolean variable isLoggedIn which indicates whether or not the user is logged in. The input fields do nothing. The Login-Button simply sets the variable to true.

Yea.. ¯\_(ツ)_/¯

The purpose of the Login-Page was not to (directly) sell the prototype. I wanted it to set the mood for the first impression and hopefully intrigue the viewers as to what's behind the auth-wall. I had hoped that the Login-Page functions as an introduction of sorts, to evoke a feeling of "alright, this proposal isn't just a loose page that someone threw together, this is a proper useable thing".

2. Search

After you successfully log in, you are shown the meat of the project, the Search-Page. Originally the advanced search drawer would be closed, but for this post I screenshotted it open so that you can see everything in one image.

I think the interface is pretty self explanatory. You can type in a query, potentially apply some filters and hit the Search-Button. This isn't rocket science.

What I'd like to emphasize though, is that it's important to create the experience of your thing working. What would it look like when we search for something?

It looks pretty realistic and smooth, eh? Of course you can't properly implement a working solution over night, but what you can implement is - the experience of how it would look/feel like. Remember we were just interested in receiving feedback.

// The Search function simply
// updates the loading-bar and
// sets up the table entries after a delay.
search: function() {
  this.searchProgress = 0.1;

  // Wait for 200ms => 25% Progress
  setTimeout(() => {
    this.searchProgress = 25;
  }, 200);

  // Wait for 1s => 100% Progress
  setTimeout(() => {
    this.searchProgress = 100;

    // Wait for 500ms => Reset & Update the table
    setTimeout(() => {
      this.searchProgress = 0;
      this.tableEntries = generateRandomTableEntries();
    }, 500);

  }, 1000);

}

<!-- We only show the progress bar if 
the progress is greater than zero. -->
<div class="progress ..."
  v-if="searchProgress > 0"
>
  <div class="progress-bar progress-bar-striped ..."
    :style="{ width: searchProgress + '%' }"
  >
    <!-- See how we calculate the width.
    It's just the progress as a percentage.
    25 equals 25% in width. Really simple.
    For this example I omitted other attributes. -->
  </div>
</div>

Just wait a little and update values. No networking, no data validation, no errors. Keep it simple, stupid.

You can click on the table entries which take you to their profile page.

3. Part Profile

These are a key feature, they enable colleagues to share the URLs via Email for example. These would be important reference points for users to come back to from time to time. They are a hub with all the information and functions you might need.

Here you can very easily provide additional value through (future) functionality. New fields, new buttons, automation for tedious tasks.

How the presentations went

With the experience now "working", the prototype was ready to be presented to the first round of people: Colleagues and the manager.

The presentation went smoothly and it got lots of praise: For the design, ease of use and the potential that it shows. The engineers and more importantly the manager immediately were on board and wanted to escalate the proposal to the decision-makers, namely the people that have power over budget assignments.

That took a while, because.. enterprise. Here's also an important lesson: You need to wait for a contract before you celebrate. This is just business, don't take it personal. Talk is very cheap and easy, in 99% of cases it isn't even meant to be misleading. Things just don't work out, it genuinely happens. As with this project.

The engineers and manager were all very interested and elevated the proposal. It got reviewed by higher-ups and again, lots of praise. But now it was time to talk about allocating budget for implementation and this is where it sadly stopped. They simply weren't able to allot enough budget for this project. Maybe with different timing it could have been different but that doesn't matter now.

This obviously made me unhappy but this is just business. It wasn't personal and that's alright.

What would I do differently next time

This whole project happend a long time ago and now I'm way more experienced with Vue.js so I'd make use of it's ecosystem a lot more. Namely I would use the awesome Vue Router, the Vuex Store and the Vue CLI.

At the point when I built this prototype, I needed to deliver as fast as possible and I wasn't too familiar with those things. I knew what they do and that I should use them in the long run, but I just stuck to what I was comfortable with in order to retain my development speed.

Now in hindsight, I would proceed like so:

1. Use the Vue CLI to quickly setup the project. Include the Vue Router and Store in the setup step.
   
2. Use the Vue Router in order to support different URLs and to be able to still contain the whole project in a single file.
   
3. Use the Vuex Store in order to abstract the request/retrieval of data away.
   
   While this isn't technically needed for a simple demo like this, this approach would be a lot cleaner and would enable you to reuse more code, if you need to expand upon the demo.
   
4. Contain everything in a single HTML File. Build the JS, the SCSS, convert images to Base64 and include all of them in a single file.

Vue Router would have saved me so much hassle. Did you wonder how I made the Part-Profile-Page for every part without a router? I created a Node.js script that generates parts

for(const part of parts) {

  for(const footprint of footprints) {

    for(const coating of coatings) {

      const item = {
        // I omitted lots of lines
        // for your viewing pleasure.
      };

      output.push(item);
    }
			
  }
		
}

then reads a Template-HTML that I created with a specific "marker"

new Vue({
  el: '#app',
  data: {
    profile: {}//REPLACEMEHEREPLS
  },

  // Etc.
});

and replaces the marker with the generated data. When that's done, it gets written to disk.

const replacedTemplateContent =
(fs.readFileSync(
  partProfileTemplatePath,
  { encoding: 'utf8' })
)
.replace('{}//REPLACEMEHEREPLS', partDataReplacement);

fs.writeFileSync(replacedTemplateName, replacedTemplateContent);

After all, necessity is the mother of invention, haha.

If there's enough interest, I could rebuild this project with my current knowledge and open source it. Let me know!

Conclusion

1. If you're only interested in presenting something to decision-makers in order to get feedback, implementing a fully featured MVP is unnecessary. Save yourself a lot of time by "faking" functionality. Of course you should know how you'd expand on your prototype but don't go out of your way and spend unnecessary time over implementation details. Create the experience of your thing working. 
   
   
2. The enterprise realm moves slowly. Decisions need time and nothing is certain as long as there aren't signed contracts. No contract, no champagne.
   
   
3. Use what you're familiar with so that you can iterate as fast as possible. With my current knowledge I could have completed this project even faster and cleaner but you're always gonna be smarter in hindsight. Hindsight is good, let it improve the future You. Creating something that people can actually see and use, has a lot more value than just plans, ideas or promises.
   
   
4. Depending on who you are trying to impress, you probably should make it look pretty and polished; Use the company colors and or the design language. The first impression is worth a lot and if you can induce the feeling of your product "fitting in", you're one step closer.
   
   My design got lots of praise and I believe that this contributed to how fast my proposal got elevated to the decision-makers.
   
   
5. Make the prototype as easily shareable as possible. No setup! Remember, the less moving parts, the less can break, the better. At best you just have a single file. People will then be able to simply forward your whole thing via email. USB sticks in big corporations and or sensitive work environments are often forbidden and no decision maker is interested in unpacking zip files.

Awesome photo by Stefan Stefancik from Pexels