There are techniques found in software engineering that can be applied to any business design. Whether you do your best system organisation using spreadsheets, or special Windows or Mac software, there are numerous tools that will assist you in planning out your most important procedures.
Developing a process that is necessary may begin with your own internal data needs, but it must fit together logically with your user experiences to get the best results. Watch this video so you can learn how to take uniquely customer-driven information, and process it based on bigger-picture experiences, user feedback and crucial criteria to set up boundaries and requirements that enhance the accuracy of the final experience.
Video Transcript:
Customer Driven Software Development
User Stories
The second last one is user stories method. User stories are a really common thing in software engineering. They’re written requirements but they’re customer driven. So they define what customers are looking to get. We can do these on paper cards or spreadsheets. You learn later today what a Kanban piece of software is. Some of you have been exposed to that. Alex is going to show you later today. We can write these user stories in a range of ways.
User stories methods are an extension of tasks that are in the actor analysis. What are some of the things in user stories? They are typically written in this format:
As a type of user, I want some goal, so that is a reason. The curry example that I’m going to give you is a little bit frivolous here but I want to pick out the key aspects. This is the user, this is what they want to do and this is the reason. Often we don’t give developers the reason. Developers are really smart people. They have very high IQs and giving them the context of what you are trying to achieve, they can often use their intuition to say, hang on. They’ll raise problems. They’ll flush things out.
This is the standard format we use for user stories. Here’s another one, “as a curry lover I want to change my order because I’m indecisive”.
Tips for User Stories
Some tips around user stories. We want to be concise. They are a contract for a conversation. Some people write their user stories and think it is the only chance that I’m going to have to talk to my developer. The goal of a user story is we get the gist of it down and each developer before they start to work, they start working on it and we’re going to talk about sprints and other things, would have a conversation with the client. We would confirm, tell us about this user story. What are we trying to do, it is a contract to talk about something.
Who writes them? Anyone can write these. Clients can write them, developers can write them, project managers can write them, business analysts can write them.
When are they written? Often they are written at high levels at the start of the project but they’re generally written throughout the process. You’ll often write user stories all the way through.
What’s an epic?
A couple of other bits of lingo, because this lingo will come around in the industry and I think it is good to demystify some of the lingo. There is a thing called an epic. An epic is a large story that is going to need to be broken up. If you look at it and say, I want to do these bits and pieces, then I’ve got this big thing over here, you can write a single user story for the epic. Often we will put that into our backlog in planning and then when we get to it, we will actually break an epic down. So an epic is just a large story that is going to need to be broken down.
Acceptance criteria
The last piece about user stories method is acceptance criteria. We want to say what are the things that need to be true? How is this going to be tested against? Orders are only going to be accepted from people whose IOUs are under $30. That is an acceptance criteria in the curry ordering system. Orders are only acceptable from people whose IOUs are less than four weeks old. That is an acceptance criteria. Order changes are rejected after 11am.
Wireframes and Sketches
My last method, one more tip and then we’ll take a morning break. The last piece is wireframes and sketches. A lot of people want to start here. I would always at least start with an actor analysis because these typically take longer to create and they are generally the culmination of the other work that you’ve done. You’ve often done the analysis on the other bits and pieces.
Those other techniques, you can do them pretty quickly. You can sit there and say, who are my actors? What are they going to do? Where do they sit, right I’ve thought about that one. You can often go through these at reasonable speed. Creating wire frames and sketches takes a little bit longer, but they’re really important. I would say our rate of arguments with clients dropped by half when we started putting material in pictures because it flushed out so many differences in what people thought.
They tie everything together and you can also use them to test solutions. We talked about that in the MVP space. They flush out misunderstandings. A lot of people are embarrassed to do these with pen and paper. It doesn’t matter if you can’t draw. Pen and paper is actually really good and I’ll show you some examples of that of ours in a moment.
Another thing you can do is a lot of people feel comfortable in PowerPoint or keynote or presentation software. You can often do these in Keynote. We’ve done that. There is a tool called Balsamiq Mockups which is quite easy to use. So if you wanted to create these, that works well. If you’re able to use drawing software, drawing software works.
Let me show you, these are the real mockups for the Content Samurai product. We firstly created these. That is the first version of Content Samurai, just coming up to two years ago. We then drew this. I wouldn’t do this for clients, because clients would be embarrassed and feel they weren’t getting value out of it. We weren’t trying to impress anybody, we just wanted to get the learnings that we could. We put these up, we got people to review them, people to look at them.
Google offers a free presentation tool called Google Slides. It’s like PowerPoint but the Google version of it. The beauty of it is you can share it and you can comment on it. So if you’ve got a team and you want to get someone to put it up, everybody can go to town commenting on it and it’s free. It’s really good.
These are the comments written in October 2014, by Eugene. This is actually what he said. That is Anthony, the product owner’s position and this is his feedback. These are just screen shots I took from it. Then we put in some drawing software. It still doesn’t look super polished, but it’s starting to look a lot better.
This is as the process moved toward the end. As you can see, I’ll go back one, it’s actually the same material. We just evolved it further. These are the latest versions we’re using at the moment. This is the way the product looks and it does a range of bits and pieces.
So you can see it started out pretty ugly. Over a series of interviews we got a heap of feedback. I don’t want to build this to get the early feedback. Early on, if I show people this, it’s worse. The reason it’s worse is people are judging my graphic design, they’re not judging the functionality of the software. I need them to judge the functionality more than they judge the graphic design.
These are our techniques, we’ve got our system focused ones, our customer focused ones and we combine them at the end with wire frames.
Non functional requirements are the things you want to tell your developer about your system that are not features of the software per se. Let me give you some examples: how fast it is going to run and how many users it’s going to have and what you’re expecting there, what browser versions it needs to support. These are not specific features but these are things that you want to get clear. Is it going to work in mobiles which is what we call being responsive, the website responds down to mobiles. And what are my hosting requirements?
This is interesting. We’ve had jobs that we had really nice hosting to serve really well and then we found out they had to keep the data in Australia. So knowing those things is important.
This is the end of our session. Hopefully there were some things in there that you learned.
There isn’t just one way to improve your own process or work with a developer to design user software or business experiences for success. The important thing is that you learn to utilise processes that help you to identify where your strengths and weaknesses exist. You can gain valuable narratives about what it is like for a user to use your product, including their feedback and descriptions of the experience. Learning to use this data for the best user experience and also for making necessary limitations to the experience, you can vastly improve the results to the bottom line of your business while saving money, time and resources.
Get in touch with us today if you think we can help improve the way your business implements its processes.